Ad Network

あわせて読みたい

  • あわせて読みたい

« 「時間に余裕があるときにこそ全力疾走で仕事し,締め切りが近づいたら流す」という働き方 | Main | iPadアプリ開発日誌: neu.Notes 1.3 リリース »

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

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

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

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

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

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

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

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

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

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

Drawing-9 

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

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

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

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c4f9853ef013485916af5970c

Listed below are links to weblogs that reference スタートダッシュ型仕事術:実践編:

Comments

Tiger's Wood

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

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

Kuwa

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

Kuwa

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

Kuwa

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

Kuwa

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

Kuwa

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

Kuwa

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

shimohiko

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

Munehiro

僕が関わっている日本の会社では、なるべくコード変更をしたくない(彼らに言わせるとスケジュールが読めないから)前提で動いているので、アーキ変更などもってのほか。駄目なアーキのまま小手先で対応しようとするので、3番目のデスマパターンを何世代も繰り返していたりします。

結局はマネージメントの問題な気がしています。

ty

ヨーロッパの会社ですが、少人数がSprint単位でStoryを達成し、動くものを
作っていくというAgile開発が、考え方としては広まっています。
実際には、ツール・環境(バージョン管理/自動ビルド/自動テスト)をうまく使い、
Storyにフォーカスし、インターフェースを適切に定義しながら、協力しながら
進めていくのは簡単ではないですが。
日本では、意識してAgile開発を進めているところは少ないようには見えます。

koji

脇道にそれますが、このブログではなぜ同じ内容のコメントを複数回投稿するユーザが後を絶たないのか不思議です。何かコメント投稿の構造上の問題があるのか、単にせっかちな人が多いのか・・・。
そこで自分でPostしてみたくなりました。

koji

何も構造上の問題は見受けられませんでした。
せっかちな人が多いようです。
ブログコメント投稿マイクロタスクに対する丁寧なテストが必要なユーザが多いようです。

H Shimizu

この方法がうまくいく事は、私も経験から学びました。正しい方法だと思います。疲弊する事や、予算超過も防げますし、何より、終わった後の気持ちのよい達成感を味わうことができます。
一方で、さらなる仕事を振られてしまったり、他のトラブルプロジェクトの火消しに回されたりして、結局、「できるはずのものができなくなってしまった。」、絶望感を経験した事もあります。なので、マイナス思考なコメントが多い事も理解できます。
しかし、これは仕事の進め方以前の、別の問題だと思います。こういう本来の仕事の進め方ができない、日本のソフトウェア業界を変える必要がある事を、もっと皆さん主張すべきではないかと思います。

PS

PhotoShareの上下反転バグを直して下さい。
早くスタートダッシュを始めてください。

ettem

数人での7日の規模のソフトならこのやり方も可能なのは分かりますが、WindowsやInternet Explorerのようなソフトでも可能なのでしょうか? アジャイルと一緒で理想的な方法に見えますが、小規模開発にしか向かない気がするのです。

それに、最初に80%できてしまうと、上層部から捨てないように圧力がかかる事が容易に推測できてしまいます。(プロトタイプモデルの開発手法でプロトタイプが捨てられなくなるように)

palm4


たしかに大規模プロジェクトでは難しいかもしれませんが、逆にむしろその効果は大のような気がします。スピルバーグも凄まじいほどの早撮りで、3時間の大作『プライベート・ライアン』はわずか2ヶ月で撮影を終えたそうです。本人の持論として、自分自身や役者など関係者の情熱が熱いうちに作ってしまうのが一番良いと考えているそうです。そして予算もその方が安くあがるそうです。どんなプロジェクトもそれを根底で支えているのは、人の心の中の情熱やモチベーションです。それはどうしても時系列で低下して行きます。夢や理想だったものが現実となり、現実の問題として具体的に自分と関係し始め、同時に現実としてそのアラも見えてくるからではないでしょうか。さらにはもっと魅力的なアイデアが頭を占有してしまう可能性もあります。(結婚などもそれに近いかと、長年つきあっても逆に結婚は遠のくことが多いことがあるかと)完成形が見えてくる前に80%作ってしまうのは、たしかに得策だと思います。最近では、iPhoneOSもスピード開発だったと思います。そのために本家のOSXの新版リリースを延期したほどです。ただし、大規模プロジェクトでそれをやるには、スピルバーグやジョブズのような強力なリーダーシップが必要だと思います。個人なら自分がそうするだけですみますが。


Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.