あんたもなんかに挑戦しているかい？

俺の場合、仕事上取得しなければならない試験ってのがあって、そいつに向かって勉強なんぞしているんだ。

勉強なんぞ、ほとんどせずに過ごすのがオッサンってもんかもしれないが、まあ、せっかくだから学んだことをちっとでも形にしていきたいもんだ。

今回の勉強のテーマはアジャイル開発。

結構色んな仕事の要素を含んでいるような気もするんだ。
いわゆるシステム開発以外でも通じる要素があるように感じるんだよね。

今回はそんなアジャイル開発の要素をちょっと触れていこうって回だ。

まあ、お勉強に付き合ってくれよな。

アジャイル開発で「固定」するもの

通常のシステム開発では要件があってそれを実現するためにはどれだけの期間と費用がかかるかを見積もるんだ。

つまり動かせないのは「要件」であってそれに必要な期間と費用を可変にするってわけだ。

何？そんなん当たり前だろって？

まあそう思うよなぁ。
でもさ、あんたの仕事で使っているシステム。
あんたがどういう機能が必要だって決めろって言われてあんたは決めることができるかい？

20年以上システム作っているけれど、自分たちの仕事で必要な機能をジャストミートで言うことが出来るヒトってほぼ0なんだよ。

そら、システムの機能を決めるって責任を負わせられたら、いざシステム稼働ってなった後に「この機能がない」とか突っ込まれるわけに行かないから、あれもこれもって機能を要求しちゃうのが普通だ。

基本的にシステムに必要な機能を定義するって責任を負うことは無理なんだよな。

じゃあどうするのか？

アジャイル開発では要件を固定しないんだ。
何？それじゃ何作るんだって？
まず、開発期間と開発人数を固定して、その体制でできそうなことを優先順位の高いところから作っていくんだ。

なので、本当にいま必要な機能から作らざるを得ない。
その機能も実際に使ってみて変えたほうが良いことがわかったら、そのように作り変えるのを次の開発期間以降で優先順位を加味しながら作っていく。

このように繰り返し作っていくやり方をイテレーションって言うんだそうだ。

つまりは誰も正解を知っているわけじゃないんだから、一緒になってトライ・アンド・エラーを大前提として仕事してこうぜって発想なわけだな。

エラーを許容する

このトライ・アンド・エラーを許容するってのは並大抵のことじゃない。

仕事ってのは出来て当たり前。仕事が出来ないのは約束を守るって言う大人としての最低限のことを守れないってことだからな。

それでもアジャイル開発ではエラーを許容しないと前に進むことが難しい。

そのために何をするのか？

まずはシステムを要求する立場のヒト、つまりプロダクトオーナーとシステムを作るヒトを一緒のチームにしてしまうってことだ。
理想は一つの仕切りのない部屋で一緒に仕事をすすめるのが良いとされている。

そしてそのチームでは

・人間性を尊重する
・ツールではなくコミュニケーション
・自律的に仕事をして協調的に仕事する
・仕事のルールの共有
・チームの状態の定期的振り返り

が必要なんだそうだ。

ルールに則ってお互いを尊重しながら積極的にコミュニケーションをとって、かつ常に自分たちのあり方を見直していこうってことだね。

これってさ。
システム開発以外でも通じる要素だよな。

システム開発みたいなプロジェクト型の仕事に限らず、事務職のような機能型の仕事でも同じことが言えると思うんだ。

仕事を自ら考えて、コミュニケーションで利害関係者と調整し、お互いに尊重し合う。

これってさ、ホント仕事の基本だと思うんだよね。

なのに、上司と部下。顧客と受注先。そう言う関係性で仕事をしてしまうと、上司や顧客に仕事のやり方の責任を集中させてしまうことになる。

これってヒトの能力の無駄遣いだと思うんだよな。

なあ、あんたはどう思う？

俺たちはどうすれば上司、部下、顧客、発注先を尊重できるんだろうか？