arclamp

ITアーキテクト 鈴木雄介のブログ

JTCでアジャイルするには組織としての仕掛けが必要

近年、DXの流れでアジャイルが注目されていますが、JTC(日本の伝統的な大企業)では、組織の問題でアジャイルチームがうまく機能しないことがあります。この問題を解決するために必要なことについて整理してみました。なお、 JTCとは「ウォーターフォール型のシステム開発が中心で、そのために部署の分割とルールが整備されており、文化にまでなっている会社」のことです。

はじめに

このエントリは、2023/1/27に開催されたアジャイル経営カンファレンスでの講演「ビジネスとITをリンクさせるアジャイルな組織のつくり方」の内容に補足を追加したものです。資料はこちらから。


なぜ、DXにアジャイルか?

まず、大前提の確認から。経産省のDXレポート2には、

企業が競争上の優位性を確立するには、常に変化する顧客・社会の課題をとらえ、「素早く」変革「し続ける」能力を身に付けることが重要である

という記述があります。DXは単なる業務効率化ではなく、自社の事業を変化に合わせて成長させるための取り組みです。そのため、DXには「変化に素早く対応し続ける能力」が必要です。

一方で、JTCは「安定して効率的に対応し続ける能力」に優れています。何か新しいサービスを開始した場合、そのサービスを広く世に普及させ、安定的に提供することを重視します。そのために裏側のオペレーション業務は部署別に分割し、効率化をおこなってコストを低減し、利益を確保します。

残念ながら、変化に素早く対応し続ける能力」を発揮するにあたり「安定して効率的に対応し続ける能力」が邪魔をすることがあります。下図は両者を比較した絵ですが、それぞれの能力に適した組織やITの仕組みが違うのです。もちろん、右が正解で、左はいらない、ということではありません。JTCであれば左があることが前提で、右に取り組む必要があります。

どちらも重要だが、右のほうが超重要

(今回は組織の話だけに絞りますが、ITの話になるとモノリスとマイクロサービスの両立、という話になります)

アジャイルはタクシーか、電車か

アジャイルは「変化に素早く対応し続ける能力」を発揮するのに有効なマネジメント手法です。まずは、その仕組みを理解しましょう。下の写真*1で、どちらがアジャイルの仕組みに近いでしょうか?

タクシーと電車、どちらがアジャイル的?

タクシーは、一見するとアジャイルです。誰かを運びたい場合、とりあえずタクシーがあれば行きたいところはどこにでも連れて行ってくれます。ところがタクシーには必要な台数を調達するのに時間がかかる、ドライバーのスキルが安定しないといった問題があります

電車のほうがアジャイルの考えに近いです。開発チームという電車と路線を用意し、定期的に運行します。出発ホームには待機リスト(ウェイティングリスト)があって、電車が来たらリストの上から満員になるまで乗車してもらいます。そして、電車が出発したら飛び乗りも飛び降りもしてはいけません。危険ですよね。出発する時点での待機リストの順番だけが論点です。電車は定刻に乗客を乗せて出発するので調達時間は不要ですし、チームの生産性が上がれば載せられる人数を増やすこともできます

1回の変化に対応したいだけならタクシーも良いでしょう。でも、変化に対応「し続け」たいなら、いちいちタクシーを手配するのではなく、電車を運行することです。そうすれば、電車が発車する時点で「誰を乗せるべきか」を判断するだけで安全に取り組み対象を変えられるようになります。

素早さは優先順位の決定回数で決まる

アジャイルは継続的に成果を出し続けるためのマネジメント手法ですが、その素早さを直接的には規定していません。素早さは「取り組み対象を変えられる回数」で決まります。

「外部の変化に対応する」というのは「取り組むことを変える」ことを意味します。電車の喩えだと、出発ホームの待機リストの順番が取り組み候補の優先順位です。この待機リストの優先順位は、いつでも何回でも変更してよいのですが、電車が出発する瞬間に、その時点で優先順位に従って取り組み対象が決定します。なので、「取り組み対象を変えられる回数」は電車の出発間隔に依存します。

たとえば、以下のようになります。

  • 週1回で出発 →週1回で取り組みを変えられる →年に約50回変えられる
  • 隔週で出発 →隔週で取り組みを変えられる →年に約25回変えられる
  • 月1回で出発 →週1回取り組みを変えられる →年に12回変えられる
  • 四半期1回で出発 →四半期1回取り組みを変えられる →年に4回変えられる

ちなみに「変えられる」ことが重要で「変える」かどうかは別です。外部の変化がなければ待機リストの並び順を変えることもないので、取り組むことを変える必要もありません。

この出発間隔=「素早さ」を決めるには「このビジネスでは、年に何回、変化を取り込めるようにしますか?」に答える必要があります。たとえば社内の業務プロセスの変更を伴うような場合、毎週のように業務フローを変えるのは現実的ではないので四半期に1回でもよいでしょう。一方で、業務フローを変えないような改善であれば毎週でもいいでしょう。重要なのは対象にとって適切な素早さを定義することです。

もし、1つのシステムの中で複数の素早さが混ざることがあれば、業務プロセス変更を伴う新規案件は四半期ごとだけど、小規模な改善は毎月、ということになります。これを1台の電車(チーム)でまかなうなら、もっとも素早いサイクルにあわせて出発間隔を決めた上で、車両(リソース)を新規開発と小規模改善に分けて、それぞれごとの待機リストを管理するようにします。

JTCでアジャイルをするときの課題

ここまではアジャイルの仕組みを電車にたとえながら、その使い方を説明してきました。とてもシンプルですが、JTCは安定して効率的に取り組むことに最適化されているので「取り組むことを変える」ことがやりにくいです。

これはチームの問題ではなく、組織の問題です。いかにチームが優秀で成果を出せる能力があっても、組織の中でその能力を発揮できるかは組織の要因が関係してきます。

ただ、「やりにくい」だけで「やれない」わけではないですし、ちゃんと組織として仕掛けをつくれば「やりやすく」できるとも思っています。特に以下の2つが重要です。それぞれについて課題と解決を説明します。

  • いかに優先順位を調整するか
  • いかに決定するか

いかに優先順位を調整するか

そもそも、待機リストに並んでいる取り組み対象候補は、どんな単位であるべきでしょうか。DXであれば、待機リストはビジネス価値の優先順位を並んでいるべきでしょう。よりビジネスに貢献し、売上や利益に貢献するものが優先されるのが当然でしょう。

そのビジネス価値を提供するために必要な業務やITが「ビジネスの仕組み」です。つまり、仕組みを作ることでビジネス価値を実現し、それを顧客に届けます。

優先順位はビジネス価値で管理する

そもそも、目的にすべきなのは仕組みを作ることではなく、価値を提供することです。DXのような案件の場合、なかなか正解の仕組みがわからないところから始めることも多いため、どうやったら、より高いビジネス価値を提供できるのかを、仕組み自体を試行錯誤する必要があります。ところが、JTCでシステム開発を長年経験していると「QCDを守って仕組みを実現する」ことが重視され、「ビジネス価値が提供できているか?」という意識が薄くなりがちです。

特にJTCではDXのための仕組みが複数の部署やシステムにまたがって整理が必要になり、複雑さが増します。数のようにビジネス価値とビジネスの仕組みの関係性はマトリクスになっており、複雑です。

ビジネス価値とビジネスの仕組みの関係

そのためビジネス価値の優先順位が変わっていく中で、ビジネス価値と、その仕組みの管理もあわせて考えていくのは難易度が高くなります。

いかに決定するか

優先順位が調整されても、これを組織として実行するための決定にも課題があります。スクラムガイドによれば、プロダクトオーナー(以下、PO)は『スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ』という1人の人間であり、そのためにビジネス価値が並んだ待機リスト(プロダクトバックログ)の優先順位を決定する必要があります。さらにスクラムガイドでは『プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない』と記載されています。

しかし、DXのように全社にまたがるような変革では、PO個人の決定を組織全体で尊重するのは極めて困難です。そのためPOの決定を組織の決定とするための手続きを行います。しかし、組織の決定のために数週間や数ヶ月もかかったり、急ぐあまりステークホルダーの調整が甘いと決定済みのことを覆されたりすることがあります。こうなってしまうと電車は安定して運行することができません。

JTCでアジャイルをするための取り組み

整理すると、JTCでアジャイルをする場合の課題は以下の通りです。

  • いかに優先順位を調整するか
    • JTCでは仕組みの実現が重視されて、ビジネス価値への意識がなくなりがち
    • JTCでは複数の部署やシステムをまたがって仕組みが複雑になりがち
  • いかに決定するか
    • JTCではPOの決定が組織で尊重されにくい
    • 組織の決定をしようとすると遅くなったり、急ぎすぎるとくつがえしが発生することがある

では、それぞれについて解決策を考えていきます。

いかに優先順位を調整するか

まずは意思決定者とチームがビジネス価値の優先順位を会話することです。もし、それが仕組みの優先順位になっていれば修正する必要があります。

たとえば「抽選機能がないなら、抽選機能を作る」というようなのは、仕組みが目的化しており、そのために課題が作られてしまっています。本来は「公平な購入機会を作る」みたいなことが提供すべき価値です。そのための仕組みは、もちろん抽選機能の開発も選択肢ですが、人手で対応することも可能です。手段が目的化してしまうことで選択肢が狭まり、ただのシステム開発に成り下がってしまうのです。

ビジネス価値が整理されたら、それを実現する仕組みを継続的に管理します。どう言った方法でも良いですが、システムデザイン領域は大きなヒントになります。サービスデザインは、顧客価値だけではなく、従業員価値やITなどの支援ツールなども含めてデザインすることが目的になっています。僕はサービスブループリントという手法を推奨しています。

こうした「価値と仕組みのマッピング」は様々な部署の協力を得ながら作成し、作成されたら関係部署で共有し、メンテナンスを継続します。それぞれの調整相手ごとに資料を作るのではなく、同じ資料を見ることが大事です。

いかに決定するか

これは単純にPOの決定を組織の決定とするためのプロセスを明示し、意思決定者などを巻き込むことです。そもそも、JTCにおけるPOの役割は下図のようにややこしいです。一般的には顧客とチームをつなぐ「横の調整」が大事だとされていますが、JTCでは意思決定者や業務部門との「縦の合意」も重要です。

JTCにおけるPOの役割

つまり、顧客とチームをつなぐ「横の調整」をした結果を、意思決定者や業務部門と「縦の合意」をしていくのが必要になります。このとき大切なのはリズムです。チームでおこなう横の調整と、組織としておこなう縦の合意は同じリズムで行う必要があります。電車のたとえで言えば、電車の出発間隔と同じ間隔で意思決定者を含めた待機リストの優先順位を確認するのです。そこには「後でくつがえすかもしれない人」を参加させなくてはなりません。それが取締役でも社長でもよいのですが、意思決定者であれば関わります。

より具体的には組織としての意思決定者とPOやスクラムマスターが参加する意思決定ミーティングを設定します。もちろん、役員などの組織としての意思決定者がスプリントレビューなどのスクラムイベントに出席することもできますが、個人的には避けた方がいいと考えています。1つ目は「JTCだと関係部署が多いから、偉い人全員が複数チームのスプリントレビューに出るのは現実的じゃない」という物理的な話と、2つ目はチームとしての意思決定と、組織としての意思決定が適度に分離しているほうが、チームがより深く考えるようになるからです。ベンチャーであれば一体になっているほうがよいですが、JTCでは階層化されているほうがチームの能力は高まると思います。

いずれにせよ、組織が「変化に素早く対応し続ける能力」を獲得するためには、組織の意思決定者が意思決定を素早くすることが絶対に必要です。前回のブログも参考になると思います。

arclamp.hatenablog.com

まとめ

この記事では以下のようなことを紹介しました。

  • DXには「変化に素早く対応し続ける能力」が必要
  • ところが、JTCは「安定して効率的に対応し続ける」ことに長けているので「取り組むことを変える」のが苦手
  • それらを解決するためには組織としての仕掛けを用意して、チームが素早く動けるようにしないといけない

JTCでもアジャイルができないということはありません。ただ、取り組むためには部署間の意思疎通や組織としての意思決定プロセスを見直す必要があります。特に大事なのは、意思決定者も一緒にアジャイルに取り組むということです。これは必ずしも「チームに参加する」ことを意味しません。チームが素早く活動できるように、組織としての仕掛けを作っていくのが重要だと思います。

(宣伝)僕が代表をしているGraat(グラーツ)では、エンタープライズDXの推進に組織とITの両面から取り組んでいます。興味をもっていただけたら、ぜひ、こちらからご連絡ください。

*1:左:JPN TAXI. by MIKI Yoshihito CC BY 2.0 右:Yamanote Line 山手線 by Melvinnnnnnnnnnn (FN2187) CC BY-SA 2.0