自己啓発

「正しいものを正しくつくる」を読んで思うことー現役エンジニアが考えるアジャイルの本質

正しいものを正しく作る

こんにちは 蓮です。

今回ご紹介する本は以下です。

「正しいものを正しくつくる」ー著者:市谷聡啓

アジャイル開発を進めている現役エンジニアとして、
この本を読んで気づいたことや自分が直面している課題を解決に導くものなどの観点から、本の感想を書こうと思います。
本を読めば分かることは簡単にまとめる程度にします。

この本は、市谷さんのご経験をもとに書かれたもので、内容が濃いです。自分の今のプロジェクトと照らし合わせながら読んでいくと、勉強になることが多いです。ただ咀嚼に時間がかかり、紹介ブログがなかなか先に進みません。

今まだ読んでる途中なので、ゆっくり更新していきます。

第1章 導入

第1章の導入として、多様性がプロダクト作りの不確実性を高めていて、
確実性を上げるためにアジャイル開発という作戦が必要になったという話をしています。

第2章 アジャイルの成り立ちと型

第2章では、アジャイルの成り立ちからスクラム、「アジャイルに作る」の型について書いています。

スクラムはアジャイルの代表的なフレームワークとして、この本でも具体的に書いています。今スクラムを始めようとしているので、とても勉強になります。

私が言いたいのは「アジャイル=スクラム」ではありません。
Agile Manifesto読めば分かりますが、アジャイルは特定の手法や方法論ではありません。アジャイルの原理・原則は、ある限られた条件下でしか適用できないものではなく、全てのプロジェクトに対し、文化やプロジェクトの特性に合わせて適用できる考え方です。

「アジャイルの本質は、プロジェクトを成功に導く最良の行動を取るための考え方である」と思います。最良の行動として、「費用対効果」や「リスクヘッジ」の考え方がありますね。これもアジャイルと言えるのです。

スプリントバックログについては、「スクラムガイド」には書いていない、
市谷さんのご経験から得た独自の視点が入っていますので、それを紹介します。


スプリントバックログは、1つの作業の単位がスプリントを越えることはないし、
もっと言うと1日を越えるべきではない。
1日を越えてしまうと、1回のデイリースクラムで状況が把握できなくなるためだ。

自分のプロジェクトでスクラムを行う際、気を付けるポイントです。

参考資料として、下記もご確認ください。
特に「IPA アジャイルソフトウエア開発宣言の読み解き方」は、
アジャイル宣言の背後にある12の原則について詳しく解説しているのでお勧めです。

・Agile Manifesto history: https://agilemanifesto.org/history.html


・Agile Manifesto(アジャイルソフトウエア開発宣言) :https://agilemanifesto.org/


・IPA アジャイルソフトウエア開発宣言の読み解き方:https://www.ipa.go.jp/files/000065601.pdf


・スクラムガイド:https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

スクラムの成果物の一つに「プロダクトバックログ」があります。
ここで大事なポイントが書かれていますので、紹介します。


スプリント対象となるプロダクトバックログは先読みして詳細化進めておく。
スプリントを始める際に、さあ詳細化を始めようという感覚ではスプリントの可視に間に合わず(いわゆる準備完了[Ready]の状態のプロダクトバックログが不足する)、スプリントの活動が混迷する可能性が高い。


プロダクトバックログが[Ready]の状態ではない時にスプリント始めても、
進め方が分からなかったり、目指すゴールをイメージできなかったりして結局手戻りが発生する可能性が高いです。
このポイントはぜひ押さえるべきです。

また、 私が好きな思考と行動のフレームワークである「ゴールデンサークル」の記載がありましたので紹介します。

f:id:jck52270:20191007220734p:plain

「Whyがなければ、自分たちのとっている行動が正しい方向に向かっているのか分からなくなってしまう。また、キーワードとして「アジャイル開発を始める」が先行している場合は、意外と誰一人その目的を分かっていないことも十分ある」といった記述があります。

これはまさにそうで、現場で「このプロジェクトはアジャイルで開発する」と先に決まって担当者におりてきているケースが多いです。担当関係者は誰も目的を知らず、手探りで勉強しながら開発を進めています。こういう場合は関係者間で認識を共通させておく必要があります。

もう一つ要求開発の際によく使うフレームワークがこちらです。

f:id:jck52270:20191007222201p:plain

ここで重要な要素はやはり先ほどのゴールデンサークル同様、<Why>です。

誰<Who>に何<What>を提供するのかは、製品開発においてよく考えるポイントですが、理由<Why>はおろそかになりがちです。

考えられる原因は、以下のようなものがあると思います。

1.顧客自身もなぜ必要なのか、<Why>が分からない、定義できない。

2.仮説検証の段階では、そもそも<Why>の不確実性が高い。

3.大きいコンセプトや主要機能は仮説を立てて定義しているが、詳細機能については定義しきれていない。⇒開発に入って仕様を検討する際、ここで迷いが生じており、仕様をなかなか決めきれない場合も多いです。

第3章 不確実性への対処←現在随時更新中

インセプションデッキ(不確実性への対処):

「早く少しだけ形にする」だけでは適応できない問題:
1.「暗黙的な期待を放置したままでは合意形成にならない」こと
2.「不確実性への対処から得られる学びが新たな不確実性を生む」こと

まさにその通りです。

・「暗黙的な期待」について思うことは、言葉の限界です。
例えば何かの要求を伝える場合、 話し手は「自分の要求+自分の期待」を合わせて伝えたつもりでいるが、聞き手は、聞いた言葉をそのまま理解しようとする。そこに話し手の期待まで理解できない。
また、同じ言葉でも、聞いている人が違ったら、それぞれ異なる理解をしている場合もある。

言葉だけでは人の理解力に差が生じるのだ。
言葉の限界の対処法として、言葉を絵や図に起こしてイメージを共有するのが効果的である。

「当事者も気づいていない潜在的な期待」を見える化するためのワークショップが
「インセプションデッキ」だ。

「インセプションデッキ」の10の項目は、ビジネス側でたたき台を作って、関係者の共有するのもいいし、関係者が集まってみんなで作っていくのも良いと思う。
「インセプションデッキ」の中で結構重要だと思う項目が、「やらないことリスト」(Not ToDo List)だ。

やること(ToDo)はいくらでもあげられるので、逆にやらないことを判断することで、ミッション遂行に向けてやるべきことが明確になる。
そうすることで、要求ばかりが膨らむのではなく、要求のスリム化ができる。

こちらの記載文言も好きです。


プロダクトのマネジメントには、リスクマネジメントと期待マネジメントがあり、
期待とリスクはつながっているのだ。

 

・「学びから生まれる新たな不確実性」について思うことは、トレードオフの共通理解です。
これがなかなか難しい。
関係者で話し合うほど、QCDの優先度が全部高く、分かち合うのが難しいため、
トレードオフの合意形成がなかなかできない。
開発者ならだれでも分かることだが、QCDの優先度が全部高いプロジェクトは必ず破綻する。
アジャイル的には、QとDのトレードオフだが、現実的にCのコントロールしか選択肢として残されていない場合がある。
しかし、ブルックスの法則が何十年も前から示しているように、予算あるいは人を追加すればソフトウェアが仕上がるわけではない。

対策として、「インセプションデッキ」に「トレードオフスライダー」という項目があるので、これを用いて関係者間で協議し共通認識を持てばいい。

 

ユーザーストーリマッピング(USM) (不確実性への対処):

USMのメリットは、短時間(2時間程度)でユーザーにとって何が必要なのかを把握することができること。 準備するものは、広い壁、大量の付箋、人数分のペンのみだ。

USMのユーザー行動は時系列に並べるのが分かりやすい。 ユーザーストーリーマッピングは手軽で簡単に実施できる要件定義の優れた手法だと思います。

ユーザー行動を時系列に並べるメリットは、参加者のスキル有無にかかわらず、 行動フローの仮説が立てられることです。

USMは一人でも進められるが、できればビジネス側と開発者が一緒に行うことをお勧めします。 理由は、把握できたユーザー要求をその場で関係者に共有できるからです。 また、様々な角度からの意見が得られるので、より広範囲の仮説が立てられます。 デメリットは、仮説が広がりすぎて、要求を絞り切れないことです。 もちろん、一人で何度もシミュレーションするのは問題ありません。

ユーザー要求をまとめるには、何度も仮説検証を行い、価値提供ができる要求を絞ることが大事だと思います。 仮説検証サイクルをどんどん回していくために、素早くプロトタイプを作成することが求められます。 検証段階や目的に合わせて、ペーパープロト、モック、アプリケーションを使い分ければ良いと思います。

ユーザーストーリーマッピングの要点:

「期間の余白」

・バッファはプロジェクトでまとめて取る。

「受け入れの余白」

・アイスボックスで凍結しておく  

期間の余白が残っていた時に要求を取り出して、優先度つけを行う。  常に余白の計算を行うようにして、的確な意思決定を行うようにしよう。

⇒すごくわかります。人は与えられた時間・予算をすべて使い切ろうとする傾向があるので、
 開発項目ごとに余裕があると、本来そこまで必要ないのに先に盛り込んでしまい過剰品質になることもあります。
 結局無駄な開発になる可能性が高いです。
 アイスボックスは今のプロジェクトに取り入れて、どれぐらいの余白があるか把握して、余白の戦略を立てたいです。

ABOUT ME
2児のエンジニアママ