【読書録】『アジャイルサムライ』に学ぶアジャイル開発 その１-役割分担と自己組織化-
ご無沙汰しております。
ブログの下書きだけが溜まっていき、
全然更新できない日々が続いております。笑
いざ書き出すと、ちゃんと書こう！となって
推敲を重ねていくうちに、疲れてきて
結局断念しちゃうんですよね。。。笑
ということで、
今日は推敲もせずに、ざっくり適当に、勉強内容をまとめて行きます。
今日は、アジャイル開発について。
（開発関連の話は、急に口調が変わります。ご容赦ください。。）
アジャイル開発を知らないとやばい。
きっかけは、仕事でクライアントから言われたこんな一言。
「今回の開発は、ウォーターフォールとアジャイルのMIXみたいな感じでやっていきましょう」
・・・
難しい要求をしてくるなあ。。
まあ、言わんとしてることは分かる。
ウォーターフォールよりはスピード感を持って、
アジャイルよりはしっかりドキュメントに残しながら
みたいなニュアンスだろう。（実際そうっぽかった）
ただ、ここで問題点が。
アジャイル開発に関する知識がほとんどない。
もちろん、経験もない。
なんか細かいサイクルでスプリント回していくやつ、くらいの知識しか持ち合わせていないのだ。
アジャイルを知らないのに、ウォーターフォールとMIXできるわけもない。
ただ、クライアントに「アジャイルやったことないんですよね」なんて
口が裂けても言えない。
クライアントからしたら、高い金を出してプロのPMを雇っているわけで。
その期待には応える必要がある。
ということで、早急にアジャイルを学ぶ必要性が生まれた。
まずは名著から学ぼう、ということで、ある1冊の本を手に取った。
いろいろなところで名前の挙がる本である。
この内容をアウトプットすることで
頭の中を整理し、自分のプロジェクトに落としていくこととしよう。
今回は、その第一弾。
アジャイルプロジェクトの役割分担と、チームの自己組織化について。
アジャイル開発に、役割分担は存在しない
まず最初に、アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりと分かれていない。これをちゃんと実践しているアジャイルチームに参加すると、小さなベンチャー企業に入ったみたいな感覚をおぼえるはずだ。プロジェクトの成功に寄与することなら何だって協力する。肩書も役割も関係ない。*1
最初の衝撃はここだ。
プロジェクトマネージャーも、デザイナーも、プログラマーも、QAも、
あらゆる役割は「存在しない」としている。
もちろん、チームメンバー１人１人の強みはあるが、
細かく定義された役割は存在しないというのだ。
これの意味するところは、
チームが一丸となって成果を出すことにのみ責任があり、
成果のために、誰でも、何でもするという意識を
チームメンバー全員が持って、ようやく成り立つのがアジャイルチームということだ。
これが理想形だな、と思う一方で
実際の現場との大きな乖離を感じた。
現在私がマネジメントしているプロジェクトでは、
ゴリゴリに役割を決めて体制図を書いているし、
他の人の役割に、あまり介入しないような進め方をしているからだ。
アジャイルチームとして見た時に
そもそも理想像が違ったな、と感じた。
チームメンバーが成果にコミットするチームの作り方について、更に説明していこう。
人に合わせて役割を決め、チームを自己組織化する
自己組織化とは、自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせるということだ。そのとき、それぞれがチームの一員として（各人のスキルと情熱と資質を発揮しながら）、どう振る舞えば最善の成果をお客さんに届けられるかを考え抜くんだ。*2
チームが自己組織化していることが、理想のアジャイルチームを作る鍵、とのことだ。
では、どうやってチームを自己組織化するか？
そのためには、
役割に人を合わせるのではなく、人に合わせて役割分担を決める
ということが大事らしい。
先の章の話と矛盾するように見えるが、そうではない。
全員が「成果のために何でもやる」という意識を前提に置いた上で
その人が１番活躍できる舞台を用意してあげるのだ。
チームメンバーの１人１人が、
自分の得意な分野・強い領域において
自己責任の下に、最大の成果を生み出す。
確かに、最強のチームだ。
ここでもやはり、自分の現場との大きな差異を感じた。
必要な役割分担に応じて人をアサインしていたからだ。
（ただ、一般的なやり方であることは間違いなく、同じようなことが、多くの現場で起こっているだろう）
このやり方で開発を進める場合、
チームメンバーの各々の強みが活きているか？
全員が主体的に、最大のパフォーマンスを発揮できる状況か？
という問いに関して、ある程度目をつむる必要が出てくる。
最高のチームを作るには。
チームメンバーの能力・スキル・人柄までもを深く知り、
全員が最高の力を発揮できる役割を提供することが不可欠、と解釈した。
決して簡単なことではないが、マネジメントする立場として、理想のチームを作ってみたい、と思った。
まずは、開発メンバーのことをもっと良く知る、というところから始めてみよう。
アジャイルのプラクティスは、まだまだ続く
本日はここまで。
ここまでの内容は、アジャイルサムライという本の、ほんの一部に過ぎない。
全体の15%を読んでいる段階で、個人的に響いた箇所を抜粋して紹介させていただいた。
読み進めていくうちに、同じように書き留めておきたいプラクティスが必ず出てくると思うので
アジャイルサムライシリーズとして、随時更新していくこととしよう。
それでは、また。
