本記事は、ソフトウェア開発者向けのオンラインメディア「CodeZine（コードジン）」からの転載記事です（オリジナル記事）。
- 講演資料へのリンク（Fintanのサイト）
なぜ新規事業開発は難しい？
木利氏と佐藤氏が所属するのは、TISで新規事業開発のエンジニアリングを担う「ITER（イーター）チーム」である。ITERチームのミッションは、社内のインキュベーションセンターで次々と生まれる新規事業のアイデアをエンジニアリングの力で形にしていくことだ。社内に広がる「TISで本当にゼロから新規事業を作れるのか？」という懐疑的な雰囲気を打ち破り、多くの新規事業がTISから生まれる状態を実現するとともに、実践の中で得た知見やノウハウを言語化し、価値ある形で形式知化することを狙っているという。
「新規事業開発は基本的に死屍累々になることを運命づけられている分野である」と語る木利氏。成功したところで再現性がない中で、成功率を高めるためには失敗から学んでいくしかない。そこで失敗からの学びを大切にしようと、TISでは「Fintan」というサイトを設立。さまざまなステークホルダーと価値を共有しながら協業するオープンイノベーションを目指している。
「新規事業の何がそんなに難しいのかといえば、不確実性に満ちていることだ」という。どの市場を狙うのか、どんな顧客がいるのか、どんな課題を抱えているのか、どのような課題解決策があるのかなど、あらゆる物事が仮説の域を出ない中で進めていかなければならない。さまざまな方法でこれらの解像度を上げられたとしても、確実ではない中で予算やスケジュール、機能を決めていき、技術選定やチーム組成へとつなげていく必要がある。
そうした中で、「エンジニアリングとは何か」という原点に立ち返らなければならなかった木利氏がたどり着いたのが「エンジニアリングの本質は『不確実性の削減』である」という言葉だった（出典：広木大地 著『エンジニアリング組織論への招待』技術評論社、2018年）。ソフトウェア開発では、市場に溢れた不確実性に向き合うことが避けられない。その向き合うべき不確実性は事業の進展とともに推移していくことから、それにともなってエンジニアリングを変化させていくことは必然であるというわけだ。
そこでTISでは「ステージ・ゲートプロセス」というプロセスを組んでいる。プロセスは複数の「ステージ」から成っており、ステージごとに対象とする不確実性を設定する。そして次のステージへ進む際に、その不確実性の解像度を十分に上げられたのかをチェックする「ゲート」でふるいにかける。「打率の低い新規事業開発では、打席を多くしなければホームランは打てない。見込みのない事業には早期に見切りをつけて、次の新しいアイデアを試していくことが重要だ」（木利氏）
TISが新規事業開発の失敗から学んだこととは
続いて佐藤氏より、実際の開発現場の様子と、実践から得た気づきが紹介された。
「開発当初、新規事業開発では、とにかくスピード感が重要だと考えていた」という佐藤氏。スピード感を最優先に、SPA +REST APIを基本として、以下のアーキテクチャを採用したという。
- フロントエンド：TypeScript、React
- バックエンド：Java、Spring Framework
- インフラ：AWS（CloudFront、ECS、RDSなど）、Terraform
- その他：GitLab、AWS CodePipeline
そしてドキュメントは「ある程度は作るけれど、それ以上は作らない」ことにして、以下の最低限に絞った。
- プロダクトバックログ：スクラムでは非常に重要。作らないという選択肢はなかった
- ユーザーストーリーマップ：スクラムでは非常に重要。作らないという選択肢はなかった
- 方針設計：至極簡単なものを作成。デザイン制約、ログ、エラーレスポンスについて記載した資料が残されていた
- ER図：これがないとかなりつらい
- 画面仕様書：これがないとかなりつらい
テストも同様に「ある程度はやるけど、それ以上はやらない」を基本方針として、以下に限定して行った。
- ユニットテスト：完璧ではないが、それなりに書いた。CIで自動テストを実施
- E2Eテスト：人間の打鍵によるテスト。画面が複雑すぎて、テスト作成自体が大きな負荷となると考えたため、自動化はしていない
- 業務シナリオテスト、性能テスト、ロングランテスト：リリース前に実施
- セキュリティテスト：リリース前に実施（アプリケーション、インフラともに）
チーム組成では、いつもの受託開発と同じように、フロントエンド・バックエンド・インフラの3つのチームに分離して、各チームで作業を進めていくことにした。
最終的にこのプロジェクトがどうなったのかといえば、半年ほどがんばったが、結局リリースを諦めることになってしまったという。「とはいえ、たくさんの反省点が見つかり、良かった点も分かった。次回以降、どうしたらうまく開発を進められるか、新規事業を成功させられるかを考えるには、いい機会になったと前向きに捉えることにしている」と佐藤氏は述べる。
佐藤氏が挙げた3つの気づきと、その要因を見ていこう。
- スピードが大事なはずなのに、結果として多くの時間を無駄にしてしまった（反省点）
→バックエンドやフロントエンドといった領域でチームを分けたことが分断につながり、コミュニケーションロスを引き起こしていた。スピードを最優先にしたことで、できるところから作ってしまい、価値を出すべき部分が後回しになってしまった。社内手続きが意外と大変で、何にどのくらい時間がかかるか予測できていなかった。
- 課題を解決することが目的なのに、リリースすることが目的になってしまっていた（反省点）
→その機能がどんな課題を解決できるのかを考えずに作ってしまったことで、価値の低い機能ばかり先にできてしまい、価値の高い機能がリリースに間に合わなかった。言語化が不足していて開発メンバーに「その機能で何を解決したいのか」が浸透していなかった。
- TISという会社で新規事業を行うメリットがあることに気づけた（良かった点）
→いろいろな専門家が社内にいることが分かり、助けてもらえた。いろいろな分野に精通したエンジニアも社内にたくさんいるため、部門を問わずナレッジコミュニティを通じて質問・回答・議論ができた。既存顧客とのつながりが多く、「◯◯について解決したいお客さまはいませんか」と投げかけると、他部署の人が既存顧客を紹介してくれて、実際に話を聞ける機会を持てた。社内で新規事業を応援する流れが少しずつ広がり、一部の手続きを簡略化することができた。
「これまで新規事業開発は懐疑的に見られていたが、以前に比べると『なんかいけそうじゃない？』という雰囲気が広がってきた。やはり新規事業開発を阻む壁はあったが、すべてが崩せない壁ではないと分かったことが何よりも大きい。いろいろと失敗もあったが、これからもFintanで気づきを共有しながら、今後もアップデートを続けていきたい」と佐藤氏は抱負を述べた。
エンジニアがエンジニアリングすべきはシステムではなく「顧客への提供価値」
このように失敗から多くを学んだTISが、これからどう新規事業開発に取り組んでいくのか。木利氏は「われわれエンジニアやデザイナーの中にある『「何を作るか」を人任せにする姿勢』こそが、新規事業開発を阻む一番の要因だと考えるに至った」と語り、その背景について、次のように述べた。
「新規事業開発ではスクラムをよく利用する。われわれは、『プロダクトオーナーは事業責任者しか担えない』という先入観を持っていた。つまり、『事業価値を最大化する責務は、われわれにはない』という前提が無意識のうちにできあがっていたのだ。
しかし、われわれの本来のミッションは、事業を成功に導くための戦略を描くことであるはず。エンジニアは要件をシステムに変換するコンバーターではない。エンジニアが作るべきものはシステムではなく『顧客への提供価値』であることを肝に銘じ、『「どう作るか」の前に「何を作るか」、「何を作るか」の前に「なぜ作るか」』を強く意識しながら、実現すべき要件を自ら定めていく姿勢を大切にしたい」。
こうした考えのもと、TISでは複数の事業でエンジニアがプロダクトオーナーを務めるようになっており、「俺たちが価値を創り出して、ビジネスサイドに『これをガンガン売って来い』と言えるようにする」と豪語するエンジニアも生まれてきているという。そんな事業価値にまで踏み込むエンジニアの挑戦は、Fintanで継続的にチェックしていただきたい。
