スタートダッシュ型仕事術：実践編

　昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。

　まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。

　ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部分の見極めのためのコーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大切。

　まだ半信半疑の人も多いだろうから、具体的な例をしめそう。先日のエントリーにも書いたCloudReadersとneu.Notesのコードを組み合わせて「PDFの赤入れ」を可能にしようというプロジェクト。当初計画していたアーキテクチャではうまく行かず、次のアーキテクチャで作ってもうまくいかず、ようやく三番目で「商品化する価値のあるアーキテクチャ」にたどり付けた、という典型的な「大幅な仕様変更を伴う」プロジェクトだ。

　実際にどうやって作ったか言えば、「仕様書も書かず、UIの細かな設計もせず、とにかく肝となる部分をスタートダッシュで手早く作る」を三回繰り返しだだけのこと。一つ目のアーキテクチャに基づくプログラミングに約３日かけた後、それを破棄、二つ目のアーキテクチャに基づくプログラミングに約２日かけた後、それを破棄、そして三番目のアーキテクチャに基づくプログラミングに同じく２日だ。

　この段階で大切なことは、

• 書いたプログラムを捨てることを恐れないこと
• この段階で仕様書を書くことは時間の無駄と認識すること
• 細かなことを無視して、一番難しい部分を最初に作ること
• できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと
• コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること

の５つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定しているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと（たとえば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど）に時間を使わず、とにかく一日でも早く「見極め」ができるところまで持って行く。

　この「見極め」の段階で、「このアーキテクチャではだめかも知れない」「これではユーザーモデルに矛盾ができて使いにくくなる」と感じたら、ばっさりと切り捨てて、もう一度作り直す。アーキテクチャに不安を抱えながらずるずると作り続けても決して良いことはない。

 

 【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで８割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す（コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など）。

　二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。

　しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ（デス・マーチ）にハマるのがこのパターン。

Comments

[Tiger's Wood]

結局何を言いたがっているのか？と隠された本心を解析いたしますと、
（本人も気づいていないかもしれないとして）
iPhoneとガラパー携帯のソフト開発の問題点について言及していて、
尚且つ救いようのない酷い成果品(コード)について批判をしてるんです。どちらとは言わずもがな・・・
しかし、こうも違う方向性は、何が悪いのでしょうか、個人に創造性などの能力が無いのか、
枠組みが悪いのか、仕組みが悪いのか、それとも政治が悪いのか・・・全部？
イージー・ライダーと暴走族の違い？？

ガラパー：ガラパゴスのパーのこと

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[Kuwa]

かのビリー・ワイルダーは、撮影に入る前にシナリオを練に練ったと言います。
その方が、結局早く、予算も少なく、しかも完璧に近い映画が作れるからという理由で・・・
一見すると、ラストスパート型に思えるかもしれませんが、コアとなる部分（＝シナリオ）を何度も練るというのは、コアの部分を一気に作り始め、作り直す労力に近いように思います。つまり、スタートダッシュ型と解釈できるように思います。

[shimohiko]

自分もエンジニアですので、「とりあえずガーッと作ってその途中でもっといい方法に気がついて今までを捨てて作り直す」方法が好きです。その方が最終的に拡張性が高かったり、不具合を追いかけやすい構成になったり、何かといいことが多いです。
ですが、チームの中でコーディングすると「いつ終わるのか、どれくらい進んでいるのか」を報告する必要もあります。そういう時に、このやり方だとどうやって報告すればいいのか、をいつも悩んでしまいます。