スクラムは子ども電車に例えると理解しやすい──安全運行は誰の責任か
アジャイルのトレンドに関する調査（15th State of Agile Report）によると、アジャイルを導入した企業がアジャイルの効果として挙げているのが、上位から順に「優先順位の変更」「見える化」「ビジネスとITの整合」だ。開発というよりは、ビジネス視点でのメリットが目立つ。
Graat（グロース・アーキテクチャ＆チームス株式会社）の鈴木氏は「あなたの組織でアジャイルは効果を発揮していますか」と問いかける。その場合の確認ポイントとしては、「適切に優先度は変更されているか？」「顧客に提供すべき価値と作られた機能は整合しているか？」「よい成果物を作ることができているか？」だと鈴木氏は言う。
もし効果を発揮していないのなら、それはなぜか。特にウォーターフォールで開発してきた組織ではルールや文化が移行しきれず効果を出し切れていないところもある。
まずはアジャイルで使われる、スクラムの仕組みの理解を深めていこう。鈴木氏によると電車で理解すると分かりやすい。電車は、遊園地やイベント会場で子どもが乗る電車だ。駅は1つ。子どもを乗せて1周して戻ってきたら、駅に並んで待っている子どもを載せ替えて、再び1周するのを繰り返す。ただし子ども電車と異なるのは、次の発車までの間に待ち行列にいる子どもたちの順番を入れ替えてもいいルールだ。
電車をスクラムに対応させると、電車の1周がスプリントであり、一定の開発期間にあたる。電車に定員があるように、スプリント中の作業量には上限がある。子どもたちはバックログアイテム、案件そのものだ。この電車の運行を支える存在もいる。子どもを優先順で並べる駅長（順番を入れ替えてもいい）はプロダクトオーナー、運転士は開発者、運行管理者はスクラムマスターとなる。このスクラムマスターは、例えば線路に落下物など問題が起きたらすぐに介入して障害を取り除くとか、ホームで泣いている子どもがいたら駅長をサポートするなどを行う。
スクラムのメリットで重要なのは、走っている電車はホーム（に並んでいる子ども）を気にしなくていいところだ。今やるべきことと、これからやりたいことが分離しているとも言える。そのため開発者は開発に集中できて、ビジネス側は次の電車が来るまでは優先順位を好きに変えてよい。
例えば、バックログで案件A、B、C、Dがあったとする。最初のスプリントでは案件AとBを乗せた。バックログには案件CとDが残っていたが、緊急度の高い案件Fが最優先となり、案件Cは不要となった。そうして次のスプリントでは案件FとDが乗るという具合だ。開発者たちは現在乗っている案件に集中すればよくて、次の案件は気にしなくていい。
ところがウォーターフォールだと、こうならない。最初に全部の機能を決めて最適なルートを決めるので、スクラムのように案件の優先順位を変更するとなると大騒ぎとなる。その点、スクラムは柔軟だ。
スクラムという電車を安全に運行させるには、ルールを守り子どもたちを電車に乗せること。乗りたい電車の出発時刻までに間に合うよう、駅に到着する。これはリリースしたいスプリントまでに要件を提示することを意味する。また、開発可能な状態まで、要件が明確になっている。そして電車では、飛び乗りや飛び降りは禁止だ。
電車を安全に運行させるのは誰の責任か。子どもに責任はない。責任があるのは親や周囲の大人たちとなる。子どもを無理矢理電車に乗せようとしたり、乗る準備ができていない（要件が決まっていない）のに乗せたりすると安全ではなくなる。
大企業でアジャイルを邪魔する組織に関わる問題
もし組織でアジャイルがうまく効果を発揮していないとすれば、チームの周辺にある問題がアジャイルを邪魔している可能性がある。今回は6つピックアップする。
組織の意思決定サイクル
スクラムガイドではプロダクトオーナーが決定者であり、組織はその決定を尊重すべしとあるものの、日本の意思決定モデルにおいては大組織のプロダクトオーナーが意思決定するのは難しい。良い悪いではなく、そうなってしまうのが現実だ。多くの部署が関わるシステムであればステークホルダーが増え、合意形成が必要になる。
また、アジャイルのサイクルと稟議や経営会議での承認のタイミングが合わないと、リズムが崩れる。例えば「次の部門長会議は再来週だから、それまで開発は進められない」「あの部長はOKと言ったから進めたのに、別の部長はNGで覆されてしまった」などが起きる。
業務との調整と基幹システムとの連携
大組織のDXはIT部門だけでは進められず、業務部門との調整が必須となる。また顧客データやマスタデータなど、新しいサービスに必要かつ価値があるデータは大抵基幹システムに格納されているため、連携が必要になる。基幹システムはウォーターフォールで開発されているため、アジャイルとタイミングが合わずに苦労することがある。
プロダクト構成とチーム編成
「組織が設計するシステムは組織のコミュニケーション構造を反映する」というコンウェイの法則が示すように、過去の組織構造がプロダクト構成やチーム編成に反映されているため、現在のビジネスとミスマッチが起きていることがある。チームが増えれば増えるほどチーム同士の会話も難しくなる。
品質保証
いいプロダクトを世に送り出すためにも、品質保証のためのプロセスは大事だ。ただし、大企業で品質保証のプロセスが開発完了後でないと始まらないとなると、素早いリリースを妨げることになる。
スプリントが完了したものの、その後に経営会議や様々な手続きがありリリースまで時間がかかってしまうケースもある。また品質保証のプロセスでバグが発覚すると、緊急案件となり「電車の飛び乗り」のような禁じ手も起きてしまう。鈴木氏は「品質保証はすごく専門性が高い仕事だが、理解されていないとテストチームに丸投げされてしまい、ボトルネックになってしまうことがあります」と指摘する。
中長期計画と予算管理
企業には中長期計画がある。中長期計画でゴールを定め、そのゴールを実現するために機能を確定させ、その機能に予算承認が下りるように、機能の完成（QCD遵守）をゴールとして計画するとウォーターフォール型になっていく。「何をやるか分からないものに予算は付けられない」となってしまう。これは予算管理だと、請負契約（ソフトウェア資産）か準委任契約（経費）にするかなどによっても変わってくる。
成果の評価
システムがもたらした成果をどう評価するか。機能の提供をゴールとすると、機能がもたらす価値は評価されにくい。MVP（実行可能な最小限の機能群）から開始して、機能追加で価値を積み増していくアジャイルの概念が理解されないためだ。
成果はデータで定量的に評価されるべきところもあるが、数字で示せるものだけが成果とは限らない。しかし評価のための機能開発は認められず、成果を認められなければアジャイルを展開していくのは難しくなる。
アジャイルを推進していくためのポイント
それではどうしたらいいか。よく海外文献では「チームに権限を与えればいい」という解決策が提案されることがあるが、鈴木氏は「日本ではなかなかそうはいかない。既存事業や資産を最大限活用するなら、既存組織にもリスペクトが必要です。組織を変える必要はありますが、破壊してはいけません」と指摘、次の4点を提案する。
アジャイルのリズムを決める
アジャイルのリズムを経営のリズムに合わせる。例えば四半期で成果が見えるように開発することが大事になる。具体例としては、業務調整を含む新機能のリリースサイクルは四半期ごとにし、既存機能の改善や追加は月次、ちょっとした修正などの保守は週次、緊急の障害対応は随時という具合のサイクルにする。
サービスデザインに取り組む
DXは顧客価値に注目することが大事だ。つい機能や仕様に目が向きがちだが、顧客や従業員に提供する価値に目を向けて、どのように実現するのかが本筋だ。そのため鈴木氏は「顧客体験と業務とIT機能を同時に語る」ことの重要性を強調する。モデル化することで実現性の確認をして、モデルを全ての部門で共有していくことを実践するのが大事になる。
DevOpsをちゃんとやる
DevOpsはインフラと運用のセルフサービス化であり、開発者と運用部門・インフラ部門の間をシームレスにつなげるものだ。開発者が運用部門に申請することなく、インフラ構築や運用ができるようになりスピードにつながる。開発と運用がうまく連携できていれば自動化ツールの整備も進む。
プラットフォームを整える
マイクロサービスなどモダンな手法を使うにはプラットフォームが必要になるため、新たな標準化の形を整えていく必要がある。部門ごとに個別にクラウド導入していてルールがばらばらであれば、新しい標準化の形にプラットフォームを整えていく必要がある。このプラットフォームは基幹システムとの連携の中継地点となり、基幹システムの機能切り出しなど段階的にモダナイズするための場所にもなる。
これまで述べてきた問題領域と、それに対する解決策については、Graatではエンタープライズアジャイルの問題領域として、組織レベルのアジャイルを実現するモデルを提唱している。
最後に鈴木氏は、「チームを取り巻く課題を解決するには、チームだけの問題にするのではなく、組織がちゃんと取り組むべきです。組織として課題解決しようとアプローチするようになると、いろんなことが社内で回るようになります」と述べた。意思決定サイクルから成果評価まで、組織レベルで多くの課題が存在する中、既存組織へのリスペクトを保ちながら、どのように変革を進めていくのか。その具体的な道筋を示した本セッションは、多くの参加者にとって示唆に富むものとなった。
組織レベルのアジャイルの実現に悩んでいる方におすすめ！
Graatが考える【エンタープライズアジャイルの問題領域】に対応する各種ワークショッププログラムの提供や、お客さまのニーズに応じたコンサルティングサービスを行っています。
本記事を読んで興味を持たれた方は、ぜひGraat公式サイトからお問い合わせください。
さまざまな課題の対応事例などをご紹介するウェビナーや、各種ワークショップの体験版なども定期的に開催しています！ 最新情報はGraat公式サイトよりご確認ください。
