いちばんやさしいアジャイル開発の教本の現場から 第三話: 次の一歩 #アジャイルのやさしい本

はじめに

この記事はいちばんやさしいdora_e_mの Advent Calendar 2020、要するに一人アドベントカレンダーの16日目のために書いた記事だ。

adventar.org

今回は「いちばんやさしいアジャイル開発の教本」を執筆する中で、ある段階では存在していたが最終版には含めなかった内容を一部紹介する。これらが最終版に含まれなかったのには、様々な理由がある。

1. 「アジャイルはじめの一歩」からは逸脱すると判断したもの
2. 他の著者が書くパートと内容が重複しているもの
3. 不要だと判断したもの

今回は1. について、昨日の参考文献に関する記事同様に次の一歩を踏み出す人に役立つと考え、この場を借りて紹介する。いわゆるアウトテイク集のようなものなので、扱う内容の振れ幅が大きいがそこはご容赦いただきたい。

コミットメント駆動

タイムボックスに対して、できるだけ多くの仕事をこなそうと考えることはタスク駆動であるといえます。一方でそのタイムボックスで生み出す価値にフォーカスすることをコミットメント駆動と呼びます。
「なるべく多くの仕事をこなそう」と考えるとタスク駆動が最適であるように思えますが、生み出す価値に基準を置くアジャイル開発はコミットメント駆動に考えてゆきます。

こなせる仕事量ではなく生み出す価値にフォーカスするという考え方は、アジャイル開発を実践するにせよしないにせよ有用なものだ。

タイムボックスの終端では、「生み出そうとしている価値が本当に価値があるものか」を判断します。
逆にタイムボックスの始まりでは、ある「生み出す価値」の真価を判断する材料を揃える、ということをコミットメントすることになります。
そうすることで、一つの開発単位内で必ず価値検証が行われ、開発対象に対しての学びを得られることになります。

アジャイル開発を「すばやくアウトプットを出していくもの」と捉えてしまうとタスク駆動で考えてしまうのだが、「こなした仕事の量」ではなく「生み出す価値」にコミットメントして開発に臨みたい。

役職から役割へ（フラット型組織）

　部長、課長、係長、係長代理…。いわゆるピラミッド型組織では複数の役職が存在します。現場で実際にソフトウェアを開発しているメンバーがアイデアを提案した場合、そのアイデアは組織の階層を上りながら承認されてゆきます。この構造の問題点は2点あります。
1つは、発案されてから承認され、それが実行に移るまで時間がかかってしまうこと。
もう1つは、上位階層から見て理解できない提案はたとえ良い提案であっても却下されてしまう可能性があることです。

図の上半分がピラミッド型組織だ。

　一方で、極力組織内の階層構造を廃したフラット型組織という形態も存在します。図が示すように意思決定者とメンバーとの間に中間層が存在しません。この形態であればピラミッド型組織と比べて1つの物事を決めるのに必要な意思決定の数は少なくなり、スピーディな行動へとつながります。また、直接意思決定者とやり取りするため提案を理解してもらうためにじっくり議論することも可能です。

そして図の下半分がフラット型の組織。近年ではこういった組織構造が増えてきているのではないか。（私が所属する組織もフラット型だ）

フラット型の組織でなければアジャイル開発を実践できないかというとそうではない。また、ピラミッド型組織より優れているというものでもない。ただ、カイゼンサイクルを回す開発の最前線では、現場が得た学びを迅速に試すことができるフラット型組織だとやりやすいのもまた事実だ。

共通の顧客イメージ

ここでは、ソフトウェアを利用する共通の想定ユーザー「ペルソナ」を活用し、全員がその想定ユーザー目線で解決したい課題を考えることをおすすめします。例えばバンド特化型SNSを考えるときに図のようなペルソナを用意しておくと、そのペルソナを起点に解決するべき課題を考えることができます。

近年ではUXへの関心が高まっていることもあり、「ペルソナ」についてはご存知の方も多いだろう。作ったことがあるという方も少なくないのではないか。

ペルソナができたら、次のステップでは解決したい課題を考えます。ソフトウェアの機能を検討する際には、「作れそうなもの」「あったらよさそうなもの」など作る側の目線で考えてしまいがちですが、ここは「解決したい課題」を軸に考えます。ペルソナに理解を深めたチームでは、「彼/彼女ならこう使うのでは」「あいつにはこの機能はいらないと思う」といったような会話がなされ、まるでもう一人のメンバーであるかのように扱われます。
　このようにして「課題を解決する」という軸で必要だと判断できる機能のみがリストに残り、仮説の段階ではありますが「必要な機能のみで構成されたシンプルなソフトウェア」の原型ができあがります。

ペルソナがあることで、仮説の前提条件が明確になり議論の焦点が定まっていく。一方で気を付けなければいけないのが、ペルソナというのはあくまで仮説でしかない、ということだ。

いざソフトウェアをリリースしてみたら実際の利用者とペルソナがずれていることもあるでしょう。「要求の変更はたとえ開発の後期であっても歓迎する」アジャイル開発の原則にのっとると、この時点で仮説、ペルソナを見直していくことも十分にありえます。

一度作ったペルソナには愛着が湧いてしまうものだが、モッタイナイ精神を発揮せずに「本当に必要なもの」を探求していこう。

プロダクトへの意見は顧客からの贈り物

皆さんはスマートフォンのアプリを選ぶ時に、何を基準に選んでいますか?ストアのランキング、そしてレビューコメントを参考にしている方も多いのではないでしょうか。ストアレビューで厳しい評価がつくのは辛いものですが、これは顧客からのプレゼントだと前向きに捉えることが重要です。そのコメントから改めて自分たちのソフトウェアを見つめなおし(観察)、どう改善するべきか方向性を見定め、作るものを決めていきます(図)。

本文中に「観察」とあるが、これは「OODA」を念頭においた記述だ。

仮説をもとに構築されたソフトウェアは、市場にリリースされることではじめてその仮説の真価が評価されることになります。立てた仮説と現実の間にギャップがあることもあれば、市場の側が変化することで結果的に仮説が市場にフィットしなくなることがあります。そのときに素早く判断し意思決定するOODAループと、素早くソフトウェアをつくるアジャイル開発は強力な助っ人となります。

おわりに

今回紹介したものは、いってしまえばボツ原稿だ。しかし、価値創出にフォーカスしたチームづくりを実現したり、迅速に意思決定したり、顧客が本当に必要としているものを探求したりといったことに役立つものではないかと考えている。よりよいものづくりをするヒントになれば幸いだ。