岸良さんがAgile Japan 2012で行ったWorkshopを社内で行ってみました。

 

普段一緒に開発しているチームに岸良さんのプレゼン資料を元に

全体最適と部分最適の話、マルチタスクとシングルタスクの話を行いました。

 

全体最適と部分最適

全体最適と部分最適の話については、一同納得といった感じでした。

常駐派遣でのソフトウェア開発の場合、Command&Controlになりがちで、各人がリスクを背負いたくないというのもあって、プロジェクトマネジメントをしているリーダーに許可や確認を行い後は、各自が自分のベストを尽くすというスタイルが多いように思う（実際それを求められていた）。

 

プロジェクトがうまく進んでいるときはそれでも問題ないが、プロジェクトがうまく行かなくなったとたんになぜ遅れているのかをマネジメントを行っている人たちが考え、その結果を現場の人に説明して改善するという一方通行的な改善が行われる場合が多い気がする。

 

その場合、人に着目せずにやり方やプロセスが間違っているという改善案が多く(そういう時もあるんだけれど)、アプローチにしても全体の速度を一気にあげるような改善案を試している。

管理社：「改善案を考えました！これできましょう！」

開発者：「・・・」

 

実際は、開発者同士がコミュニケーションをとることで現場が考える問題点を洗い出してマネージャーは開発者が考えた改善案を実施するために必要な権限を与えたり環境を整えるだけで開発速度は増すのではないかと思う。

 

その手段として、チームで協力し開発速度が遅くなりがちな人や工程を皆でカバーすることで改善を行う。

こうすることで、チームがどんどん改善を行うためのコミュニケーションをとり始め、自分たちで開発しているというやる気が起こり、開発が面白くなっていくと思う。

遅れている原因がなんであれ、マネジメント層だけで考えるのは避けたい。

 

 

マルチタスクとシングルタスク

次にマルチタスクとシングルタスクについての話

ワークショップ

「１〜の数字」、「A〜 のアルファベット」と「○、△、◇の記号」を３０ぐらい？縦に記載して行きマルチタスクとシングルタスクを実践するというワークを行いました。

 

最初に自分がどれくらいで終わるかの見積もりを行ってもらいました。

１回目は、数字→アルファベット→記号→数字・・・と記載する。

２回目は、数字３０個→アルファベット３０個→記号３０個と記載する。

 

結果

１回目は、全員見積もりをかなりオーバー（終わらなさすぎて途中で打ち切った）しました。
そして2回目。全員ほぼ見積もりに近い時間で終わった。

考察

見積もりした時は、前提条件として一つのタスクに”集中”出来た場合これくらいで終わりますという見積もりに成っているということ。

実際の開発ではそんなことはあり得なくて、何らかのコミュニケーションを取ったり、確認作業が発生するためタイプしていた時間は見積もりに近い値かもしれないが、作業開始から完了までの時間は見積もり時間をオーバーする。

結果

マルチタスクとシングルタスクをお手軽に認識するためにはとてもよいワークショップだと思う。
これを気に見積もりについて皆で話し合うときのコンテキストの一つをチームで揃えられました。