2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。
エンタープライズアジャイルとは
「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。
弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。
- 顧客は日本企業で社歴が数十年以上
- システムはいわゆるSoE領域（間接的にでも売上に寄与する）
- 10人ぐらいのチームが継続的に維持される規模
こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。
フィードバックサイクル
企業システムではリリースサイクルを「3ヶ月定期」にするのがいいと考えています。3ヶ月という期間は、
- 現場と話し合って成果を作り出すための最短期間
- 経営層として成果を評価できる最短期間
- 上記をやりながらシステムを開発するための最短期間
というような意味を持っています。つまり、日本企業の中で現場や経営層と合意形成しながらシステム開発する最短期間が3ヶ月なのです。ざっくりしたスケジュールとしては設計1ヶ月、実装1ヶ月、受入1ヶ月となります。
3ヶ月といっても顧客にとっては慌ただしく過ぎていきます。前半は企画して見積もりして部署間調整。中盤になって開発に入り始めたら説明資料を作り営業に説明に行きながら機能詳細を詰めていく。終盤は受入しながら経営層向けの説明資料を作り、リリース向けの広報作業、さらには前のリリースの評判をヒヤリングして次の企画の優先順位を考え始めなくてはいけません。そして、いざリリースされると次のサイクルが始まっている中で現場からのQA対応もしなくてはなりません。これは、なかなかタフなのです。
上記のような3ヶ月定期的リリースをしてみて感じたメリットは以下の通りです。
- スケジュールが決まっているから締め切り駆動で物事が進められる
- 「次のリリース」が決まっているから要件の押し込みが発生しにくくなる
- リリース時に経営層のレビューをするから「成果に結びつく機能は何か」という優先度判定になる
- 他の部門や経営層から確実なフィードバックが得られる
この3ヶ月間はプロセスは手続き的に進んでいくのでウォーターフォール風な側面も持ちます。中間成果物もドキュメントだったりするので動くソフトウェアというわけではありません。ただ、3ヶ月間の日程とリソースが先に決まっています。なので、僕としては3ヶ月イテレーションという言い方が適切に感じています。
プロダクトオーナー
こうした案件ではプロダクトオーナー、つまり、他部門にまたがる要件を取りまとめ優先順位付けをする役割が非常に重要です。
一般的な定義のプロダクトオーナーはシステムの受益者であるユーザーと開発チームの仲立ちであり、その両者にアプローチすることが求められます。
しかし、日本のエンタープライズでは特に
- 会社組織の意思決定プロセスの促進
- 社内の現場部門との調整
といったことが強く求められます。
つまり、日本企業では「POとしての判断」というのがPO個人ではなく「組織的に行われるもの」であり、POはその判断を促進するファシリテーターのような機能が必要になります。つまりPOには強力な組織内調整能力が求められるのです。
ところが「ビジネスも理解し、開発の言うことも分かり、経営層にもパスを持ち、現場に対する交渉力も持つ」なんていうスーパーPOはなかなかいません。
なので、実体としては「リードPO」のような人がいて、あとはそれぞれの役割を数名の人が集まって実現する形になることが多いように思います。
リードPOにもっとも必要なのは「想い」です。このプロダクトをこうしたい、これが会社として目指すべきものだ、という熱い想い。それがあると周りが協力してPOとして機能します。例えば上司が経営層とのパスを調整してくれたり、別部署の同期が相談に乗りながら調整方法を考えくれたりといったことです。
こうした活動をする中で成果と機能のバランスや、社内で何が求められているのかを理解していくことで成長していくことができるわけです。
ちなみに「そういう日本企業の組織的判断ってやつが無駄なんだ」というのは、半分は理解しつつも、それを言い訳にしてアジャイルを諦めたくはありません。そういう企業こそ、僕らの生活には欠かせないわけで、少しずつでも改善してもらわないと困るのです。
アーキテクチャ
最後はアーキテクチャです。健全にプロセスが機能するためには、それを保証するアーキテクチャが必要です。簡単に言うと他の機能から独立してリリースできる、ということです。
情報分析系システムなどはデータの終着点なので、そもそも他システムに対して疎結合になります。しかし、オンラインシステムでは簡単にいかない場合もあります。
弊社の事例では、そういった際にアプリ分割を行なって既存機能との疎結合化を図りました。社内では心臓外科手術なんて言ってましたが、モノリシックなシステムの一部を切り取り、まっさらな別のモジュールにした上で認証機構は共有できるようにしましたです。術後に小さな障害はあったものの経過は順調で、想定通り、その部分だけは独自にリリースが可能になりました。
技術的な側面としてはCI/CDや自動テストなども段階的に導入されています。ただ、それは導入が目的というよりも、リリースを頻繁にする際にデプロイ手順の自動化や面倒で複雑なテストケースの自動化をやってないと「やってられん」というチーム内の素直な動機です。方法論さえ事前に理解しているなら「困ってから対応する」というほうがチームの導入モチベーションも上がるので悪くないことだ思っています。
なお、これがマイクロサービスアーキテクチャに繋がっているのは言うまでもないでしょう。アジャイルといっても、個別の機能によって適切なリリースサイクルは異なります。よって機能感を疎結合にし、それぞれが独自のサイクルでリリースを可能にすることはとても大切なのです。
まとめ
エンタープライズアジャイルが何であるかはよく分かりません。ただ、僕としてはアジャイルの原則に従い、顧客と対話しながら、適切なフィードバックが得られるようにしているだけです。その結果が以下のようなことです。
- フィードバックは3ヶ月定期リリースにするこで経営層や現場から得られるようにする
- プロダクトオーナーは顧客や開発だけでなく、経営層や現場ともやり取りをして判断を促進する
- アーキテクチャは適切にプロセスが回るように疎結合を実現する
こう書くと当たり前のことですよね。でも、それでいいんだと思います。
僕はどの案件でも「アジャイルを導入しましょう」と言ったことはありません。むしろ、言いたくない。
案件の背景と顧客の要望に応えるための手法がアジャイルであるかはどうでもいい。ただ、結果的にアジャイルな要素を含んでいる、というだけです。手法は道具です。それぞれの現場に必要な道具を適用して、当たり前なことをひとつひとつ積み重ねていくのが大事だと思っています。
資料は以下から。
