アジャイルな話
はい、こんばんは。毎度おなじみトモやんです。
今日の題材はアジャイルな話。
アジャイルな三角形
とりあえず三角形を書いてみる。
チームの話をするとき三角形を書くとマネージャーをトップにしたヒエラルキー的なものを連想されるかもしれませんが（というかそういう風に考える人、多いだろうなぁ…）
トモやん的には辺上をベクトルが置かれていた方がいいのです。つまり、三角形には循環が含まれている。三角形に限らず、始点と終点が同じな閉じた図系は、すべからく循環すべきだと思います。
さて、これだけだと分かりづらいので捕捉をいれます。
この図の説明は必須です。PDCAサイクルにつながるものもあるかもしれません。アイデアがあり、アイデアを製品化し、製品からデータを取る。そしてこのデータを次に活かす事が最も大事な所です。これを繰り返していくことでチームは成熟するし、良いものも作れるようになります。白井はこれを「回す」と言っています。そのまんまですね。しかしこれだけでは具体性に欠けるので図に追加します。
動詞が追加されました。
ちょっと話がそれますけど、動詞には必ず付くものがありますよね？そう、主語です。つまり
- 作る人
- 測る人
- 学ぶ人
がそれぞれにいるという事になります。ではそれはどんな人なのか？（ちなみにここまでhttp://blogs.itmedia.co.jp/.shared/image.html?/photos/uncategorized/2011/05/27/4.pngを参考にしています。）
作る人（我が道を行く奇妙な連中）
プログラマ、システムエンジニア、デザイナー
測る人（ネクタイをしない垢抜けたサラリーマンというイメージ）
マーケッター
学ぶ人（がっちりスーツに身を固めたエリート）
アナリスト
つまり前述の三角形を実現するには上記のような人々が必要という事です。
でも物を作ったら売る人も必要というわけで
という感じになります。売る人というのはもちろん、営業マン・ITコンサルです。ところで売る人がいるなら、売られる人も必要ですよね。
アジャイルではお客さんもサイクルの中に入れてしまいます。これをプロダクトオーナーとかオンサイト顧客とか言うようです。
アジャイルのような反復型学習において、彼らの協力は不可欠と言えます。
ち・な・み・に
やはり（http://blogs.itmedia.co.jp/hiranabe/2011/05/lean-startup-introduction-in-japanese-1.html）より
アジャイルでは「顧客にとって既知の問題」に対する「顧客の要求」を満たすべく開発します。もし顧客が「顧客にとって未知の問題」を持っていたら、開発サイドは顧客に情報をフィードバックし、その問題を「既知」とします。要するに開発側で分かっている事があったら顧客にちゃんとそれを伝えるって事ですね。
対してその発展系であるリーンスタートアップでは「顧客にとって未知の問題」について「仮説」を立てていき、検証していくことになります。アジャイルとの違いは「仮説の検証による顧客理解の深化」であり、その為、リーンスタートアップは未知の問題に対しても取り組む事ができるようになりました。
ただし、リーンスタートアップはそもそもアジャイルの発展系だと思うので、ここではアジャイルに含みます。（アジャイル開発の特徴は曖昧である事ですが、定義が曖昧なのはまだ歴史が浅いからです。）
さて、アジャイル開発において顧客の存在はとても大きいので、上記の図を少し改善します。
営業マン・ITコンサルの方々には顧客との橋渡しをしてもらう事にしましょう。
さてさて、目指すべき姿が見えてきました。ところがここである問題が浮上します。
ベンチャー起業によくある事です。PG、アナリスト、マーケッター、営業マン、それぞれの役割に合う優秀な人を必要最低限数だけ用意しなければなりません。でも人的リソースは限られています。ではどうするか？
解決したようです。皆が三角形の内側に集まってきました。アジャイルではこのように役割分担が非常に曖昧になります。顧客はそんな事をしていても何も気になりません。さてさて、役割分担が曖昧になると、ある効果が生まれます。
スケジュールは大規模プロジェクトにおいて個人の責任を明確にするために組まれるものです。しかしアジャイルにおいては役割分担が曖昧であるため、責任の境界もまた曖昧になります。これを共同責任と見なす事ができますが、プロダクトオーナーは不安なようです。
ここで登場するのがアジャイルなマネージャです。アジャイルなマネージャの役割は
- ・いま、どうなってるか追跡する
スケジュールが無いため、これだけが心配です。
- ・プロジェクトの状況を伝える
追跡するだけじゃなく、きちんと広めましょう。
- ・チームのいく手を阻む障害を取り除く
アジャイル開発が順調に進むためには、こういった事も必要です。
時としてチームメンバーが座礁しているポイントにも現れるでしょう。しかし、あんまり偉そうじゃないですね。
アジャイルなマネージャはむしろ雑用係のような存在ですが、チーム内のメンバーが最大限に実力を発揮できるよう頑張る存在です。さながら朝倉南ちゃんのような存在です。またプロダクトオーナーと一緒にユーザーストーリーの作成などもします。（アジャイルでは顧客の要件定義をユーザーストーリーを作ると言います。）
営業マンやITコンサルタントの役割の大半をになってしまうので、アジャイルなマネージャーの登場に代えて顧客との橋渡しをしていた営業マン・ITコンサルタントは退場してしまいました。
イテレーションはアジャイル開発においてとても重要な指標です。例えば３ヶ月のプロジェクトがあれば６回のサイクルがあるという事で、このサイクルの質と数が伴って初めてアジャイル開発はその真価を発揮するからです。
また、アジャイル開発は重要な案件を任せづらいと言われますが、トモやんはそうは思いません。例えばウォーターフォール型開発であっても失敗するときは失敗するものであるし、どんなにウォーターフォール開発を極めたとしても信頼が無ければウォーターフォールに適すると言われる大規模案件は任せてもらえないものでしょう。
そして信頼を失った時のリスクは大規模案件を手がけるウォーターフォール開発の方が大きいのです。一方でアジャイル開発はもともと小規模案件に向けた少人数チームであるから、大規模案件を手がけられるほど信頼が得られた時のリターンは大きいと考えられますし、そこから信頼を失う事があったとしても、それは元の鞘に収まるだけなので大して痛くもありません。
従って
チームさえできてしまえば、アジャイルほどリスクが少なくリターンの大きい開発手法はない
と考えられます。以上、アジャイルなアナリストっぽいトモやんがお送りいたしました。
