#blog [https://medium.com/@jamesacowling/stepping-stones-not-milestones-e6be0073563f](https://medium.com/@jamesacowling/stepping-stones-not-milestones-e6be0073563f) 著者の [James Cowling - LinkedIn](https://www.linkedin.com/in/jcowling) をみる限り、 Dropbox の Senior Principle Engineer だった模様 # なぜこのブログを読んだか [[Project Management for Software Engineers]] を読んでたら引用されてたのでついでに読んでみた また冒頭の > Successfully delivering on long-term engineering projects often requires structuring them around stepping stones that deliver concrete value and illuminate "unknown unknowns" rather than arbitrary milestones that only serve as project checkpoints. が刺さったので読もうとなって読んだ # 何が書かれているか 割とこの2ヶ所が全てみたいな主張ではある > Here's the problem with arbitrary project milestones: They're kinda useless. Sure you need to figure out a project plan and do some estimating and track progress and send out emails to half the company about how you just successfully completed Milestone M2b and are making great progress towards Milestone M3. Milestones are good for tracking execution, but do they actually help de-risk a project or eliminate unknown unknowns? Not really. > (意訳) > TBD > - Stepping stones are a cohesive, concrete deliverable. They involve the completion of something, generally a simplified version of a final system. > - Stepping stones deliver real value. If the company decides to pull the plug on the project, we should have got something out of the stepping stone version. This could be a system that works at smaller scale or a useful standalone component. > - Stepping stones reside in the cone of strategy. The road to success will likely take a meandering path, but each step should be directionally consistent with where we want to go. > - Stepping stones allow us to learn something! By building a smaller version of the project, we drastically reduce the scope of unknown unknowns. Problems that seemed open-ended and intractable at the start now just seem like obvious next-steps once the solution space has been trimmed down. > (意訳) > - TBD > - TBD > - TBD > - TBD 要するに、実行のためのマイルストーンというのは途中経過を報告する上では意味があるがプロジェクトを成功に導くという観点からすると意味はなく、アジャイルにおけるインクリメントのように最低限動作するようなもので Unknown Unknown を取り除くようなものを作る or 完了することをマイルストーン (このブログでは川を渡る際の途中の石というイメージで Stepping Stones と呼んでる) と置くべきという主張をしている。 # メモ 背景としては、以下2つがある - Unknown Unknown - Known knowns はすでに明らかになっているはずなので実行すれば終わりである、 Knonw unknonws も実験をしてみれば良いだけなのでさほど怖くなくむしろエンジニアリングの領域である。最も怖いのは Unknown unknowns でそもそもこれらは予測することができない上にやっていかないと Knonw になってくれない - 逆にいうとそのフェーズまでで出ていることは、後回しにせずにちゃんと対処しておくべきという話でもある - Starategy is Cone (not Linear) - 一見すると、プロジェクトの実行というのは1本の線に思いがちだけど実際にはやっていくとわかることが増えるみたいな構造でコーンのような構造をしている - [https://scrapbox.io/files/6417d98c342d64001ce4a942.webp](https://scrapbox.io/files/6417d98c342d64001ce4a942.webp) - 不確実性コーンの話とかからもこれは明らかにそう Stepping Stones の価値というのは以下のようにコーンを進んでいく中で Unknown Unknown を減らしていく部分に価値があるのだとしている > It's alright if you drift left or right along your way to the goal, just don't veer right out of the cone. You need to stay directionally on track. At each step we eliminate unknown unknowns while making progress towards our end goal. > (意訳) > TBD また Stepping Stones はそこに限定した価値だけを作れと言っているわけではなくあくまでもその先のゴールを見据えるべきでそのためにもよりシンプルな Solution が重要としている。 > The key was that we designed earlier stepping stone versions in a simple and extensible way, with an eye towards our long-term goal. This is an art. Typically the best engineers in a company will distinguish themselves by the ability to do this. > (意訳) > TBD そして上記でも主張している通り、良いエンジニアというのはゴールを見据えた上で最もシンプルで利用することができる(Minimum Viable) な価値、機能を提供することができるエンジニアであるとも言っている。 # 感想 - マイルストーンの設定の際にスクラムにおけるインクリメントのように価値を示すことができる途中経過を設定すべきであるという主張は普段スクラムやアジャイルの考え方に使っている身からするとしっくりくる - また、 Unknown Unknown を見つけるために Stepping Stones を設定するというのも共感する部分だったので改めて言語化される内容だった