デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。
「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。
なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。
失敗1:半島型
新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕組みに強く影響を受けてしまい、「これまでのやり方」を違う名前で取り組みだけになってしまい、実質的に意味がない状態になるからです。
たとえばリリース日と機能スコープが確定している状態で、日々のマネジメント手法だけをスクラムにする状態です。このような取り組みの場合、プロジェクトリーダーをスクラムマスター、週次定例をスプリントレビューと呼び替えているだけで、実質的な考え方は何も変わりません。
しかも、スクラムのようなアジャイル型のマネジメント手法は、全体ゴールが確定した状況には適さないので、むしろ、手法としてはアンマッチです。この状態で「アジャイルはうまくいかない」と評価するのは間違いです。
システムの再構築でマイクロサービスに取り組むのも似ているでしょう。機能配置を変えないまま、ただ単に機能をサービス化しても、密結合な分散システムができあがるだけです。ネットワークオーバヘッドの分だけ性能は劣化し、サービス間のデータは不整合だらけで使い物になりません。
失敗2:孤島型
では、これまでの仕組みと完全に分離してしまうのはどうでしょうか。たしかに「これからのやり方」は機能するかもしれませんが、ビジネス価値を高めるのは難しいでしょう。なぜなら、その企業にとって重要なデータやプロセスは「今までの仕組み」で管理されているからです。
重要なデータやプロセスに関わらないでビジネス価値を高めるのは困難です。
アジャイルはビジネス価値を上げていくために、顧客からのフィードバックを受けながら安全に開発対象を変更するための手法です。生み出すビジネス価値が低い、つまり、あってもなくても良いようなシステムは、開発すべき機能も曖昧になり、アジャイルのメリットは活かせません。
マイクロサービスで新しいサービスを作っても、それが基幹システムとの通信を許可されない、個人情報や過去の履歴情報も扱えないなら宝の持ち腐れです。そもそも、ビジネス価値の低いシステムはモノリスで作っても、たいして変わらないでしょう。なぜなら、変化への要求が少ないからです。
成功には出島型
そこで「意識的に分離し、意識的につなげる」ことが必要になります。つまり、アジャイルやマイクロサービスがきちんと機能する場を用意しながら、今までの仕組みの中にあるデータやプロセスを利用できるようにするのです。
そのためには「今までの仕組み」は維持することを前提に「これからのやり方」とのギャップを埋める取り組みを行うことです。
「今までの仕組み」を大事にするのには2つの理由があります。1つ目は、現状の儲けの大半が「今までの仕組み」で成り立っているのであれば、それを簡単に捨てることはできないという現実的な理由。2つ目は、今までの仕組みとして完成されている資産は、うまく利用したほうが効率的だという前向きな理由です。
講演では、以下の3つの取組みをあげました。詳細については資料を確認いただければと思います。
- スクラムにおける要件の詳細化をどう行うべきか?
- どうすればプロダクトオーナーが決定できるようになるか?
- マイクロサービスに移行するにはどうするか?
アジャイルもマイクロサービスも素晴らしい先人の知恵ですが、その前提となる仕組みがなければ機能しません。「これからのやり方」が機能しないとき「今までの組織やITの仕組みが間違っている」と言うのは簡単ですが、それでは前に進めません。もちろん、組織やITの仕組みを変えていくことは必要ですが、一朝一夕にできることでもありません。であれば、「今までの仕組み」を利用しながら、「これからのやり方」を実践するための知恵が必要になります。
これには「これからのやり方」を学ぶだけでは足らず、今までの仕組みのことも理解し、どうすればよいのかを真剣に考え、周りの人や経営層に働きかけをしていく必要があります。