決め手となったのは4点（多いですが）で、①自分の経験が活かせる、②やりたいことがやれる、③自社でエンジニアを抱えている、④風通しがよさそう、です。①はSolaがBtoBの業務システム開発も行っており、前職の社内SEで事業会社の内部を知っていることは武器になると思いました。②については、社内SEとしてベンダーコントロールを極めてもな…と考えて始めた転職活動だったので、手を動かしてモノが作れるのは魅力的でした。コードも書きたかったけど、ずっとIT業界に身を置いていた割に、プログラマー未経験の35歳だと微妙かもとPMで応募。結局コードは書いてないですけど(笑)。③は面接で会ったエンジニアの技術力が非常に高いと感じ、この技術者レベルなら戦えると思いました。④は経営者が若く急成長しているので風通し良さそうかもと。SIerのPM職を中心に見ていて、選択肢には入れていたものの初期志望度は3番手以降だったので、選考過程で縁を感じたのも大きいです。

PMでありつつ、部の責任者でもあるので、全部と言えば全部なのですが、敢えて挙げるなら2つです。1つ目は反省の残った「物流システム開発プロジェクト」です。ほぼ新規顧客/新規開発にも関わらず、タイトなスケジュールで立ち上がったことで、要件定義を基本設計で吸収しながら進めることになりました。要件の膨張と収束を繰り返しながら、加えてリリース直前に重要な要件を追加せざるを得ず、最終的にはリリース時期を変更することに。2つ目は成功体験となった「ドローンアプリ開発プロジェクト」です。大規模なプロジェクトで、ソフトウェアだけでなくハードウェアもスコープに入ってきたので作るモノも複雑で面白かったですが、PMとしては上流の要件定義が非常にうまくいったことで、品質もプロセスも成功と言えるものであったと思います。共通するのは「要件=プロジェクトのゴール」をきちんと定めることが極めて重要であるということ。お客様も開発メンバーも、皆が迷わないように、面倒なことでも最初の段階で議論に議論を重ねることが必要ですね。

断片的な情報から仮説を立て、必要な要件を組み上げていくプロセスが楽しく、苦労する部分でもあります。お客様はITのプロではない場合も多いので必要な情報の選別をお客様任せにすることは、プロとして対峙する以上無責任です。またお客様にとってあたり前すぎる機能やフローは言及されない場合もあります。それらの検討を漏らしてシステムを開発してしまうと、使えない使いづらい成果物にしかなりません。言われたことを形にするだけではダメで、限られた情報をもとに仮説を立て、自分がリードする形で確認すり合わせを行うことが重要です。入社して途中から参画した販売管理システムの開発プロジェクトで、技術力の高いエンジニアは多いものの、ビジネスロジックをお客様と詰めきれておらず、残された期間の中でリカバリする必要があった時は大変でした。こうした反省が、今のSolaの開発スタイルや基準を作ってきたので、財産といえばそうなのですが、当時はきつかったですね(笑)。

シニアは言うまでもないですが、若手で成長途上の人も含めてエンジニアリソースが豊富なことはビジネス上の強みだと思います。あと入社前に感じていた風通しの良さは、想定以上に良くて、意思決定も即断即決の会社なので大手企業にいた身からすればポジティブなギャップでした。課題は、①エンジニアレベルにまだバラつきはあること、②ビジネス理解はもっと深めた方がよいこと、だと思います。①については育成もそうですし、業務の仕組み化も必要です。②については、顧客の業務の流れやお金の流れを理解することがシステムの要件理解にもつながり、もっと言えば必要なのか不要なのかの判断をすることにもつながってきます。エンジニアといえど業務目的を外さないことが重要ですので、技術に真摯なことは良いことなのですが技術の先にも目を向けて欲しいなと思います。

私自身まだまだ未熟ですが、自分以外にもSolaの中にPM職を増やしていくことです。
事業規模を拡大させるためには、より多くのプロジェクトを対応する必要があり、プロジェクトの数を増やすためには、PM職が多く必要になるからです。そのためにはエンジニアのみならずPMの成果の平準化が必要なので、業務の仕組み化は必須だと感じています。
また部の責任者としては、入社してからの5年間で事業規模がおよそ2倍になったので、次の5年間でも2倍となることを内心目指しています。