SI事業者のアジャイル開発はなぜ失敗するのか

「アジャイル開発に取り組んではみたのですが、うまくいかないので、元のやり方に戻そうと思っています。」

あるSI事業者での講演の後、こんな話しを伺った。同様の話しは、他でもよく耳にする。

私は、エンジニアでもなければ、アジャイル・コーチでもない素人だ。ただ、成果をあげているアジャイル・チームの連中との付き合いは多く、「門前小僧」程度には、アジャイルについては理解しているつもりだ。そんな、私でさえも、これは失敗するだろうと、思うことが多い。

うまくいかない取り組みに共通しているのは、おおよそ以下の3つに整理できそうだ。

ひとつは、「システムを作ることを目的にしていること」だ。

ビジネスを成功させること目的とせず、そのための手段である「システムを作ること」を目的としている「アジャイル開発（？）」では、うまくいかないのは当然のことだ。

2001 年初頭、ユタ州スノーバードで、ソフトウェア開発の将来について議論するために17 人のソフトウェア・エンジニアが集まり、「アジャイルソフトウェア開発宣言」が決められた。そこには、次の4つの価値が明記されている。

個人と相互作用をプロセスやツールよりも重視する

動くソフトウェアを包括的なドキュメントよりも重視する

顧客との協調を契約上の交渉よりも重視する

変化に対応することを計画に従うことよりも重視する

これらについての解説は、既に多くの実践者たちが公開しているので、ここでの説明は割愛するが、簡単に要約すれば、「ユーザー及び開発者相互の対話を通じ、現場の変化に柔軟に対応して、ビジネスの成果に貢献するために、ソフトウェアを開発すること」であろう。

仕様書を確定させて、その通りにシステムを開発することを目指してはいない。どうすれば、ユーザーが達成しようとしている売上や利益、顧客満足などの事業目的を達成できるかについて、ユーザーと対話し、そのために最適なソフトウエアを開発することを目指す。

エンジニアたちは、業務や事業に関心を持たなければならない。彼らと対等に、どうすれば、事業目的が達成できるかを、ユーザーと一緒になって考えるのだ。

コードを沢山書くことではない。できるだけコードを書かずに事業目的を達成することを目指すことでもある。

このような基本を抑えないままに、手法としての「アジャイル開発」を真似たところで、うまくことはない。

二つ目は、「兼任／兼務でやっていること」だ。

エンジニアは「機械」ではなく、「人間」である。例えば、機械であるパワーショベルなら、穴を掘る必要があれば、必要に応じて現場へ機械を運び、仕事をさせて成果を出すことはできる。しかし、「この事業を成功させる」責任を担うエンジニアが、他の仕事を掛け持ちするのは、大変な負担だ。集中が途切れ、事業の成功に対する情熱もリセットされ、習熟度も高まらない。また、チームで行う仕事だから、チームの中での信頼関係を育むのが難しくなる。

稼働率は変わらないかもしれないが、生産性は確実に低下する。稼働率を高めて工数で稼ぐビジネスであれば、それでもいいが、ユーザーの事業の成果を目指すのであれば、このようなやり方でうまくいく道理はない。

三つ目は、「チームを信頼して任せていないこと」だ。

「変化に対応することを計画に従うことよりも重視する」

アジャイルソフトウェア開発宣言に示された4つの目の価値だ。VUCAの時代、すなわち、変化が早く、未来を予測できない時代にあっては、圧倒的なスピードこそが、唯一の対処方法だ。そのためには、大幅に権限を委譲された自律したチームに任せなくてはならない。

そんなアジャイル開発について、「現場に任せてしまうので、計画を立てても意味がない」という誤解をしている人たちがいる。「変化に対応することを計画に従うことよりも重視する」と言う価値が、そのような誤解を招くのかも知れない。あるいは、自分たちの計画の失敗を取り繕うために、「アジャイル開発だから、仕方がない」と言う人たちもいる。

結論から言えば、計画は必要である。ただし、計画とは仮設であり、変化とともに修正すべきものであるとのコンセンサスが前提にある。つまり、「計画を実行する過程で生じる変化に対応すること」こそが、大切だという考え方が、共有されていなければならないのだ。

また、アジャイル開発に従来のプロジェクト・マネージャーは不要だ。品質や進捗、トラブルへの対応は、プログラムを書く当事者である自律したチームに委ねるからだ。そんな彼らの取り組みの障害を排除し、最大限の支援を提供するのが、スクラム・マスターの役割であり、プロマネのような、プロジェクトを管理して、指示や命令を行う役割はない。

自律したチームは、自分たちのやっていることを自分たち自身でふり返り、どうすれば、もっとうまくいくかを、考え、知恵を絞り、変化に柔軟に即応し、不断の改善を繰り返す。

「現場、現物、現実＝三現主義」という言葉ある。机上の空論ではなく、当事者が、実際に"現場"で"現物"を観察し、"現実"を認識した上で問題解決を図るという考え方のことで、品質やスピードを向上させるための日本の製造業における伝統的考え方だ。その考えを土台にしているのが、アジャイル開発であることは、ご存知の方も多いだろう。

このような前提があるにもかかわらず、管理者が、現場を信頼せず、作業の進捗や品質に、細かく介入しようとすれば、現場の自律は失われ、モチベーションも大きく下がり、変化への即応力もなくなってしまう。

もちろんほかにも理由はあるかも知れないが、「アジャイル開発がうまくいかない」と嘆く、SI事業者の方々に、この３つが当てはまることが多い気がするが、いかがだろうか。

【12月度のコンテンツを更新しました】

======

目的の資料にいち早くアクセスできるよう、以下の二点を変更しました。

・タイトルと資料の構成を大幅に変更しました

・研修資料を作るベースとなる「最新のITトレンドとこれからのビジネス戦略（総集編）」の内容改訂　

ITソリューション塾について

・教材を最新版（第38期）に改訂しました

・講義の動画を新しい内容に差し替えました

======

DXとビジネス戦略

【改訂】デジタル化がもたらすレイヤ構造化と抽象化　p.14

【改訂】デジタル化とDXの違い 改訂版　p.27

【改訂】DXの定義　1/3 p.39

【新規】DXの定義　2/3 p.40

【改訂】DXの定義　3/3 p.50

【改訂】DXのメカニズム　p.45

【新規】「デジタル前提」とは何か p.46

【改訂】DXの公式 p.47

【新規】なぜ「内製」なのか 1/3 p.178

【新規】なぜ「内製」なのか 2/3 p.179

【新規】なぜ「内製」なのか 3/3　p.180

【新規】ITベンダーがDXを実践するとはどういうことかp.174

ITインフラとプラットフォーム

【新規】サーバー仮想化とコンテナ　1/2 p.76

【新規】サーバー仮想化とコンテナ　2/2 p.77

【新規】コンテナで期待される効果　p.78

【改訂】コンテナとハイブリッド・クラウド／マルチ・クラウド　p.81

開発と運用

【新規】アジャイル開発が目指すこと　p.37

【新規】SI事業者がアジャイル開発で失敗する3つの理由　p.74

IoT

【新規】Connected p.139

ビジネス戦略・その他

【新規】個人情報とプライバシーの違い p.146

【新規】「個人を特定できる情報」の範囲の拡大 p.147

【新規】Privacy保護の強化がビジネスに与える影響 p.148

【新規】影響を受けるデバイスやサービス p.149

【新規】スマホAIの必要性 p.150

AIとデータ

【新規】データサイエンティストに求められるマインドセット　p.146

改訂【ITソリューション塾】最新教材ライブラリ　第38期

・ITソリューション塾の教材を最新版に改訂しました

- DXと共創

- ソフトウエア化されるインフラとクラウド

- IoT

- AI

下記コンテンツを新規に追加しました

- RPAとローコード開発

- 量子コンピュータ

- ブロックチェーン

下記につきましては、変更はありません。

ERP

クラウド・コンピューティング