中島聡さんのスタートダッシュ型仕事術に、考えさせられました。
最初にスタートダッシュすれば、初期に全体の見通しが立つから、失敗作ができても捨てればいいので、品質の良いものを作り出せる。
- Software is Beautiful:第2回 「締め切りは絶対に守るもの」と考えると世界が変わる|gihyo.jp … 技術評論社
- Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し,締め切りが近づいたら流す」という働き方
- Life is beautiful: スタートダッシュ型仕事術:実践編
- Life is beautiful: 私のとっておきのプログラミングスタイル
【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで8割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す(コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など)。
二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。
しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ(デス・マーチ)にハマるのがこのパターン。
確かにそのとおりだと思います。夏休みの宿題を早く終わらせれば、遊んで暮らせる。
でも、私は夏休みの宿題を最後まで残してしまう子供でした。当時も早く宿題を終わらせた方が良いのは分かっていました。でも、分かっちゃいるけどやめられない。今でも仕事をスタートするのが遅くて、ラストスパート型の仕事ばかりやっているように思います。
そこで過去の反省点をふまえ、どうやったらスタートダッシュできるようになるか、自分なりに考えてみました。スタートダッシュ型の人は100人に1人しかいなくて、99人はラストスパート型だそうなので、スタートダッシュ型になる方法論が分かったら100人中99人の人の役に立つはずです。
自分の経験を思い出してみると、なぜ最初に仕事が手に付かないのか。まず「何をすればよいのか分からない」というのがあります。何を目標にするのか(What)、どんな方法で実現すればいいのか(How)、何に価値を見いだすか(Why)の3つが明確になっていなかった。
出題者が意図したものと違うものを作ってしまったり、完成させることができなくなってしまったり、「こんな宿題をしても、どうせ役に立たないからしたくない」などと考えてしまったりするわけです。
つまり、What、How、Whyの3つが不確実でエントロピーが高い。エントロピーを下げると動きやすくなって、やる気も出るわけです。















