アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則

アジャイルプロジェクトマネジメント

　読みながら、思ったことをつらつらと。
　アジャイル開発の肝は、同じメンバーで同じチームで開発をし続ける環境があるか？だと思う。SIなどで、プロジェクトサイクルが顧客都合にならざるを得ない状況であれば、開発メンバーを固定化して、同じメンバーでずっと開発し続けることは、現実問題難しい気がする。本書で取り上げられている例も自社製品のソフトウェア開発についてだ。ほとんどの開発現場では、プロジェクトが終盤に向かう頃に、メンバー間のコミュニケーションも闊達になり、お互いの考えている事も理解しやすい関係にようやくなる。次も同じメンバーで開発すれば、素晴しい生産性が得られるだろうに。。と考えるが、そうもいかないことの方が多いだろう。そもそも同じようなシステムの開発があれば、まだいい方だろうが。

　同じメンバーでチームワークを熟成していった方がいいと思う理由は、システム開発は、ほとんどの場合は、人との共同作業だ。しかし、共同作業の人数が多いからといって、生産性がそれに比例して生産性が上がっていくものではないことは、誰しもが納得するだろう。では、なぜ生産性が上がらないのだろう。自分が最近思うのは、共同作業の効率性というものは、共同作業者の作業内容をよりよく理解していないと、効率が上がらないからだと思う。少人数の時は、お互いの作業内容を理解しているから、自分がどう動けば効率が良いか考えることができるし、実際行動に移すこともたやすい。しかし、メンバー増えてくるとだんだんそういうことも難しくなる。いつも思い出すのは、レストランなどの飲食店だ。飲食店では、役割分担が、ホール、厨房などとはっきりしているが、おそらくお互いの仕事をよく理解しているメンバー間で仕事をすると、店の周り具合は格段に違ってくるだろう。それを可能にするのは、お互いの信頼と理解に成り立つような、細かなことかもしれないが、暗黙知、ナレッジの蓄積があるからだと思う。

　短期で、より良いメンバーで、しかも品質も良く、システムの満足度も高い開発はできるんだろうか？何がシステム開発における成功になるのかは、人によって解釈も違うし、何が正解かは私もよく分からない。ただシステム開発側の満足度だけを考えてよいならば、アジャイルでイテレーションサイクルを短く、動くものを提供し、より良い方向に改善するというような事ができるならば、それほどワクワクするものはないだろうと思う。チーム開発の良いところは、自分で考えていたことと、全く違うことが生まれたり、発想だったりということだ。
　

　これを読んでて、思い出したことがある。開発工程においては、必要なことだが、システム開発をしているメンバーには無駄に感じるものが、視点を変えると、開発を加速させることもたりすることってないだろうか？コーディングのスピードが上がるとか、生産性が上がるとかではなく、仕様変更、要求管理の効率性についてだ。仕様策定者のような者が、一人で決めたようなものは、大抵は皆の批判をあびる対象になりやすい。「そんな仕様じゃ作れない」みたいな事が、あちらこちらで起きている。だったら、仕様は関係者全員で決めれる、というか覆せるということが重要だ。そのときは、プロジェクトメンバー間での信頼関係は勿論のこと、顧客や利害関係者とも良好な関係を築けていることが、必要なのだけれども。決定された物は、時間と共に陳腐化されてしまうことはあるけれども、決定や変更に対するプロセスを評価する仕組みを作ってみたい。結果がすべてと言われれば、、それまでだが。