おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

「考える」と「行動する」を分けない

アジャイル開発とスクラム』を読みました。

俯瞰的にアジャイル開発・スクラムについて整理されていて、客観的な視点で冷静にアジャイルについて見つめ直す、よい機会になりました。
1点強く印象に残ったことがあったので、まとめてみます。


アジャイル開発とスクラム』260ページからの引用です。

一つのプロジェクトの中で「考える」ことと「行動する」ことを二つの作業とか二つの役割に分けてしまうのではなく、一つのチームに、さらに一つの個人にまで同居させるのですね。

この引用の文脈は実践知リーダーシップについてなので、ここだけ抜粋しても著者の趣旨とは異なってきますが、「考える」と「行動する」が分かれてしまっているということが書かれているとご理解ください。

「考える」と「行動する」が分離してしまっている

この一節を読んで、自分の開発現場の問題点がクリアになりました。
「考える」と「行動する」が完全に分かれてしまっています。

「考える」は、プロジェクト管理や外部との窓口にあたります。
「行動する」は、プログラムの設計や実装にあたります。

役割分担で言えば、プロジェクトリーダーや管理層は「考える」側であり、
開発者(メンバー)は「行動する」側です。

お互い自分の領域でないことには無関心です。

しかし、「考える」側だから行動しなくてもいいとか、「行動する」側だから考えなくてもいいというわけでは決してないです。

すぐにものを作ろうとする開発者

ここでは「行動する」側にフォーカスをあてます。

開発者はすぐに「ものを作ろう」とします。

なぜそれが必要なのか?だれが使うものなのか?優先順位はどうなっているのか?
そういう背景やビジネス価値を考えずに、手を動かし始めようとします。

How(どうやって作るか)ばかり考え、What(なにを作るか)が疎かになっています。

そして、とりあえずものを作ったら自分の責務が果たせると思い込んでいます。
(それがたとえビジネス価値を生み出さなくても、ものができれば一安心)

・予期しない問題が起きたら、予測不足だった計画、技術戦略が悪い。
・計画よりも工数がオーバーして残業多発したら、見積もりが甘かったせいだ。
・無理難題を押し付けられたので再検討を依頼したら、文句言わずにとりあえずやれと言われた。
・上流工程ですでに確定しているから、明らかにおかしいけれど設計通りに作るしかない。

色々あると察しますが、そもそも手強い問題から目をそらして、考えることを回避してる場合が多いと思います。計画の妥当性、設計や方式の事前チェック、論理的な問題指摘、そういったものは面倒です。とりあえず手を動かす方がラクです。

そういう手強い問題を結果的にだれかに押し付けてしまっているんだと思っています。
不可抗力は自分のせいじゃない。けれども、不可抗力に仕立てあげてるのは自分かもしれません。

数年前の自分は少なくともそうでした。

行動する前に考える

開発者の多くは、自分の役割は「できるだけ速く、ものを作る」ことだと定義しています。
そうではなく「できるだけ速く、価値を生み出す」であるべきだと思います。

トヨタ生産方式の「7つのムダ」のようなことをもっと意識すべきなんです。

そのためにどうするか?
手強い問題にもっと向きあわなくてはならないです。

「行動する」前に「考える」が必要です。

自己組織化

同じく『アジャイル開発とスクラム』の45ページから引用します。
スクラムにおける開発チームの定義についてです。

機能横断的に様々な技能を持った人が製品を中心に集まり、自律的に行動する。開発チームはバックログに入っている項目を完了状態にし、製品の価値を高めていくことに責任を持つ。

開発チームが自律的に行動する。いわゆる、自己組織化です。
「行動する」と「考える」が一体化できている状態です。やはり、これを目指さないとダメなんですね。

私個人としては、アジャイルの最もよい点は自己組織化できるということだと思っています。
これがないと、なにも始まらないし、改善していかないはずです。

今回、『アジャイル開発とスクラム』を読んで、自己組織化は非常に重要な要素であると再認識しました。