中島聡さんのスタートダッシュ型仕事術に、考えさせられました。
最初にスタートダッシュすれば、初期に全体の見通しが立つから、失敗作ができても捨てればいいので、品質の良いものを作り出せる。
- Software is Beautiful：第2回 「締め切りは絶対に守るもの」と考えると世界が変わる｜gihyo.jp … 技術評論社
- Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
- Life is beautiful: スタートダッシュ型仕事術：実践編
- Life is beautiful: 私のとっておきのプログラミングスタイル
【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで８割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す（コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など）。
二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。
しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ（デス・マーチ）にハマるのがこのパターン。
確かにそのとおりだと思います。夏休みの宿題を早く終わらせれば、遊んで暮らせる。
でも、私は夏休みの宿題を最後まで残してしまう子供でした。当時も早く宿題を終わらせた方が良いのは分かっていました。でも、分かっちゃいるけどやめられない。今でも仕事をスタートするのが遅くて、ラストスパート型の仕事ばかりやっているように思います。
そこで過去の反省点をふまえ、どうやったらスタートダッシュできるようになるか、自分なりに考えてみました。スタートダッシュ型の人は１００人に１人しかいなくて、９９人はラストスパート型だそうなので、スタートダッシュ型になる方法論が分かったら１００人中９９人の人の役に立つはずです。
自分の経験を思い出してみると、なぜ最初に仕事が手に付かないのか。まず「何をすればよいのか分からない」というのがあります。何を目標にするのか(What)、どんな方法で実現すればいいのか(How)、何に価値を見いだすか(Why)の３つが明確になっていなかった。
出題者が意図したものと違うものを作ってしまったり、完成させることができなくなってしまったり、「こんな宿題をしても、どうせ役に立たないからしたくない」などと考えてしまったりするわけです。
つまり、What、How、Whyの３つが不確実でエントロピーが高い。エントロピーを下げると動きやすくなって、やる気も出るわけです。
では、どうやってエントロピーを下げるか。
まず見積もりとスケジュールを立てる事。これは記事に書いてありました。
①「ほぼ確実にできるタスク」だけを抽出して，まずはそれのスケジューリングをする。予測不能なものについては，正直に「現時点では見積りができない」と宣言し，必要ならば「見積りをするための調査期間」をもらう
まず①だ が，「締め切りは絶対に守るもの」ということを常に念頭に置いておけば，「3ヵ月でリリース可能なところまで持っていく」みたいなあいまいなものではな く，「この機能の実装には1週間」「このUIの追加には 3日」という，より明確に定義された細分化されたタスクリストになる。
当然だが， プロジェクトの最初の段階では見積りすら不可能なタスクもあるものだが，その手のものを「今までの経験をもとにざっくりと」見積 もるのはとても危険である。そういう場合は，まずは3日とか1週間の「調査期間」をスケジュールしてもらい，その期間に実際にプロトタイプを作りながら 「タスクの難易度」を測定するのだ。その間に「これなら作れる」という感覚が得られたのなら見積りを出すし，それでも無理ならば「相当難しいタスク」と覚悟したほうがよい。
その場合，この手の「難易度の予想が難しい」タスクをほかのタスクより先にやることがとても大切である。それが「相当難しいタスク」であるかどうかを見極め，全体のスケジュールを見直したり，機能変更をするのは早ければ早いほど良い。
Software is Beautiful：第2回 「締め切りは絶対に守るもの」と考えると世界が変わる｜gihyo.jp … 技術評論社
見積もりとスケジュールで、何をするか(What)と、どうやってするか(How)をある程度明確にできそうです。
あと、忘れてはいけないのが、仕事とは何かの役に立つためにするということ。何に価値を見いだすか(Why)を把握しておかないといけません。価値があいまいなままスタートダッシュしても、価値が無いものができてしまいます。これは、スタートダッシュの前に終わらせておくことだと思います。
三方よしがその「何か」になります。「売り手よし、買い手よし、世間よし」です。
まず「売り手」です。その仕事で生活しているからには、利益がでなければいけません。利益が出るような市場を選んでいることが大事です。失敗が見えている仕事、自分のポリシーに反する仕事は断ることもあります。また、仕事にやりがいがあればやる気もアップします。それが自分にとってどんな仕事であるか見極め、やりがいのあるものに変えられるなら変えていきます。やりがいが、車や飛行機にとってのエンジンのようなものです。車でも船でも飛行機でもいいですが、自分が何かの乗り物だとイメージすると楽しいです。
次に「買い手」がいます。顧客が何を求めているのかはっきりさせておかないと、完成した後で、「こんなはずでなかった」と言われていまい、失敗します。要件の聞き取りには、ある程度の時間をかけるのが良いでしょう。これが上手くいくと、外部からエネルギーを受け取れます。銃の弾丸は自分では動く力は無いですが、外部の火薬から運動エネルギーを受け取って進みます。ビリヤードの球が動くのもそうです。
最後に「世間」です。その仕事をしていることで、「世間」をよくすることに貢献すると思えれば、やる気も出ます。逆に「世間」に悪影響を与えると考えられるなら、それを無効化する方法を考えるか、断るべきです。例えば、公害がでるような製品で、地域住民に迷惑がかかると、結局は会社の評判が下がり、会社にとってもマイナスです。だめなら、だめな理由を示して顧客を説得します。
まとめると、問題点を全て洗い出し、それを無効にしてから、やっとダッシュができると思います。問題点を無効にするまでは、ゆっくり進まないと大けがをする。ゆっくり、ダッシュ、ゆっくりの順にするので、仕事全体はS字曲線になると思います。
イノベーター理論(1) | マーケティング・コンセプト | ミツエーリンクス
これはイノベーター理論のS字曲線です。結局こうなるのではないか。そして導入初期に問題点を無効化することで、そのものが持つ良い面が浮かび上がってくれば、離陸（＝ダッシュ）が成功するのではないかと思います。
松浦彰夫 拝
コメントする