エンジニアリング組織論への招待

エンジニアリングとは

エンジニアリングとは何かを実現すること
実現とは不確実性の高い状態から不確実性の低い状態に移していくこと
不確実性を下げるには→情報を生み出すこと
仮説法→わずかな情報から大胆に推論を行い、証拠を探すこと
人は常に論理的な思考ができるわけではない

不確実性とは

環境不確実性（未来への不安）
・方法不確実性→ソフトウェアをどのように作るのか
・目的不確実性→何のためにそのソフトウェアを作るのか

通信不確実性（他人への不安）
・他者理解の不確実性→人は他人や事象を完全には理解できない
・伝達の不確実性→コミュニケーションが到達するとは限らない
・成果の不確実性→仮に理解されたとしても予想されたように行動するとは限らない

人間が持つバイアス

• 個々を取り巻く環境から一般的なことだと決めつけて理解することから生じる偏見

• 伝統や権威を無批判に受け入れて誤った考えであっても信じてしまうことから生じる偏見

• ゼロイチ思考、すべき思考、選択的注目、レッテル貼り

これらのバイアスがあるため人は常に論理的に思考できるわけではないことを知っておく

アジャイルな組織

チームが環境に適応して不確実性を効率よく削減できている状態

少人数の対話を重視する→情報の非対称性をなくす→できる限り少人数で最も情報の多い対面でのコミュニケーションを重視する

役割を分けすぎない→限定合理性をなくす→自分の役割を遂行するにはどうしたらよいかではなくチーム全体の目的において今自分はなにをすべきか

意思決定を遅延する→リアルオプション戦略

価値の流れを最適化する

仮説を立てる

顧客の課題「どんな痛み・ニーズを感じているか」
課題といったときにあったら嬉しい機能を考えてしまいがちだが､ それが熱烈な飢えとか痛みのようなものでなければ 顧客はお金を払うことは少ない。ニーズとは必要性のこと

顧客セグメント「誰かどのくらいそれを感じているか」
どんな人が課題を感じるのか、 それはどれくらいの人数いるのかということをあ
る程度概算する。 どんなに便利でも10人しか必要でなければビジネスは成立しな
い

独自の価値「他にはない独自の価値は何か」
どんなに強いニーズであっても、他にたくさんの代替手段があればそちらに流れ
てしまう。 ｢すごく安い」 とか 「すごく簡単」 のように他には見られない価値が必要

解決策「どのようにその痛みを解決するか」
ニーズを満たし、独自の価値のある解決策であるかを確かめながら、 シンプルな
言葉で解決策を書く。 これが実現できれば MVP になる

チャネル「どこから顧客をどのくらいの値段で連れてくるか」
顧客セグメントが十分にいても、簡単に獲得できなければビジネスは大きくなら
ない。 どの媒体からどれくらいの人をいくらで獲得するのかを想定していくこと
が重要

収益の流れ「お金はいつどのようにいくら支払ってもらうか」
このサービスに対して、誰に、いつ、いくらくらい支払ってもらうかを想定する。ものが売れるというのは価格によって大きく異なる。 顧客が少なくても切実であれば、多くの金額を支払いビジネスは成立する可能性がある

コスト構造「売上に対してどんなコストがどれだけかかるか」
収益が生まれても､ それに応じてかかるコストがどれだけあるかによって、利益率が決まる。 どんなによいサービスでも顧客あたりのコストが大きすぎれば、価
格を上げざるを得ない

測定項目「なにがどれくらいならうまくいっているか」
今まで想定した仮説がうまくいっているかを測るための数値は何で、どのくらい
だったらよいのか。 最大3つ程度の売り上げ以外の数値項目を設定する
競合優位性 「なぜ自分たちがそれをやるとうまくいくか」

競合優位性「なぜ自分達がそれをやるとうまくいくか」
競合優位性の1つは、最初になぜ自分たちがやるとうまくいくのか。 もう1つは、これが成功するとなぜ他の競合が自分たちを模倣できないのか

仮説の検証

仮説検証において重要なこと→役割の整理、いつどんな会議をを開くのかを決める→不確実の解消

・役割の整理
プロダクトオーナー
チームに対してやっていくストーリーを優先順位順に並べた「プロダクトバックログ」を作成します。チームのROI（Return on Investment）を最大化させるために、ビジネス上の要件から、プロダクトバックログを完成させます。What（何を作るべきか）の意思決定の権限を与えられている責任者でもあります。チームの近くにいて、チームからの疑問に誰かに確認する必要なく答えられなければ、チームのパフォーマンスが下がってしまいます。

開発チーム
開発チームは、「プロダクトバックログ」にしたがってHow（どのように作るべきか）の意思決定の権利をもっています。また、その責任があります。

スクラムマスター
スクラムマスターは、プロダクトオーナーと開発チームの間に存在する「ボトルネック」を解消するためにあらゆることを行います。 メンバー1人1人をメンタリングしたり、スクラムにおけるイベントのファシリテーションを行います。プロダクトオーナーのもつ不安を開発チームとともに向き合わせ、開発チームのもつ不安をプロダクトオーナーとともに解決するように促します。

・いつどんな会議を開くか
チーム全体でことに当たれるようにする
チームの誰か1人が抱え込んでしまったことを素早く検知できるようにする

スプリント計画
プロダクトバックログを実現可能なスプリントバックログに変換
する会議。 タスクの分解、 実現方法の検討、課題点の洗い出し、
一段詳細な見積りなどを行う

デイリースクラム
毎朝、チームの全員が出席して、1分程度でその日やることや､
前日までの課題を簡潔に話す会議。 全体で15分程度におさめ、
全員が立った状態で会話をするのが望ましい

スプリントレビュー
プロダクトオーナーが、 インクリメントをレビューする。 修正が
必要なことがあれば、 プロダクトバックログに追加する。 スプリ
ントごとにリリースポイントとなるようにプロダクトを開発する

レトロスペクティブ
振り返り会議。 チームが、 スプリントの中で、 振り返りを行う。
良かった点や悪かった点、次に向けての改善アクションを決める