「他部署との調整なんて」と気乗りしない自分を動かした、泥臭い先輩の背中
その後、もっち氏が「価値を届けること」へと仕事の向き合い方を変える決定打となったのは、業務外で取り組んだ社内トイレの混雑問題を解決する改善活動だった。距離センサーを使って空き状況を自席のWebブラウザから確認できるシステムで、開発自体は簡単だったため、すぐに形となった。しかし、いざ会社で実際に運用しようとした途端、開発面以外の課題が数多く表面化したのだ。
個人が持参した「Raspberry Pi」を会社の資産にする手続きや設置許可の申請、さらには総務や社内のIT部門、警備担当者との度重なる交渉など、開発とは関係のない泥臭いタスクが多く立ちはだかった。
ここでも最初は「他部署との調整なんて自分の仕事じゃないのに……」と気乗りしなかったが、チームの先輩エンジニアが積極的に他部署と交渉し、課題を次々と突破していく姿を目の当たりにする。「泥臭い調整を率先して引き受けていく先輩の姿が、ものすごくカッコよかったんです」ともっち氏は語る。
価値をユーザーへ届けるためには、コードを書く以外にも大事なことがたくさんある。そのことに気づいてからは、視野が狭かったあのころの自分を反省し、他のエンジニアや異なる職種のメンバーを心からリスペクトできるようになった。
それから、もっち氏の仕事への向き合い方は大きく変わった。「やったことがないから」と拒絶するのではなく、価値提供に必要な手段であれば何でも貪欲に面白がってやってみる。ここから、器用貧乏エンジニアへの道が始まったのだ。
胃が痛むようなつらさを感じた、資産滅却の教訓
その後、もっち氏は機械学習を用いた新規プロダクトの立ち上げに参画。初めて開発提案し、自ら予算を取りに行く役割を担った。苦手な数学の数式と格闘しながら、アルゴリズムやデータ分析、ターゲットのドメイン知識を必死に勉強した。しかし、プロジェクトの規模が大きくなるにつれ、これまで経験したことのないプレッシャーが重くのしかかる。さらには見積もりの甘さから、追加費用分の提案をしなければならなくなり、非常につらい状況に陥った。
ほかにも契約書の文章作成から、インシデント発生時のエスカレーションフローの策定、ニュースリリースの文面検討まで、プロダクトを世に出すために求められる役割は何でもこなした。
そうした奮闘の結果、顧客からは度々引き合いもあり、有償でのPoC（概念実証）までこぎ着けたものの、最終的な本導入には至らなかった。顧客は、機械学習プロダクトに「100点満点の精度」を期待するが現実的には難しく、それが導入見送りの理由となった。さらに、現場の視点ばかりに気を取られ、顧客となる大企業の中でどのように稟議が通るのかといった、「意思決定者や予算決定者」のプロセスが見えていなかったことも要因だった。
そして、立ち上げから数年を費やしたプロダクトは最終的に資産滅却、つまりソフトウェア資産を捨て、中止となってしまう。もっち氏は言葉にできない悲しみを味わった。
「最後はさすがに結構思うところがあって、悔しかったです。失敗するにしても、もっと早く失敗に気づいて方向転換できるアプローチをすべきだったと思っています」と、もっち氏は振り返る。
この大きな失敗体験こそが、きれいごとだけではない、現場の生々しいリアルな教訓として昇華されたのである。
