アジャイルを無責任に広めるのはもうやめよう

Kowloon_Walled_City_Statue

(画像:wikimedia commons

 

こんな記事を見かけました。

 

記者の眼 – 「アジャイル嫌い」はもうやめよう:ITpro

http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1

 

開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう!」となったときに、候補に上がることが多い開発手法ではあります。

 

しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。

私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです(ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはありません)。

自分でアジャイルをやって痛い目を見たこともあります。

 

アジャイルは流行りなので、「なんとなくカッコいい」とか「活気が出そう」などという理由で特に若いプロジェクトリーダーがやりたがることが多いのですが、そういう場合はまず成功しません。

 

それはなぜか。

それは、アジャイルが成立するプロジェクトの要件は、ウォーターフォールよりも遥かに厳しいからです。

 

なぜアジャイルは成功しないのか

アジャイルを成功させるには、それが適用できるかどうかについて、プロジェクトの要件を明確に認識する必要があります。アジャイルは魔法の開発手法ではありません。

アジャイル開発には、エクストリームプログラミング(XP)やユーザ機能駆動開発(FDD)、スクラムなどいくつか方法論がありますが、XP や FDD がごく最初期のプロトタイピング以外で実行されている例は見たことがないので、下記ではスクラムをアジャイルの例として書いています。)

アジャイル、特にスクラムを成功させるには、下記のような条件が満たされている必要があります。

 

  1. プロダクトオーナー(開発の価値判断を決める責任者)とスクラムマスター(進行役)が高いレベルのスキルと責任感を持っていること
  2. メンバーのスキルと意欲が高いこと
  3. チームが常に一つの場所に集まっていること
  4. 経営陣がアジャイル開発の価値を理解していて組織がそれに合わせて構成されていること

 

正直な話、これらの条件が日本の企業で揃うことは極めて稀です。

 

まず、1と2の条件で必要な「経験とスキルと意欲の高いリーダーとメンバー」なんて普通は揃いません。

普通のプロジェクトでは、例えば6人の開発チームだとすると、大体1-2人が頭抜けていて、残りの2-3人ぐらいが平均レベル、残りの1-2人は未熟だったりサボりぐせがあったりします。

そういうチームでアジャイルをやると、どうなるか。頭抜けている1-2人にグッと負荷がかかります

彼ら彼女らが病気で倒れたり、自分ばかりに負荷がかかる状況に嫌気が差して退職したりすれば、プロジェクトは崩壊します。

これはリスクマネジメント的な観点で非常に危険です。

 

また、スクラムでは「スプリント」と言って、一定の期間(1週間か2週間が多いです)を区切って開発を管理していくのですが、1週間というのは通常5営業日なので、実際のところ非常に短いです。

仮に祝日が1日入ったら、それだけで全体の稼働が10-20%もカットされます。誰かが有給を取ったら、部分的に稼働がカットされます。メンバーの誰かが病気になったら、そこの調整も必要です。

スプリントという全体に影響する固定の期間がある上に突発的な事象にも対応しなければならないので、アジャイルプロジェクトを適切にコントロールするには極めて高いマネジメントスキルが必要です

経験と能力のあるプロジェクトマネージャーが極めて少ない日本の現状では、ここのコントロールができないことが極めて多いのです。

 

さらに、3の「チームが常に一つの場所に集まっていること」も、予算や人手不足の昨今ではなかなか困難な条件です。

スクラムは、基本的に意欲とスキルの高いメンバーが密なコミュニケーションを行えることが前提になっているので、そこに外注企業やリモートワークのメンバーが入ってくるとコミュニケーションが大変になります。

確かに、今はチャットや動画会議などのサービスが浸透しつつありますが、それでもやはり「場を共有」しているかどうかは大きな違いになります。

よく言われることですが、人がコミュニケーションする際の情報の約8割は身振りや表情などの非言語コミュニケーションなのです。

 

上記のスキルのばらつきの問題と、マネジメントスキルの問題、コミュニケーションの問題が結びつくとどうなるか。

タスクを引き取ってこなしていく、責任感とスキルの高いエンジニアがどんどん疲弊していきます

実際、現場で意見を聞いてみると、経験のあるエンジニアは一度はこうしたプロジェクトを経験しており、「アジャイル(スクラム)」という言葉に抵抗感を持っている人が多くいます。

 

また、日本ではプロジェクト的な働き方が多いIT企業でも、年度や四半期という会計上の区切りが事業上優先されることが多く(上場企業なら尚更このプレッシャーが強くなります)、プロジェクトの納期もそれに引きずられるケースがたくさんあります。

プロジェクトの設計は本来タスクの見積りを積み上げて行わなくてはならないのですが、「事業計画上、今期中にリリースが必要(来期は開発予算取ってないよ)」とか「営業がお客さんと納期を約束してきちゃった」とか「プレスリリースに予定書いちゃった」などという理由でスケジュールが決まってしまうケースが多々あります。

これはあるべき姿ではありませんが、システム開発もビジネスなので、こうした事情に合わせる必要もあります。そして、こうした「納期ありき」のプロジェクトを行う場合は、やはりウォーターフォールで見積りを立てていって、クリティカルパスをコントロールしていく開発手法のほうが適切なのです。

 

なぜアジャイルが流行るのか

一度アジャイルをやってみれば、これらの困難には気がつくはずなのですが、なぜ未だにアジャイルが安易に提唱されてしまうかというと、私は要件定義の重要性から逃げているプロジェクトリーダーやマネージャーが多いからだと思っています。

 

ウォーターフォール型では「何をどう作るのか」という要件定義の部分を適切に行わなければ、そもそも実装が始まりませんが、「モノを見ないとわからない」とか「変なものができたときの責任を負いたくない」とか「ドキュメントを作りたくない」などといった責任感やリテラシーの低いリーダーやマネージャーがいると、見る見るプロジェクトが混乱していって、スケジュール遅延の責任の所在が問われます。

これが「アジャイルでやりましょう!」となると、基本的にはプロトタイピング手法を組み合わせることが多いので、そういった要件定義フェーズの「面倒」を回避できる気分になるのでしょう。

また、調整や検討が必要な「めんどくさい要件」を決めずに開発を進めることも可能なので、いつでも要件変更を行える気分にもなります。

 

しかし、実際のところ、アジャイルでもドキュメントは大事ですし、適切な要件定義や設計が行われなければブラックボックスだらけになり、九龍城のようなプロダクトになって、バグや設計ミスの多い使い物にならないものができてしまいます。

 

アジャイルも、上で書いたようなプロジェクトの要件が揃っていて、比較的構造がシンプルなスマホアプリの開発や、既にベースが出来ているシステムの改善や拡張等なら適切に効果を発揮することも多いのですが、安易なアジャイルの導入はリーダーの責任をメンバー(ほとんどはエンジニア)に押し付けて潰してしまうことに繋がります。

 

こういうプロジェクトを私はたくさん見てきたので、安易なアジャイル(スクラム)の流行にはとても拒否感を感じています。

アジャイルが適用できる条件が整っているのなら、ウォーターフォールはもっと効果的に実施できるはずで、その上で「なぜアジャイルを選択するのか」という問いに答えられるかどうかがとても重要だと考えています。

 

アジャイル開発のプロジェクトに突っ込まれそうになったら、「なぜアジャイルなんですか?」とリーダーに訊いてみるといいでしょう。

明確な答えが返ってこなかったら、そのプロジェクトは危険です。

 

Masayoshi Hashimoto

「フロントライン通信」編集長。業務経験は15年を超え、メディアサイトから数千万人規模の会員システムまで、10社で80件以上のプロジェクトのマネジメントを実施。2011年にスタートアップを立ち上げ、多くの人がプロジェクトをより成功できるためのツール「マンモスプロジェクト(Mammoth Project)」を開発。世界中の現場で戦うチームを応援することを人生の使命とする。

You may also like...

コメントを残す

メールアドレスが公開されることはありません。