書けるプロジェクトマネージャー、PKSHA Technologyでの仕事のやりがいを語る
2012年の創業以来、「未来のソフトウエアを形にする」をミッションに掲げ、アルゴリズムによる社会課題解決を実施してきた株式会社PKSHA Technology（パークシャ・テクノロジー）。機械学習や深層学習を用いた機能特化型のアルゴリズムモジュールを提供するソリューション事業や、アルゴリズムをベースにしたSaaS型ソフトウェアプロダクトの事業を展開しています。
同社が開発したチャット型対話エンジンは、LINEや資生堂などをはじめ100社以上に取り入れられ、カスタマーサポートや社内問い合わせ対応の自動化を支援しています。他にも金融業界や自動車業界などの幅広い領域でアルゴリズムによる課題解決をリードし、注目を集めている企業です。
創業者であり代表取締役である上野山勝也氏は、日本のAI研究をリードする東京大学の松尾研究室にて博士号（機械学習）を取得し、その後助教に就任した経験を持ちます。他にも、トップカンファレンス採択の博士号取得者、CTO経験者など、高い専門性を持つメンバーが多数在籍しているのが特徴です。
最先端の研究や技術に強いだけではなく、多くの導入実績と高い利用継続率を達成している同社では、どのような開発をおこなっているのでしょうか。
今回は、PKSHA Technologyでプロジェクトマネージャーを務める清時康平さんに、実際の仕事の進め方ややりがいなどを伺いました。
清時 康平
新卒で2014年に野村総合研究所に入社。プロジェクトマネージャーを経て、2019年12月からPKSHA Technologyに入社。現在はプロジェクトのマネジメント業務をしながらコードも実際に書く「書けるプロジェクトマネージャー」として、さまざまな現場で課題解決に携わる。
コードを書くために、PKSHAでプロジェクトマネージャーに
ーー今日はよろしくお願いいたします。清時さんは前職でもプロジェクトマネージャーをされていたとのことですが、転職を決められた理由は何だったのでしょうか？
清時：
転職の一番の理由は「自分でもコードを書きたい」ということでした。
プロジェクトマネージャーの見習いから始めて5年半ほど、大手の企業でいろいろなことを学ばせていただいたのですが、主な仕事内容は管理業務でした。お客様からお話を伺い、システムに落とし込む設計作業などには習熟したのですが、納品レベルのコードを書く機会はなく、自分の趣味ツールを作る程度でした。
ただ、プロジェクトマネージャーとして、コードを自分でも書けるくらいに理解しておかないといけないな、と感じることがあり……。仕事には慣れていく一方で、これを知っておけば事前にお客様により良い提案ができていたのでは、と疑問に思う機会が徐々に増えていきました。
ーーコードを書きたくてプロジェクトマネージャーに転職、というのは興味深いキャリアだと思うのですが？
清時：
そうですね。自分のキャリアでは開発職として転職をすると未経験扱いとなってしまい、それは給与面で不利でした。
そのため転職に踏ん切りがつかない状態が続いていた時に、PKSHA Technologyの求人を見つけて、一度話だけでも聞いてみようと。実際にカジュアル面談で話を聞いてみると、ビジネス／アルゴリズムエンジニア／ソフトウェアエンジニアという職種があり、ソフトウェアエンジニアの中でもプロジェクトマネジメントタスク：開発タスクの割合は各人で異なるということがわかりました。会社としては開発については教えられるからプロジェクトマネジメントをできる人が欲しい、一方、自分は開発をしたいが未経験に近く、プロジェクトマネジメントの経験がある、とお互いの希望が合致したんですね。そこでプロジェクトマネージャーとして入社し、これまで約2年勉強してきて、ようやくそれなりにコードを書けるようになってきたかな、というところです。
ーーなるほど、プロジェクトマネージャーとしての業務をこなしながら、プログラミング技術を学び、実際に書けるようになってきたんですね。転職前にやりたかったことを達成されたわけですが、技術のキャッチアップは相当大変だったのでは？
清時：
最初はかなり大変でした。半年くらいはずっと土日もカフェで勉強しているような状態でしたが、メンバーにマンツーマンで教えてもらえたので助かりました。今では1つの案件のコードを一人ですべて書けるようになったので、頑張って良かったな、と思っています。
ーーそれは清時さんの学習能力の高さもあるのでは？
清時：
優秀なエンジニアの方が、ずっと面倒を見てくださったことが一番大きいですね。あとは、今いるチームではイチから全部を作る必要があり、それこそAWSのアカウント取得から始めるという感じです。システムが既に出来上がっていて、仕組みはよくわからないけれど昔からあるので使っている、というものではないんですよね。本当にイチから全部勉強して組み上げられるようになったのが、自分としては大きかったと思います。
スピード感を持ちつつ、最後まで寄り添って形にする
ーーPKSHA Technologyは「検証で終わらない」ということを掲げていますが、どのような意味でしょうか？
清時：
いわゆる機械学習や深層学習などの技術を導入する場合、アルゴリズムのPoC（Proof of Concept）、検証だけで終わってしまうケースがありますよね。PoCをとりあえずやってみよう、ということでアルゴリズムを組んで、何パーセントの精度を達成できました、これは高いですね、という話があってそこで本当に終わってしまう。
それはなぜかと言うと、アルゴリズムはモダンな技術で実装されることが多い一方で、多くの企業ではレガシーの基幹システムを使っているため、組合わせて実業務フローに落し込むのが難しいからです。他にも、比較的モダンな技術、例えばDockerコンテナを組み込めるメンバーが先方にいない、または、いたとしても一人で作業するのは自信がない、などの場合もあります。
弊社の場合には、実際にそのような案件をいくつもこなしている技術力の高いメンバーがプロジェクトに入っていきます。Bizメンバーが先方社内で動いているシステムの詳細をきちんと把握して、どのような使い方をされたいのかヒアリングもしますし、実際に手を動かすアルゴリズムエンジニアとソフトウェアエンジニアが、お客様から直接話を伺います。すると、このAPIで提供するほうが良さそうであるとか、基幹システムに組み込むのではなく、別にダッシュボードを用意した方が良さそうであるとか、オンプレミス環境のなかにコンテナで納品したほうが良さそうであるといったことが、その場で決定できるんです。
こちらで必要な情報があればビデオ会議させていただいたり、逆にお客様のほうでわからないところがあればこちらからご案内することもできますし、寄り添う形で進めることができます。そのレベルまで頑張っていくので、本当にシステム連携まで到達できます。
検証自体を目的とせず、ちゃんとビジネス価値に繋げられるということが、PKSHA Technologyを選んでいただいている理由だと思います。
ーーエンジニアもお客様とのミーティングに参加してその場で決定、というのはすごいスピード感ですね。
清時：
大手の企業だと社内調整用にPowerPointの資料を100枚書いて、審議し結果が出るのは3ヶ月後、などの事例を聞いたりもします。
弊社の場合、そのプロジェクトを実際に動かす人たちが上流工程から入るので、その場で15分くらい話をしたらプロジェクトの方針が決まっている、ということもあります。「じゃあ私は来週までにこれを作っておきます」ということで解散したら、来週には実際に出来上がっているというスピード感ですね。
ーーこのスピード感あふれるイメージは、入社される前からありましたか？
清時：
いえ、どちらかというとありませんでした。アルゴリズムエンジニアとソフトウェアエンジニアは社内で開発に集中していて、Bizメンバーがお客様のところに話を伺いに行く、という流れかと思っていました。
ところが、本当に初期のミーティングからアルゴリズムエンジニアもソフトウェアエンジニアも参加しているので、そこはイメージが良い意味で違ったかな、と思っています。
ーー「最後まで寄り添う」という点で、実際にお客様と一緒にこんなことをされた、などのエピソードがあればお願いできますか？
清時：
例えば、最初は一つの環境だけでテストをしたいのでこういうAPIを用意してくれればよい、という話でしたが、途中で「色々な日付を想定してテストをしたくなった」という要望をいただいたことがありました。それで、いくつかの日付でテストするための仕組みが必要になってしまったんです。お客様側で実装するはずが、スケジュール的に間に合わなくなるということで、こちら側の仕組みとして実装をして、結果としてすごく感謝していただいたケースがありました。
一般的なウォーターフォール型の請負開発だと、要件定義でここまでやらなければいけない、ということが決まっています。逆に、それ以上やるのであれば追加料金が発生します。一度決めたところから内容を変えるのが難しいので、後で別の方法にしておけば良かったと思っても、変更できないともやもやしてしまいますよね。
しかし、先程のテスト面の対応をしたことによって信頼関係ができていたおかげなのか、「もっと良い方法を思いついたのですが、これはいかがでしょうか？」と伝えたら「PKSHAさんが良いというのであればそれでお願いします」と言っていただいたことがありました。助け合いというか、信頼構築というか、この人たちが言っているから大丈夫、と思っていただけた時に、やっていて良かったなと感じましたね。
ーーそれは個人的な事情で可能だったのか、それともPKSHA Technologyの方針だからこそ可能だったのか、どちらでしょうか？
清時：
両方だと思います。メンバー1人ひとり技術力の高い方が多く様々な提案が可能ですし、会社としても現場のエンジニアがいいと言うのであればそれでいい、というスタンスなので、エンジニアに任せてもらえていますね。結果としていいものをお客様の手元に届けられているのではないか、と感じています。
ーーそのあたりも、最後まで寄り添って形にすることにつながっていそうですね。
清時：
あとは、本当に成果が出る、お客様のことを第一に考えているのも大きな特徴です。
何十億円もかけて基幹システムを刷新したものの、結果的に中身は何も変わっていない、という業界話を聞いたことありますが、弊社の場合には暗黙の了解として、かけていただいたコスト以上の成果を創出しようという雰囲気があります。実際にそれ以上の成果に貢献できたプロジェクトもありますね。
共存共栄の関係を目指す、そういう空気を私は感じていて、個人的にPKSHA Technologyの好きなポイントですね。
一般的なプロジェクトマネージャーの枠をはみ出して業務に臨む
ーーお話を伺った限りでは柔軟にプロジェクトに取り組まれている印象なのですが、そのプロジェクトマネージャーとしての業務はどのようなものでしょうか？
清時：
誤解を恐れずに言えば、一般的なSIerのプロジェクトマネージャーから営業の要素が減り、アプリ実装やインフラ構築が増えた、という感じです。『「SIerのプロジェクトマネージャー」 ー 「営業」 ＋ 「アプリ・インフラ構築」』というイメージですね。
最近ですと、DMP（Data Management Platform）の構築や、データをきれいにグラフで見られるように可視化するダッシュボードを作るといったこともしています。あとは教育関係で、生徒の達成度に応じて問題を提示するアルゴリズムがあるのですが、そのAPIの部分のコーディングなどもしています。私はプロジェクトマネージャーの立場ですが、コアとなるアルゴリズム以外の部分を私が一人で書くこともあります。
ーーかなり手を動かされているんですね。
清時：
はい。あとは要件定義や、委託先のベンダーの選定、契約関係など、通常のプロジェクトマネージャーとしての業務もしています。
PKSHA Technologyにおけるソフトウェアエンジニアのソリューション担当チームには、ビジネス寄りの人と開発寄りの人がいます。開発寄りというのは、お客様とのミーティングに出席しつつ、普段は開発や新しい技術の調査研究などR&D的な業務をしている人のことです。私は前職の経験もあり、どちらかと言うとビジネス寄りですね。しかし、開発がゼロということはなく、一般的なプロジェクトマネージャーの役割を7割程度しながら、3割程度は開発を担当しています。開発寄りの人の場合は、ミーティングなどに3割程度の時間を割いて、残りを技術の調査や検証にあてています。
人によって割合が違い、私のように開発が3割という人がプロジェクトマネージャーと呼ばれているイメージです。
ーーなるほど。人によって業務の配分が変わるんですね。役割が決まっている組織が多いなか、とてもフレキシブルな開発環境ですね。
清時：
はい。アルゴリズムエンジニアだがソフトウェアエンジニアの仕事もできてしまうので、ここは私が書いておきますね、という人もいたりします。逆にBizメンバーでありながらGitHubリポジトリを持っており、他社からエンジニアスカウトが来た、みたいな人も。自分もビジネスとソフトウェアエンジニアの真ん中のようなポジションですしね。
ビジネス、アルゴリズムエンジニア、ソフトウェアエンジニアのどこかに軸足があるものの、皆、好き放題その領域からはみ出ていますね。また、評価の基準が明確で、スペシャリスト枠のための基準、そしてはみ出した人向けには、はみ出したことも考慮された形での基準があるので、突き詰めたい人は専門をとことん突き詰められるし、はみ出したい人はどんどんやりたいことをできる、そこがいいなと思っています。
▲マネジメントだけでなく実際に手を動かすことも多い清時さん
PKSHA Technologyの魅力は視野を広げて成長できること
ーーこれまでにお話いただいている部分と重複するかもしれませんが、開発の視点から、PKSHA Technologyの魅力的な点はどこでしょうか？
清時：
まず、先程挙げたスピード感、あとはまっさらなところから立ち上げる機会があるのも推しポイントです。まっさらなところから、というのは多くの会社でレアなプロジェクトだと思いますが、弊社の場合にはイチから初期構築を行う案件が大量にあります。日本全国で見ても、こんなまっさらなところから色々と自分で決めて作る実務経験を何周も積めるのは、PKSHA Technologyを含めて数社くらいなのではないかな、と思っています。
ーーたしかに、なかなか体験できなさそうですね。
清時：
SIerではなくWeb系の会社などでも、設定ファイルはあるから手順に従って進めるだけなど、ブラックボックス化したシステムを利用するケースもあると思います。ある意味ではこれまでの努力の結果として、あまり労力をかけなくて済むようになったわけですが。
自分たちで中身にしっかりと取り組み、そして最終的には設定だけで自動的に作業が進むようにすることをチーム内で「型化」と呼んでいます。PKSHA Technologyの場合、今まさに型化をしていこうというフェーズです。そういうところに取り組めるのも、魅力的なポイントですね。
ーーなるほど。単に決められたところを開発をするわけではない、そこに面白さや魅力があるわけですね。
清時：
加えて、色々な業界のビジネスサイドの悩みごとを実際に聞けて面白い、というのもあります。
大きな会社に入ると部署ごとに顧客が固定されていて、例えば10年間保険関係をやっています、こちらは10年間流通関係をやっています、ということも多いようです。PKSHA Technologyの場合は、本当に様々な業界のお客様がいらっしゃるので、例えば自動車が好きな人であれば関連する案件に手を挙げることもできます。業界ごとに違う雰囲気を感じたり、逆にどの業界にも共通する点が見えてくるので、その共通のところの型化を考えるのも面白いです。
また、先ほどと重複する部分もありますが、例えばプロジェクトマネージャーと言っても手を動かせて技術的な部分を伸ばすこともできますよ、という広がりもあります。単純に技術が好き、ソフトウェアエンジニアリングが好きで、土日も趣味でプログラミングに取り組んでいる人も多いです。そのような環境なので、「わかりません」と声を上げると気軽に皆が集まって教えてくれますね。
また、Bizメンバーが「このAPIはどういう仕組みなんですか？」と聞いてくれることもありますね。エンジニアもお客様とのミーティングに出るので、雰囲気や課題・要望を知った上で開発を進められますし、エンジニアマネージャーも全員コードを書けるので、現場の悩みや苦しみをわかったうえでのアドバイスをもらえます。「この方針でいきましょう」となったら、途中で「実は賛成していなかった」と言い出すような人がいない、全員で走っていく雰囲気もいいなと思っています。
ーー価値のあるシステムを作り上げにいく、という点では役職に関わらず、全員が同じ方向性を持って取り組まれているんですね。
清時：
はい。エンジニア全員が最初からクライアントとのミーティングに出る会社は少ないかもしれないのですが、PKSHA Technologyでは初回の挨拶のような段階から全員参加することも多いので、空気感を共有して開発をしている部分も特徴であり、魅力だと思います。
プロジェクトマネージャーの苦労とやりがい
ーー今、プロジェクトマネージャーとして抱えている課題はありますか？
清時：
あえて挙げるとしたら、勉強し続けなければいけないことですかね。それが嫌だとは思っていないのですが、勉強を止めると大変なことになるな、という危機感はあります。
Bizメンバーから「エンジニアリングの部分でわからないので教えてください」と聞かれることもあり、その際に私がアルゴリズムエンジニアの担当者と話すのですが、会話についていけないなんてことがあってはならない。橋渡し役不在でイメージがずれてしまうと、メンバーの能力はあるのにプロジェクト進行がよれてしまうこともあるため、勉強をし続けることが必要です。
あと課題とは少し違いますが、プロジェクトマネージャーの人数が単純に少なくて苦労しています。案件数はかなり多いのに、コードを書くプロジェクトマネージャーの人となるとやはり数が少ないので……。チーム全員が型化やプロダクト化といった新しい挑戦に集中できる環境を維持するために、調整タスクなどは極力分散して低負荷な状態を保ちつづけたい。そのために仲間が欲しいというのが一番の希望ですね。
ーー一ありがとうございます。今は苦労している点を挙げていただいたのですが、反対にやりがいを感じるのはどんな時なのでしょう？
清時：
自分が案件に関わって、うまくプロジェクトが回り始めたときですね。
先ほど「橋渡し役として勉強し続けることが大切」だとお話ししたことにつながるのですが、例えばエンジニアとBizメンバーが打ち合わせをする際、お互いの不明点が多く話が全く進まないといったシチュエーションも珍しくないですよね。そういった時に自分が入っていくことで不明点を解消し、話をまとめることでメンバーそれぞれのやるべきことが明確になり意識が揃いはじめるんです。そうすると、お客様との打ち合わせの場でも堂々と説明できるようになるので、最初は不安そうにしていたお客様がだんだん笑顔になってくれるんですね。プロジェクトを成功させるには、信頼関係を築くことが必須ですし、お客様からの信頼を得られた時にプロジェクトマネージャーをやっていて良かったなと思います。
プロジェクトマネージャーがいなくても、仕組みを作って型化することでプロジェクトが回っていくのであれば、組織としては一番理想的だとは思います。しかし、新しいことをやりたいとなると、大抵の場合はこれまでの仕組みのままだとうまくいかない。なぜなら新しい課題が常に出てくるようになるからです。そうしたときに、自分がプロジェクトに関わることで仕組みを作り、生まれた時間で新たなチャレンジをし、また課題が出てきたら仕組みに落とす。そうしたサイクルを回していき、組織として新しくできることが増えていると実感できたときに、プロジェクトマネージャーとしての達成感があります。
ーーちなみに関係構築～納品まで、どのくらいのスパンで回っていくのでしょうか？
清時：
案件にもよりますが、3ヶ月～1年くらいです。中には信頼関係を深めたことにより、単発のプロジェクトではなく、何年も一緒にやらせていただいているケースもあります。
ーーなるほど。3ヶ月～1年くらいの期間で、その体験を常に回し続けるというのは、ある意味では大変さと面白さを両立させられて、素敵な環境ですね。
PKSHA Technologyの働き方に合う人
ーー最後に、どんな方がPKSHA Technologyに合っているかどうかをお願いします。
清時：
PKSHA Technologyには3つのバリューがあります。このバリューに合致する人が合っていると思います。
一つ目は「Be proactive for the future（未来に先回りし、ポジティブな業界進化を仕掛ける）」。自分なりの解釈だと、本当に効果のあるものを作ること、お客様もこれで加速するというものを作ることですね。それを皆が思って、実際に取り組んでいます。
二つ目は「Credit cycle for building network Intelligence（信頼のうねりを外界に作り出し信頼のハブになる）」。一生懸命やることで、あの人だったら大丈夫、と信頼される人たちの集団になるということです。お客様からの評価ももちろんですが、社内でも、あの人はきちんとやってくれる、相談したらちゃんとやってくれる、というのは実際にあるなと感じています。
三つ目は「Learning machine for multi specialty（専門性の連鎖を通じ、自らをアップデートし続ける）」。実際に皆が個人個人で勉強をしていて、自然と「こんな新しい技術が出ましたね」などが雑談として出てきたりします。
社内には、これら3つのバリューに当てはまっている人が本当に多いと感じています。
ーー先程までの実際の業務に関するお話からも、それは感じました。
清時：
あとは、皆でいいものを作っていきたい、作ったら面白い、と楽しめることでしょうか。コードを書く作業は個人的なものだと思われがちですが、静かに熱い、確かな一体感、連帯感みたいなものがありますね。
例えば雑談をしているなかで、これをあの会社のサービスと結びつけるとすごく良さそう、となれば、ではアポを取りに行こう、とすぐにアクションにつながることもあります。または、ひとまず作ってみようとなって、来週から週2回、時間をとって書いてみようかと動き始めてみるということも。
プロジェクトが一つ終わったら、全員で打ち上げにいったりもします。そういう雰囲気が好きな人は合うのかな、と思います。
ーー最後に転職を検討している方に向けて、メッセージをいただけますか。
清時：
働き方の観点について、プロジェクトマネージャーの立場からコメントさせていただきます。
現状ありがたいことに、沢山のお声がけをいただき開発を進めているのですが、人手が足りていません。
「コードを書けるプロジェクトマネージャー」という点をずっと言ってきましたが、これからぜひ書きたい、勉強やります、という人はぜひ来ていただきたいですね。私がまさにそうでしたから。私のように書けるところまで引き上げてもらうこともできます。
逆に、もともとソフトウェアエンジニアだったけれど、要件定義に興味がある、エンジニア組織をこうすればもっとうまく回るはずといった思いがある、などの人も大歓迎です。
