あなたのプロジェクトは要求を実現する方法論やツールを使っていますか

on

アジャイルがダメだと思う7つの理由　2013年3月21日
アジャイルがそんなにダメだと思わない7つの理由　2013年3月22日


TLに流れてきたのでまたやっているのか…と思いつつ何気にブログのアップ日を眺めてみたら「2013年！」。啓蟄も過ぎた頃だしモゾモゾと目覚めてきたのかしら。


みなさんにはあまり関係がないかもしれませんがワタシの立ち位置としては「プロジェクトのためにイイトコ取りをする」がポリシーです。ダメな理由を探して意見をぶつけ合うのは関心ないのですが、ワタシが関わるプロジェクトについてはそのプロジェクトが期待する結果を得られるやり方ならなんでもやってみよう、です。


1. 全体スケジュールにコミットできない
うーん、これ、契約によりますよね。契約で求めらて応じるならプロジェクトチームがどう思おうがコミットしなければならないわけで。それって、コミットしないと認めない契約ならそれに合わせるのか、はたまた提案時に見積もり前提条件で条件の交渉をするかどうか。


提案チーム（営業と技術とマネジメント）がリスクを検知できるかどうかにもかかってきますけど。


ウォーターフォールでもアジャイルでもどっちでもいいんですよ。契約元の立場では。やりたいこと、要件を実現してくれれば。とは言っても、RFPがふにゅふにゅだったり存在しなかったりすることもあるし、提案自体がズブズブだったりするならコミットも何もないんですが。


コミット云々の前に、要件を出せるのか、請け負えるのか、です。


2. アーキテクチャ上の無駄が生じる
FSしましょう。無駄がいやなら。発注元も受注側も。そういう提案したらいいじゃないですか。「そんなフェーズ入れられない」と言うならどうしたらそうしたできるかもっと考えたほうがいいですよ。そんなに難しいことではないです。


あとですね、作った以上は固定資産です。償却が必要なのです。無駄がいやならそう言ったことも回避する提案をしたらいいのですよ。


3. コーチって何だよ
名称はともかく、ちゃんとロール設計してみたらどうでしょう。それが開発に良い影響をあたえる貢献が期待できるならコスト計上すればいいのです。体制的にそうした役割が認められないときは、リスクのエクスボージャを測ってそれに応じたリスク対策費として費用に入れたらいいじゃないですか。そのくらい考えましょう。


4. 変化ヲ抱擁スルために固定化している
固定とはメンバのようですね。あれ、アジャイルでもプロジェクトが必要とするスキルとレベルを持ったメンバでチーミングするんですよ。それは、ウォーターフォールでも同じです。なぜなら、それがプロジェクトの目標を達成するためのリソースとしての要求だから。


ただ、人は更新されるんですよ。本人の希望もあるし外部要因が働くこともある。所属する組織の都合もあるし、個人的なことだったりする。それもリスクなわけですが。


チームの中でロール設計が縦割りがひどければ人の更新が起きるときにトラブルになるわけです。それをチーミングするときから考えておけ、ということです。マネージャが。


5.実証主義的な説明に過ぎない
大前提が間違っているのでは。プロジェクト自体「唯一無二」なのですよ。何かが違う。同じメンバで同じ開発テーマをやったとしても、前回と今回では経験値が違う。同じことはありえない。


いつでもプロジェクトをやるときは、そのプロジェクトとしてどうなのかを知ることが必要なの。


6.手段が目的になっている
プロジェクトを成功するためかどうかで判断しなければならないの。それをするためにはプロジェクトに対する要求を知らなければならないでしょう。プロジェクトの存在理由を知って、それを実現するためにどのような手段がとれるかを考えること。新しいやり方は実績がないけれどでも一番可能性があると判断したのなら、検証して失敗がわかった時点で従来のやり方に戻ったとしても取り戻せるように、ちょびっとFSしてみたらいいじゃない。


7.アジリティはアジャイルだけのものではない
そりゃそうだ。必要とするプロジェクトを実現しようとするチームのものだ。チームが必要とするならそれを取り入れなければプロジェクトは目的を達成できないのだから。


あなたのプロジェクトは要求を実現する方法論やツールを使っていますか。