傲慢SE日記 ~個人事業主として獅子奮迅中(TownSoft)~

40間近のフリーランスなSE日記です。TownSoftという屋号で仕事をしてます。仕事の依頼も受けてるよ!→http://townsoft.jp/


テーマ:

最近アジャイルプロジェクトマネジメントチックな仕事をしている。チックと書いたのは、僕の学んだアジャイルプロジェクトマネジメントと現場で実践しているアジャイルプロジェクトマネジメントに随分違いがあるからである。

まずアジャイルについて簡単に触れておく。
ソフトウェア開発というものは形が無いもののため、出来上がったものの想像が難しい。また、進捗を計ることが難しいものである。そのため初めに仕様を決めて一気に作り上げるとお客さんの想定しているものと違ったり、実運用では使用しないような機能がついてきたり、予想以上にコストがかかってしまう場合がある。(ちなみに、この開発プロセスを一般的にウォーターフォールと呼ぶ。)
その点アジャイル開発では必要最小限の機能を作り、それをお客さんに見せては肉付けをしていくと言うことを繰り返していくものである。そのためお客さんの意見を一定の間隔で取り入れるため、お客さんの望むソフトウェアが出来上がりやすいのである。しかも、一定の間隔でお客さんに見せるので開発者にも張り合いが出る。(この開発プロセスを一般的にスパイラルと呼ぶ。アジャイル開発はこのスパイラルを基本にしている開発プロセスである。)

さて、この一見すると良さそうに見えるアジャイル開発ですが、、、大きな欠点もあるのだ。
このプロセスは実践するにはかなり難しいものなのだ。

ウォーターフォール開発は今までの古典的管理法と言う他の業種で行なわれてきた管理方法を応用して使うことが出来るのですが、アジャイル開発ではこの古典的管理法とはまるで違う管理方法を使わなければならないため実践できる人がとても少ないのである。
アジャイルの最大の欠点はこのプロジェクトマネジメントの難しさにあるのだ。

例えば、営業職の人ならばここまで読んで一つの疑問が生まれかもしれない。それは「ウォーターフォールならば初めに仕様を決めるため見積もりが取れるが、アジャイル開発の場合は随時に仕様変更が起こるため見積もりが取れないのではないか?」という疑問や、常に要件を受け入れていたらいつソフトウェアは出来上がるんだ?と言う疑問が生まれたりしないだろうか?
実際この点の調整は不可能ではないが難しい。(大体においてカットオーバーの時期を決めてそこまでに詰め込めるだけ詰め込む場合が多い。)


僕はこの難しさを肌で感じたので、今回はそのフィードバックとしてここに記しておく。
今回のアジャイル開発を行う上で感じたのがコントローラと呼ばれるリーダーなどがアジャイル開発が未経験もしくは経験不足だった上に、アジャイルの知識が著しく不足していた。そのため、アジャイル開発のような形式で結局ウォーターフォール開発になってしまったところがあった。この現象はアジャイル開発を初めて導入する現場ではほぼ確実に起こると僕は今回思った。
それを先人は経験で学んでいるためか、アジャイル開発プロセスで有名なXP(エクスストリームプログラミング)等の本には「初めて導入する際には経験者をリーダーもしくは補佐に置くこと」と記載されている場合が多い。中途半端な知識や経験でアジャイル開発を行なうとみんながみんなバラバラに物事を考え始め、統一性の無いカオス、すなわちカウボーイプログラミングと呼ばれるものが出来上がる。(ただし、カウボーイプログラミングは技術者の個々のレベルが高い場合は一概に悪いと言ってよいのか僕には分からない。)

すなわち、初めからお客さんの要求レベルがウォーターフォールの要件定義のレベルを指していてそれを僕らは二週間足らずで仕上げなければならないと言う事が起こったのだ。コントローラーやその立場に近い人は「これが開発プロセスだから」や「他に比べて○○だから」と言う事を言いながら僕らを馬車馬のように働かせた。徐々に肉付けのはずがいきなり肉付けになったのである。
そして、それに対して更に肉付けをしてくると言う最悪な状況で開発者は仕事をしなければならなくなったのだ。

そして、開発者もアジャイルプロジェクトマネジメントの知識が無いためか「やるしかない」と言う思想で走り出した。僕はこの思想が理解できないままこのわけの分からない状況に慣れるしかなくなってしまった。そう、残業をしないというスタンスを崩さなければならなくなったのだ。上からは「稼働時間を上げて欲しい」とかを言われたりするが、そもそもプロセスとして管理しているなら稼働時間を上げるための理由が必要だろう等と思いながら僕は働いた。
この時点でコスト管理が出来ていないのは明白だった。

アジャイルプロジェクトマネジメントはお客さんの言っている要求を100%満たすことではない。初めに書いたとおり、お客さんが望むことはソフトウェアが出来上がった時点で違う場合があるのだ。そのためお客さんの【本当の要求】を満たすために出来ては見せると言う事を繰り返すのだ。そして、その際には出来る限りシンプルな実装が出来るように工夫をして本当に必要なものから実装するように管理する必要があるのだ。

今回のプロジェクトでは全てを取り込もうとした上に、責任の所在とか言う言葉が飛び交うくらいタスク管理がウォーターフォールになっていたのだ。アジャイルプロジェクトマネジメントがどれだけ難しいかが分かった現場だった。



ちなみに、結果的にはこのプロジェクトは成功(*1)した。
僕はこの成功があったためカウボーイプログラミングについては少し考慮の余地があるのかと思ったのだ。成功の原因として、今回のメンバーは個々のレベルが高かったというのが一点あげられる。それだけ高いレベルの人が集まったカウボーイプログラミングについてはもう少し研究をする必要があるのかもしれない。

*1…ただし、出来上がったソースは随分汚いものや手抜きされたもの、コピペされたもの等が散乱していた。劣悪なものだった。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

傲慢SEさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。