Ad Network

あわせて読みたい

  • あわせて読みたい

« モバイル・プログラミング入門:非同期通信でおもてなし | Main | このブログを統計解析してみた »

「作っては壊す」過程があってこそ良いものが作れる

 iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。

 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ(XMLOverHTTPはDataOverHTTPのサブクラス)、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController(HotEntryViewController)からModel側(HateneHotEntry)に移すことにより、難解になりがちなControllerのコードを大幅に簡略化して読みやすくした。

 この手の「大幅書き直し」をリファクタリングと呼ぶ人もいるが、私にとってはこの手の書き直しはプロジェクトの初期においては日常茶飯事。「これで完璧」と思ったものを次の日にさらに大幅に書き直し、なんてことも良くある。どんなに賢いエンジニアであっても、最初に思いついたアーキテクチャが最適であるなんてことはまずあり得ないので、この「作っては壊す」段階はより良いアーキテクチャに到達するためには必須の工程。焼き上がった壷が気に入らずにたたき割る陶芸師と同じだ。

 この段階で目指すことは、とにかくメンテナンスのしやすいコードを生成すること。プロジェクトも後半になるとどうしても大規模な書き直しはしにくくなるため、その場しのぎのコードでプログラムはどんどんと「きたなく」なって行く。その時に大きく影響してくるのが、プロジェクトの前半で書いたコードの品質。基盤さえしっかりしていれば、「その場しのぎコード」が多少混ざったところでなんとかなる。基盤がぐらぐらしていると、デスマーチあるのみだ。

 NTTの研究所にいた時にかいま見たウォーターフォール型の開発は、上流にいるエンジニアがフローチャートのレベルまでに落とし込んだ詳細設計書を下請けに渡して「コード化」するというものだったが、ここで完全に欠如しているのは、この「作っては壊しながら設計を改良して行く」という工程。

 私の経験から自信を持って言えるのだが、どんなに優秀なエンジニアでも、この「作っては壊す」という過程を経ずには良いソフトウェアは作れない。料理でも陶磁器でも同じだが、ソフトウェアには「作ってみて初めて分かる」ことがたくさんあるので、そこからのフィードバックを主任設計者が自らコードを書いて実感することがとても大切なのだ。

 ソフトウェアを作る上でもっとも難しいのは、顧客や内部からのあいまいな要求を詳細設計書に落とし込む部分であることは誰でも知っている。しかし、意外にちゃんと認識されていないのは、良い詳細設計をするためには、実際に設計者自身が(ここが大切、他人に任せてはいけない)プロジェクト初期段階で、自分が考えた設計をコードに落とし込んで「作っては壊す」という作業を繰り返しながら(コードではなく)設計そのものを「練り上げて行く」過程が必須だということ。

 それはシェフが新しく思いついたレシピに基づいて実際に料理をしながらレシピを改良して行く過程、もしくは陶芸師が焼き上がった壷のできを見ながら製造工程を改良して行く過程と全く同じだ。実際に料理を作らずにおいしい料理のレシピが書けるシェフがいないのと同様に、実際にプログラムを書かずに品質の高い詳細設計書など書けるエンジニアがいるはずがない。

TrackBack

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

Listed below are links to weblogs that reference 「作っては壊す」過程があってこそ良いものが作れる:

Comments

のろし

チームに無断でアーキテクチャを壊してプロジェクトも壊してしまった私がひっそりと通りますよ

HojiKo

すべて目が行く届くスケールならいいですが。
しっかりした「基盤」はやっぱちゃんと設計するのでは。APIコロコロ変えられると最悪ですし、基盤と上位のスケジュールが同じぐらいという事もあるでしょうし。

HALion

それにしても何でNTTはウォーターフォールが好きなんでしょうか。元々公社だったから何事もウォーターフォールなプロセスで仕事していて、それしか知らないからシステム開発にもそれを適用しているんでしょうか。紐の切れた凧のようですよね。伝統だけが残っている悪いパターンのような気がします。

心は萌え

俺的暗号翻訳

このエントリで言いたいこと。『上流工程をやるエンジニアはちゃんと自分でも作れ。』

gnety

確かにたった1000行くらいのプログラムでも何回もコアの部分の書き換えはしないといいプログラムはできませんね

nanasi

>NTTはウォーターフォールが好きなんでしょうか。
紙ペラ1枚の仕様書を作って、あとはおまえらがやれと丸投げできるからでしょう。
仕様書は出したんだから俺らの責任じゃないしと言いやすいとか:-P

じびき

今回の投稿にはとても賛同しました。やはり、作っては壊す、プロトタイプを作って試すというのは、とても有意義な事だと思います。

でも仕事でやるのはなかなか難しいですよね。管理されていなかったり、管理が甘ければ、隙をついてプロトタイプを作ったり出来ますけど、半日単位で監視されているような状態だと無理ですね。

車

自動車業界にいますが、ウォーターフォール型が実情にあっていないのがよく分かります。
この業界では、”絶対に”逆戻りは許されません。

つまり、最初の上流過程のロジック作成の時点で、不備の無い完全なロジックを作成すれば手直しが存在せず、
完全に成功するというのです。

そのため、上流過程のロジック検討の段階でDRBFM(=最悪条件を考慮した上で設計する手法
Design Review Based on Failure Mode)を何度も行い、徹底的に問題を洗い出します。

しかし、どんなに天才でも経験したことが無い問題を考えることは出来ないため、
初期段階で完全に問題を洗い出すことは出来ません。

ウォーターフォール型では、途中で不備が発覚してもロジック開発が一通り終わるまでは放置になります。
そして、ロジック開発が終わった後で、そのロジックを修正するためのロジックを検討し、また
ウォーターフォール型の開発を始めます。

ほんとーに馬鹿馬鹿しいですが、今の自動車業界では完全な一強皆弱であり、
その一強がウォーターフォール型を強制している以上は仕方ないのですが…。

M.Suzuki

ウォーターフォール型の開発は、そのまま下請け孫請け曾孫請けと言う会社構造に合わせやすいからでしょう。
NTTに限らずプロジェクトメンバーの多いプロジェクトでは、開発者の質を(日本では)個別に管理できない(しない)ため、上級工程で事細かく書式化する事で大きな質のブレを抑えている・・・と言うのが私の認識です。
極端に良くもならなければ悪くもならないと言うのは工業製品としては優秀なんでしょうけどね(^^;

バルタン

優秀なエンジニアとそうでないものとの違いでしょうか?何度も作り直すことはできないのではないでしょうか?開発スケジュールだって決まっているはずですし。そもそも開発スケジュールをどのように決めるのでしょうか?開発する規模を見積もって、これくらい規模だとこれくらいの期間かかる、だから作り直しは2回まで、、、とか言うようにしているのでしょうか?すいません、自分は時代遅れかもしれません。

kazumichi

ここ10年、さまざまな業務系のシステムインテグレーションの世界を見てきましたが、
日本は特に建設業界と同じような製造工程を踏んでいます。


建築業界は建築基準に則った設計をベースに実際の物理的なアウトプット(ビルが建つなど)ができますが、
業務系システムインテグレーションでは「業務」という常に不確定要素を含む「目に見えにくい」アウトプットを出していくことになり、この「目に見えにくいアウトプット」という成果物をいかに予算内で実現するか?が常に問われます。


よって、建設業界の製造モデルのようなウォーターフォール型のほうが
不確定要素を極限まで無くし、型にはめて実行に移すことができるので
みんな楽なんだと思います。


しかし、小生は中島さんのご意見と同じで、「作って壊すこと」が
ソフトウェア、そしてソフトウェアエンジニアたるものの存在意義であり、
「壊すことを恐れずに必ず成し遂げること」がモノづくりの原点だと
考えています。


日本の大手システムインテグレータでプログラミングを現役で出来つつ
設計もできる人間はかなり少なくなってしまっているのが現状です。


本当にソフトウェアが作りたくてこの業界に現役で活躍されている方は
ほんの一握り。

そもそも業務システムなどの開発案件で、
「ほんとはコンピュータシステム化しなくても、物理的な業務改革で効率化できるやり方があるのになぁ」なんて思うことが多々あります(^-^;

なげるな

今は過渡期で、いずれはウォータフローでもちゃんと回る時が来る。

土方を経験しなければ優秀な建築家になれないなんて、ナンセンスだろ?

humu

そもそも上位で設計する人間が実際に作業を行う現場を見たことも無い,
知らないためにどんなにスバラシイ設計が出来たとしても成果物は役に立たないものが多い
TOPが強ければ強いほどその傾向が多い

TOPは曖昧な仕様を曖昧な指示のまま下に流すため下で実際にコードを組む人間が
結局上流に遡ってその場で決めることになる
日本で綺麗な形でプロジェクトが流れてるのを見たことが無いのですが・・・
海外だともっとスムーズに流れるものなんですかね?

oda

いつも興味深く拝見していただいています。

自分の職場(組み込み系)を考えると、
「作っては壊しながら設計を改良して行く」
は、実践するのが難しいと感じます。
例え、上流・下流の開発構造がなくても。
(理由)
 設計書を見せて、レビューしてもらって、
詳細設計書がほぼ固まってから、コーディングしないと動かない。

 自分の職場は、基本仕様の概要や修正案件が
上のほうから降りてきて、設計するところから、
始まります(※軽微な修正は、設計書は書かない)
 自分ひとりで、上流から下流をやってる感じですね。

 さて、中島さんの「作っては壊しながら設計を改良して行く」
ですが、これは、コーディングしテストしながら、設計を練りこむと理解していますが、自分の職場だと難しいです。
 他制御の方や上長にレビューしてもらいつつ、基本仕様書ー>詳細設計書とドキュメントを詳細化して固まらないと、コーディングできないです。
 なぜなら、詳細設計書まで固まらないと、他制御の機能とうまく連携できなかったり、自制御内の他の関数とうまく連動できなかったりするからです。

 中島さんの場合(マイクロソフト時代)は、自分と違って、組み込み系ではなく、純粋なソフトウエア開発ですが、他制御の方との連携を確認するために、詳細仕様所が固まるまでコーディングできない、ということは無かったのでしょうか。

Post a comment

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