TISが新規事業開発の失敗から学んだこととは
続いて佐藤氏より、実際の開発現場の様子と、実践から得た気づきが紹介された。
「開発当初、新規事業開発では、とにかくスピード感が重要だと考えていた」という佐藤氏。スピード感を最優先に、SPA +REST APIを基本として、以下のアーキテクチャを採用したという。
- フロントエンド：TypeScript、React
- バックエンド：Java、Spring Framework
- インフラ：AWS（CloudFront、ECS、RDSなど）、Terraform
- その他：GitLab、AWS CodePipeline
そしてドキュメントは「ある程度は作るけれど、それ以上は作らない」ことにして、以下の最低限に絞った。
- プロダクトバックログ：スクラムでは非常に重要。作らないという選択肢はなかった
- ユーザーストーリーマップ：スクラムでは非常に重要。作らないという選択肢はなかった
- 方針設計：至極簡単なものを作成。デザイン制約、ログ、エラーレスポンスについて記載した資料が残されていた
- ER図：これがないとかなりつらい
- 画面仕様書：これがないとかなりつらい
テストも同様に「ある程度はやるけど、それ以上はやらない」を基本方針として、以下に限定して行った。
- ユニットテスト：完璧ではないが、それなりに書いた。CIで自動テストを実施
- E2Eテスト：人間の打鍵によるテスト。画面が複雑すぎて、テスト作成自体が大きな負荷となると考えたため、自動化はしていない
- 業務シナリオテスト、性能テスト、ロングランテスト：リリース前に実施
- セキュリティテスト：リリース前に実施（アプリケーション、インフラともに）
チーム組成では、いつもの受託開発と同じように、フロントエンド・バックエンド・インフラの3つのチームに分離して、各チームで作業を進めていくことにした。
最終的にこのプロジェクトがどうなったのかといえば、半年ほどがんばったが、結局リリースを諦めることになってしまったという。「とはいえ、たくさんの反省点が見つかり、良かった点も分かった。次回以降、どうしたらうまく開発を進められるか、新規事業を成功させられるかを考えるには、いい機会になったと前向きに捉えることにしている」と佐藤氏は述べる。
佐藤氏が挙げた3つの気づきと、その要因を見ていこう。
- スピードが大事なはずなのに、結果として多くの時間を無駄にしてしまった（反省点）
→バックエンドやフロントエンドといった領域でチームを分けたことが分断につながり、コミュニケーションロスを引き起こしていた。スピードを最優先にしたことで、できるところから作ってしまい、価値を出すべき部分が後回しになってしまった。社内手続きが意外と大変で、何にどのくらい時間がかかるか予測できていなかった。
- 課題を解決することが目的なのに、リリースすることが目的になってしまっていた（反省点）
→その機能がどんな課題を解決できるのかを考えずに作ってしまったことで、価値の低い機能ばかり先にできてしまい、価値の高い機能がリリースに間に合わなかった。言語化が不足していて開発メンバーに「その機能で何を解決したいのか」が浸透していなかった。
- TISという会社で新規事業を行うメリットがあることに気づけた（良かった点）
→いろいろな専門家が社内にいることが分かり、助けてもらえた。いろいろな分野に精通したエンジニアも社内にたくさんいるため、部門を問わずナレッジコミュニティを通じて質問・回答・議論ができた。既存顧客とのつながりが多く、「◯◯について解決したいお客さまはいませんか」と投げかけると、他部署の人が既存顧客を紹介してくれて、実際に話を聞ける機会を持てた。社内で新規事業を応援する流れが少しずつ広がり、一部の手続きを簡略化することができた。
「これまで新規事業開発は懐疑的に見られていたが、以前に比べると『なんかいけそうじゃない？』という雰囲気が広がってきた。やはり新規事業開発を阻む壁はあったが、すべてが崩せない壁ではないと分かったことが何よりも大きい。いろいろと失敗もあったが、これからもFintanで気づきを共有しながら、今後もアップデートを続けていきたい」と佐藤氏は抱負を述べた。
