プロトタイピングを実施して、家事の「Unknown Unknown」を「Known Unknown」にする：アジの開き×4の所要時間は20分（1/3 ページ）

4人家族の家事育児をワンオペで担うことになった陽太郎さんは、エンジニアリングマネジャーとして学んできたアジャイルの知識を活用して、家事の「何が分からないのか分からない」を整理し、状況がデスマーチであることを把握します。

[高橋陽太郎（リクルート），＠IT]

※本記事はアフィリエイトプログラムによる収益を得ています

　こんにちは、リクルートでエンジニアリングマネジャーをしている高橋陽太郎です。

　エンジニアリングの知識と経験を総動員してワンオペ家事＆育児をカイゼンしていく連載「家事場のシスぢから」。前回は、自分の状況を透明化し、チームのみんなに協力してもらうことで仕事を調整し、家事のスタートラインに立ちました。今回からはようやく家事の中に取り組んでいきます。

コアの課題に立ち返る

　連載第1回で、コアの課題として下記の2つを洗い出しました。

1. 勤務時間は変わらず確保しなければならないとしても、子どもがいる時間になるべく仕事をしないようにできないだろうか。そうすれば時間の捻出についての大部分は解消できる
2. 料理に慣れておらず、時間がかかってしまうのはすぐには向上しないだろう（制約条件の理論で、ボトルネックの性能を高めるのがステップ4になっている理由がこれです）。そこで、時間がかからずに料理を提供する方法はないだろうか

　前回までは、主に「1」に対しての対策を打ってきました。幸い周囲の協力を得られ、業務の時間調整ができることになりました。そこで、2番目の課題に手を打っていきます。

　ただし第1回で記載した「料理に慣れていない」はその通りなのですが、これが本当に課題なのか、他にクリティカルな課題はないのか、といった点はまだ推測の域を出ません。そこでまずは正しい課題認識を持てるように手を打っていきます。

　今回も、議論の取っ掛かりとしてスクラムの「検査・適応・透明性」という3本柱（※1）を活用して考えていきます。

透明性の最初の一歩

　スクラムには、検査・適応・透明性という3本柱があります。これらは相互に関係があり、適応するには透明性が必要で、透明性を保つために検査をする必要があります。

　しかし検査をしようにも、第1回の最初で記載した通り、唯一のレパートリーが「コーラ豚」の私からすると、「何が分からないのか分からない」というのが正直な状態です。

　それではここからどのように始めていけばよいのでしょうか。

経験を頼りに「Unknown Unknown」を「Known Unknown」へ

　まず、「何も分からない＝何が分からないのか分からない（Unknown Unknown）」状態から「何が分からないのかは分かる（Unknown）」を増やしていくことが重要です。

　これは、不明確なこと、不確実なことを減らすということと同義です。この点、ソフトウェア開発はさまざまな不確実性への対応方法を進化させてきました。例えば下記のようなものです（※2）。

• Minimum Viable Product（MVP）
• スパイク
• プロトタイピング
• Fisibility Study（フィジビリ）（※3）
• Proof of Concept（PoC）

　これらの手法に共通するポイントは、推測に基づかず、「実際に検証したもの」を積み重ねる（※4）という経験主義の考え方（※5）です。前回登場したKenの動画で記載されていた内容もこの考え方に通じるものがあると考えています。

※1　スクラムガイド（ScrumGuides.org）

※2　ここでは手法の列挙にとどめていますが、どのようなフローでこれらを活用していくかという話は「Software Estimation Paradox（Chris Lucian）」が参考になります。私が翻訳した「【翻訳】ソフトウェア見積もりのパラドックス（PoohSunny's blog）」も併記します。

※3　「フィジビリ」は、私が勤めているリクルートで頻繁にでてくる用語です。いわゆる「リクルート用語」のようです。フィジビリ：【リクルート用語】リクルートの社内で使われている“社内用語”をまとめてみた（転職アンテナ）

※4　こういった考え方から、「推測である見積もり」をしないという「NoEstimates」という考え方もあります。Woody Zuill（Twitter）

※5　経験主義については「経験主義（スクラム）の3本柱（サーバントワークス）」が参考になります。