この記事は、みらい翻訳 Advent Calendar 2020 1日目の記事です。

はじめまして、株式会社みらい翻訳プラットフォーム部の@nile_mtです。
エンジニアリングマネージャーとして、機械翻訳サービスのMiraiTranslatorの開発に携わってます。
私自身は、機械学習系のエンジニアではなく、どちらかというとWeb系かつマネジメント系の人です。
みらい翻訳として、Advent Calendarやるのは初めてらしいですね。
トップバッター緊張しています。

はじめに

今日のお話は、「エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング」からの引用です

不確実性＝いろんな「もやもや」「不安」とどう向き合うか

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング
著者：広木大地(ひろきだいち)
https://www.amazon.co.jp/dp/4774196053/

目次
- Chapter1：思考のリファクタリング
- Chapter2：メンタリングの技術
- Chapter3：アジャイルなチームの原則
- Chapter4：学習する組織と不確実性マネジメント
- Chapter5：技術組織の力学とアーキテクチャ

うまとま君の技術めもによくまとまってます。

スケジュール予測と不確実性

スケジュールマネジメントの基本

総作業時間／人数＝必要な工期

怒られそうですね。
これで納期決めると、絶対に遅延します。

実際はこう

制約スラック

単純な工期の積み重ねでは、うまくいきません。
諸々の制約があり、実際の工期は、理想工期よりも長くなります。
その制約によって増える分を制約スラックと呼びます。

リソース制約

この人にしかできないとか、得意分野による属人的制約
例えば、フロントとバックエンドとか

お互いの得意分野を学び合い、どちらもできる人を育成していく
得意な人が「あまり知識を要さなくても作業をこなせる仕組みを作る」

依存制約

作業と作業の間にある依存関係
例えば、「APIができてないとUI作業に入れない」とか

API仕様を決めてモックを作ることで並行作業を可能にする

調整コストや意思決定

例えば、１ヶ月に１回の社長臨席の会議でないと意思決定できない。
次の会議を待つ時間。その会議で意思決定されなかった場合、さらに１ヶ月

組織構造と権限委譲

重要なのは制約スラックを見えるようにして、原因が何かを考え、アイデアを出すこと

プロジェクトバッファ

見積もりの不確実性を吸収するための期間

「やったことがない」ことに対して、どれだけ時間がかかるかを想定するのは難しい。
「やったことがない」ことをするとき、人間は不安になる。

悲観的見積もりと楽観的見積もり

見積もりは「予測」であって「ノルマ」ではない

ノルマにするとディフェンシブになり悲観的になっていく
一方で、「楽観的すぎ」ても、予定通りには完成しない。

「わからないものは不安」
「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくか」を管理する

CCPMアプローチ

エリヤフ・ゴールドラットの「ザ・ゴール」「クリティカル・チェーン」参照

ここのタスクにバッファを積むのでなく、全体にプロジェクトバッファを設定します。
（ここのタスクにバッファを積むと１００％バッファ消化しちゃってバッファにならないというのはみなさん経験あるんじゃないかと思います）
そこで、プロジェクト全体の何％とバッファを設定して、バッファの消費率を管理する。
プロジェクト全体として、あとどれぐらいバッファが残っているのか
こうすることで、プロジェクトの状態を把握することが容易になる

多点見積り

個別のタスクに対して、複数パターンで見積もる

例えば
・完了確率は正規分布に従うと考えて、平均と最悪の偏差をみる（2点見積り）
・楽観的な最善値、大体これぐらいで終わるだろうという最頻値、最悪のケースの最悪値の３つで見積もり（３点見積り）

偏差が大きい程、不安が大きいタスク

どうやって不安を減らしていくか

不安＝偏差が大きいものから先にやる
タスクが進めば、不安量が減り、リスクを確実に減らしていけます。

不安が大きいものを、小さなタスクに解体する
「どこが不安であるのか」「何をすれば不安でなくなるのか」を基準にタスク分解
「不安の大きなタスク」と「不安の小さなタスク」に分解することで、見積もりしやすくなるので
偏差＝不安が小さくなり、また優先度の自由度も増す。

** 相対見積り
実時間でなく見積もると悲観的な見積もりになりがち
基準となる平易な「タスク」を元に、それの何倍かという見積り方法

SMLで見積もる（Tシャツサイズ見積もり）
ストーリーポイント
理想日見積り（理想的な１日の稼働時間（例えば、６時間はタスクに向き合える）×日数）
実時間（いつまでに完了するかを見積もる手法。ノルマになりがち）

計画でなく実績から予測する

小さくスプリントを回しベロシティを測定することで、実績から将来を予測する

ヴェロシティが多い ≠ 生産性が高い

安定したヴェロシティを出して、予測精度をあげる方が大事

スケジュール不安はコントロールできる

不確実性をリリース予測の幅として表現することで、スケジュール不安を可視化できる。

可視化できればコントロールできる

＃まとめ
「スケジュール予測と不確実性」は、書籍の中ではごく一部です
そのほかにも、参考になる部分多いので、ぜひご一読ください。

明日は＠@Ungaahhhh が Wordpressか z-index 530000 の話書くって言ってました。