ソフトウェア開発の現場において、「アジャイル開発」という開発スタイルはデファクトスタンダードになっていると思います。
「正しいものを正しくつくる」には、アジャイル開発で起きうる問題点と、筆者(市谷聡啓さん)自身の経験を元に得られた対応策・知恵が詰め込まれています。
私もソフトウェア開発に携わる者として、読まないわけにはいけないと直感したので、読んでみました。
ちなみに、チームにスクラムを導入するために勉強したことと試したこと - Web系エンジニアのアウトプット練習場でご紹介した「カイゼン・ジャーニー」は、市谷聡啓さんと新井剛さんの共著で、こちらはスクラムを用いたアジャイル開発の入門編のようなもので、ストーリー仕立てでわかりやすく、スクラムをチームに布教するのに便利だと思います。
所感
「正しいものつくる」ということ
「わからないことに向かっていくこと」が重要で、意識しておかなければならない点であると感じました。
ソフトウェア開発において「正しいもの」、つまりユーザーに求められ世の中のためになるものがどんなものなのかについては、プロジェクトスタート時にわかっていないことがほとんどです。
特にプロジェクト初期は何もかもがわからない状況であることが多く、仮説と検証を繰り返して開発を進めていくことになります。
しかし、「わからないことを検証する」ということをしっかり意識しなければ、本当はわかっていなことでも「おそらくこれが正しいだろう」ということでわかった気になり、検証することなく開発進めてしまう恐れがあります。
- 「人間はわからないものが怖い」
この点は振り返ってみると「自分自身も怖さを感じてるなー」ということがあるので、これを受け入れた上でどのように向き合っていくかを真剣に考える必要がありそうです。
わからないものは怖い、それでも立ち向かっていかねばならない。
それが「不確実性」の高いソフトウェア開発の難しいところだと感じました。
スクラムはこういった「不確実性」に適応するのにピッタリのフレームワークで、筆者がオススメする理由でもあると思います。
「正しくつくる」ことができれば、ある程度「不確実性に適応」することができると感じました。
「正しくつくる」ということ
前述の通り、わからないものをわかるまで検証することはとても大事です。
開発を進めていくには、できるだけわかるものを増やしていかねばなりません。
検証を行うには、仮説を言語化し、検証の方法を考えて、検証を実行にうつしていくことが重要です。
ここで注意しないと行けないと思ったのは、「仮説の検証はできるだけ早い段階で行ったほうが良い」ということです。
例えば、簡単なアンケートを取るのと、実際にMVP(Minimum Viable Product)を作って検証するのとでは、前者の方が圧倒的に早く検証を行うことができます。
MVPを作らないと検証できない場合もありますが、簡単なアンケートでわかるものはそこで検証してしまったほうが、早く「不確実性」を減らすことができ、プロジェクトを前進させることができます。
さらにリスク管理の面でも、アンケートの段階で「正しくないもの」だとわかった場合、作業の巻き戻しは少なくて済みます。
仮に本番想定のものを作り込んでから、初めて検証を行うとすると、「正しくないもの」だとわかった場合の巻き戻しの量はえげつないものがあります。
具体例が極端でしたがもっと微妙な違いの場合、私自身意外にも検証を後回しにしたくなる気持ちが働くことがわかります。
こうした「不確実性への適応」をはじめ、「正しくつくる」ための知恵が詰め込まれていました。
まとめ
ソフトウェア開発についてまわる「不確実性」の問題。
「正しいものを正しくつくる」はこれに真っ向から向き合った全328ページの超大作です。
「正しいものを正しくつくる」難しさと、その難しさに対抗する手段を学ぶことができました。
これを自分の現場に適用してみて、どのように現場の開発が変わるかどうか、今から楽しみです！