「アジャイル開発に取り組んではみたのですが、うまくいかないので、元のやり方に戻そうと思っています。」
あるSI事業者での講演の後、こんな話しを伺った。同様の話しは、他でもよく耳にする。
私は、エンジニアでもなければ、アジャイル・コーチでもない素人だ。ただ、成果をあげているアジャイル・チームの連中との付き合いは多く、「門前小僧」程度には、アジャイルについては理解しているつもりだ。そんな、私でさえも、これは失敗するだろうと、思うことが多い。
うまくいかない取り組みに共通しているのは、おおよそ以下の3つに整理できそうだ。
ひとつは、「システムを作ることを目的にしていること」だ。
ビジネスを成功させること目的とせず、そのための手段である「システムを作ること」を目的としている「アジャイル開発（？）」では、うまくいかないのは当然のことだ。
2001 年初頭、ユタ州スノーバードで、ソフトウェア開発の将来について議論するために17 人のソフトウェア・エンジニアが集まり、「アジャイルソフトウェア開発宣言」が決められた。そこには、次の4つの価値が明記されている。
- 個人と相互作用をプロセスやツールよりも重視する
- 動くソフトウェアを包括的なドキュメントよりも重視する
- 顧客との協調を契約上の交渉よりも重視する
- 変化に対応することを計画に従うことよりも重視する
これらについての解説は、既に多くの実践者たちが公開しているので、ここでの説明は割愛するが、簡単に要約すれば、「ユーザー及び開発者相互の対話を通じ、現場の変化に柔軟に対応して、ビジネスの成果に貢献するために、ソフトウェアを開発すること」であろう。
仕様書を確定させて、その通りにシステムを開発することを目指してはいない。どうすれば、ユーザーが達成しようとしている売上や利益、顧客満足などの事業目的を達成できるかについて、ユーザーと対話し、そのために最適なソフトウエアを開発することを目指す。
エンジニアたちは、業務や事業に関心を持たなければならない。彼らと対等に、どうすれば、事業目的が達成できるかを、ユーザーと一緒になって考えるのだ。
コードを沢山書くことではない。できるだけコードを書かずに事業目的を達成することを目指すことでもある。
このような基本を抑えないままに、手法としての「アジャイル開発」を真似たところで、うまくことはない。
二つ目は、「兼任／兼務でやっていること」だ。
エンジニアは「機械」ではなく、「人間」である。例えば、機械であるパワーショベルなら、穴を掘る必要があれば、必要に応じて現場へ機械を運び、仕事をさせて成果を出すことはできる。しかし、「この事業を成功させる」責任を担うエンジニアが、他の仕事を掛け持ちするのは、大変な負担だ。集中が途切れ、事業の成功に対する情熱もリセットされ、習熟度も高まらない。
稼働率は変わらないかもしれないが、生産性は確実に低下する。稼働率を高めて工数で稼ぐビジネスであれば、それでもいいが、ユーザーの事業の成果を目指すのであれば、このようなやり方でうまくいく道理はない。
三つ目は、「チームを信頼して任せていないこと」だ。
「変化に対応することを計画に従うことよりも重視する」
アジャイルソフトウェア開発宣言に示された4つの目の価値だ。VUCAの時代、すなわち、変化が早く、未来を予測できない時代にあっては、圧倒的なスピードこそが、唯一の対処方法だ。そのためには、大幅に権限を委譲された自律したチームに任せなくてはならない。
例えば、自動運転車（正確には自律運転車、英語では、autonomous vehicle と呼ぶ）を考えてみよう。もし、まっすぐなトンネルの中だけを走行するのならば、予めあらゆる事象を予測して、プログラミングし、確実にその通り動作するように、監視、制御すればいい。それで問題が起こっても、トンネルの状況は固定的なので、それに合わせて修正することで、以降のトラブルを確実に回避できる。
しかし、トンネルの中しか走れない自動運転車など、使いものにならない。目的地をインプットすれば、後は、時々刻々変化する現場の状況を自律的に判断し、その場で即応できなければ、事故を起こしてしまうだろう。起こりうるあらゆる事象を事前に想定することなどできないから、自動車自身に自律的な判断と動作を委ねるしかないわけだ。
アジャイル開発が、変化に即応するためにも同じ理屈が通用する。目的地の設定＝「ビジネスを成功させること」、自動運転（自律運転）＝「現場に権限を委譲し、現場を信頼して、自律的に判断、行動させること」ということになる。
そんなアジャイル開発について、「現場に任せてしまうので、計画を立てても意味がない」という誤解をしている人たちがいる。「変化に対応することを計画に従うことよりも重視する」と言う価値が、そのような誤解を招くのかも知れない。あるいは、自分たちの計画の失敗を取り繕うために、「アジャイル開発だから、仕方がない」と言う人たちもいる。
結論から言えば、計画は必要である。ただし、それは一切の変更が許されず、その通りに実行しなければならない完全無欠の計画ではなく、どのような状況にも対応できる計画である。そして、計画とは仮設であり、変化とともに修正すべきものであるとのコンセンサスが前提にある。つまり、「計画を実行する過程で生じる変化に対応すること」こそが、大切だという考え方が、共有されていなければならないのだ。
また、アジャイル開発に従来のプロジェクト・マネージャーは不要だ。品質や進捗、トラブルへの対応は、プログラムを書く当事者である自律したチームに委ねるからだ。そんな彼らの取り組みの障害を排除し、最大限の支援を提供するのが、スクラム・マスターの役割であり、プロマネのような、プロジェクトを管理して、指示や命令を行う役割はない。
自律したチームは、自分たちのやっていることを自分たち自身でふり返り、どうすれば、もっとうまくいくかを、考え、知恵を絞り、変化に柔軟に即応し、不断の改善を繰り返す。
「現場、現物、現実＝三現主義」という言葉ある。机上の空論ではなく、当事者が、実際に“現場”で“現物”を観察し、“現実”を認識した上で問題解決を図るという考え方のことで、品質やスピードを向上させるための日本の製造業における伝統的考え方だ。その考えを土台にしているのが、アジャイル開発であることは、ご存知の方も多いだろう。
このような前提があるにもかかわらず、管理者が、現場を信頼せず、作業の進捗や品質に、細かく介入しようとすれば、現場の自律は失われ、モチベーションも大きく下がり、変化への即応力もなくなってしまう。
もちろんほかにも理由はあるかも知れないが、「アジャイル開発がうまくいかない」と嘆く、SI事業者の方々に、この３つが当てはまることが多い気がする。
私は何も、アジャイル開発について論じたいわけではない。物事の本質や原理原則を突き詰めないままに、カタチだけをまねしようとして、うまくいかないことの事例として、「アジャイル開発」を採り上げたまでのことだ。
DXもこの話に似ている。本来の目的など、どこかに棚上げされてしまい、デジタル技術やデータを使うことが目的となり、どのツールがいいのか、とのように使えばいいのかに腐心する。しかし、ツールの善し悪しは、機能や性能のためではないはずだ。目的の達成、あるいは、課題の解決にとって、いいのか、悪いのかであろう。ところが、その大切なところが、抜け落ちている。
デジタルが普及し、人々の行動様式や価値観、人間関係などが大きく変わってしまった。緩やかだった社会の変化も、あっという間に変わってしまう世の中になり、社会の継続性は失われ、不確実性がこれまでに無く高まっている。ビジネスの前提となる社会の特性が変わってしまったのだ。そんなデジタルが前提の社会に適応できなければ、事業の継続も企業の存続もあり得ない。
この現実に対処するためには、ビジネスのあり方、例えば、ビジネス・モデル、制度や暗黙の決まり事、雇用形態や業績評価などを時代に即したカタチに変革しなくてはならない。
そのためのツールとして、デジタルはとても役に立つ。紙や鉛筆、電話やFAXよりも、遥かにコスパがいい。また、デジタルは、かつては無理だった課題の解決や新しい価値を生みだすことができるほどに進化した。デジタルを駆使することは、これまでとは桁違いの効率化と新しい価値の創出に、貢献してくれるというわけだ。
DXは、そんなデジタルが前提の社会に適応することを目的とする。デジタルは、それを支える手段である。
本質を理解したDXも、手段をデジタルに置き換えるだけのDXも、表面上の行動を見れば、よく似ている。前者はビジネスを変革することをめざし、後者は、手段を置き換えることをめざす。
「アジャイル開発」も同様だ。本質を理解した取り組みはビジネスの成果を目指し、手法を真似るだけの取り組みはXPやスクラムなどで提唱されるやり方を使うことを目指す。
表面上の行動を見れば、両者はよく似ているが、自ずと結果は違ってくる。
本質や原理原則を追求せず、手段だけを、「それらしく」したところで、うまくいくことはない。アジャイル開発にしても、DXにしても、そんな見せかけだけになってはいないかを、改めて、問い直してみてはどうだろうか。
ITビジネス・プレゼンテーション・ライブラリー
