エンジニアリング組織論への招待 を読んだ感想です。
これまではアジャイルな体制や開発の実務経験がなく、ブログ等で方法論を読んでどのようにして実際に運用すればよいのかイメージできませんでした。「不確実性のマネージメント」、「不安に向き合う」という考え方からアジャイルがやりたい事が分かった気がします。
考え方の転換を迫られる Chapter1 思考のリファクタリング
頭から読み進めた時に、書籍のタイトルから推測した書きたいことが詰められていると感じた内容でした。開発を円滑に進めるために日々悩んでいる事に具体的な回答はないものの、自分のとらえ方を見直す機会にります。
最後のカレー作りの寓話は あるある 過ぎでした。
パーティに来るみんなのためにカレーを作りましょう。そう言って、ボブとエバは2人でカレーを作り始めた。
ボブは「どんなカレーにするかは僕が決める。カレーの代金は僕が出すから。エバは料理が得意だから僕が支持するようにカレーを作ってくれよ」と言った。
エバは了解し、材料とレシピを来るのを待った。
ボブはどんなカレーにするか悩んだ。料理が得意ではないのでレシピを書くのに時間がかかった。
エバは、とりあえずライスは必要だろうと考え、お米を炊き始めた。そして、ボブがようやく書き上げたレシピを見て、こう言った。「このレシピは正確じゃない。香辛料の分量を決めてもらわないとカレーはできないわ」
ボブは香辛料の分量がどんな味になるのかわからなかったが、パーティーは近いので「適当に決めてくれよ」と言い捨てた。
しばらくして、ボブはパーティーの客から「ライスはターメリックライスじゃないと嫌だ」と言われたことを思い出した。
そしてエバに「ライスはターメリックライスにしてくれ」と頼んだ。エバは「もうライスは炊いてしまった。ターメリックライスにするならもっと早く言ってよ」と怒り始めた。
ボブは「ターメリックライスじゃないとダメだ」といった。
エバはライスの炊きなおしになるが、仕方なくボブの提案を受けれた。
パーティー目前になってもライスは炊けない。それにカレーはターメリックライスよりも白ご飯に合うように作ったから、味のバランスもめちゃくちゃだ。
それを知ってボブは激怒し、「パーティに間に合わなければ、カレーを作る意味がないじゃないか！それでも料理人なのか！」と言い捨てた。
エバはその言葉に怒りを覚えて、「あなたがターメリックライスにしろって言い出したり、レシピを作るのが遅かったから遅れたの」と抗弁した。
味の整っていないカレーと雰囲気の悪くなった2人を見て、パーティは興ざめに終わった。
仕様を出してくれない発注者と、納期は不変なので見切りで開発に着手せざるを得ない開発者。お互いに悪気はなく、自分の責任範囲を全うして良かれと思ったが、望まない結果になってしまう辛い結果です。もう半歩相手側に寄り、状況を伺うだけで改善できると思ったり、思わなかったりします。
伝え方を何とかしたい Chapter2 メンタリングの技術
伝言ゲームで例えられるように、伝わる情報に介在する人が多い程に不正確になり少しずつ内容が変化していきます。それは1対1の場合でも話し手の言いたいことは半分程度しか伝わりません。しかし、発信者の心がけで改善できるものと信じています。
話し手が意図していることが伝わないのは、本書でもなどか出てくる「情報の非対称性」があり、話し手が理解していることと聞き手が理解している程度が違うので、それを無視して話し手が話したいことを話してしまうと、聞き手には全然伝わりません。「氷山の一角」に例えると、話し手が話したいことは海面から出ている部分だけど、それを理解する前提として海中に巨大な氷があります。互いに海中の氷に気づいていないので、沈没事故を起こしてしまいます。
カレー作りを成功させたい Chapte3 アジャイルなチームの原理
アジャイルの考え方を理解できた(と思われる)「不確実性」が出てきました。
受託開発を行っている立場としては、案件が開始された時点でお客様とは立場の違いから抱えている「不確実性」がずれています。
- お客様は開発したものがエンドユーザに受け入れられられるか分からない「目的不確実性」
- 開発者はスケジュール通りに進行するのかが分からない「方法不確実性」
ウォーターフォールは「方法不確実性」と「要件定義」という言葉で「目的不確実性」を半分だけ対処します。半分だけなのは、要件定義でエンドユーザに受け入れられる内容を検討するものの、結果がフィードバックされるまでの時間がアジャイルと比較して長いためだと理解しました。
アジャイルでは、「目的不確実性」と「方法不確実性」に加えて、正しく伝わっていないかもしれない「通信不確実性」に対処しながらプロジェクトを進めていきます。
これまでアジャイルの記事を読んでも自分の中に「すとん」と落ちなかったのは、方法が書かれたものばかりを読んでいたために、その背景にある考え方にまで至らず、モヤモヤした状態が続き開発を進めるイメージをつかめませんでした。
プロジェクトの進め方 Chapter4 学習するチームと不確実性マネージメント
見積を行うときには不安の量を「バッファ」として計上しています。一つ一つの作業でみればそれ程ではないものの、全体として積み上げると過大と感じることもあります。
気がかりではありつつもバッファの妥当性を検証することがありませんでした。「予定と実績の管理」と考えると及び腰になりがちであり、早く終わることに越したことはからでした。それでは「方法不確実性」と向かっていないので、方法に関心しつつも、耳が痛い内容でした。
考え方を組織に適用する Chapter5 技術組織の力学とアーキテクチャ
リリースを積み上げていくと、その時のやむを得ない事情などで技術的負債が積みあがってしまいます。技術的負債が積みあがると属人的になりがちだし、負債を返済するための期間を確保するのも大変です。これまでは感覚だけで大変さや必要性を説明してもなかなか理解してもらえず、技術的負債を数値化するのは気づきませんした。
組織に適用するには再現性や客観性が大事ですからね。
論文はこれかな。 Technical Debt: From Metaphor to Theory and Practice [後で読む]