設計書の自由度について
誰が書いても同じコードになる設計書、これいいなって思った。私は数年前は、コード書く人に自由度を残す設計書を書いてて、後輩も「その考え方良いですね」って言ってたけれど、それは同じ人が設計書とコードを書いているからで、別の人が書いたらそこは考慮の漏れているバグ余地なんだよな。
まなめはうす
その通りなんだよなぁ。
自由度が大きくなれば、解釈も広がるし。
でもこれは↓が本当の問題ではないかと思う。
マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを構築する。
黒船の大砲がソフト業界に構造改革を迫る：田中克己の針路IT：ITpro自動車だと、同じマフラーを作り続けることができるけど、システム開発の場合は、同じマフラーを作ることは意味がない。同じプログラムを作り続ける意味がないからね。
SIにあてはめると、外部設計を作り続ける会社、内部設計を作り続ける会社、プログラムを作り続ける会社に分業化するってことでしょ。
今と一緒ジャン。そして、インテグレータが上澄みをはねていくと。
マジでいっておくと、今のSIerの生産性が低いのは、要件定義、外部設計、内部設計などの各工程で、分業(別会社に発注)をやってるせいです。分業するからコミュニケーションロスが発生する。
2008-03-05 - ひがやすを blog - SIerが自動車産業をまねしようとするのはいい加減やめなさいというid:higayasuoさんのエントリがあった。
SIerの生産性と、自分の意識 - techlogアジャイルな方法論はこれとはまったく異なる方針をとっている。用意している役割はただひとつ、ソフトウェア開発者だけだ。そして、それを担うのはあなただ。チームで行動し、顧客とも緊密に連携してソフトウェアを開発する。アジャイル開発で信頼をおくのは人だ。
僕が目指したいのはこれだ。
用意している役割はただひとつ - アジャイルプラクティス - techlog
# 引用の入れ子が激しすぎる･･･。
というわけで、ある程度自由度のある設計書を使って、「ソフトウェア開発者」が開発を行うのがいちばんなのかな。
GoogleのDesign Docみたいな感じ。
Design Doc
Google で必ず書くことになっているドキュメントへ〜たのめも:Google のソフトウェア・エンジニアリング
- プロジェクト立ち上げ時の 1〜2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。
- 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それはまた別プロジェクトになることが多い
- Design Doc の内容
- プロジェクトの背景、目的
- おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
- プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
- セキュリティやプライバシーについての考察(問題と対処方法)
- テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
- レポジトリ上の位置やサーバのアドレスなど
- コードを書いていると解離していくので、できるだけ解離しないようにアップデート
SIerでやっても、たぶんきっとぜったいうまくいかない。
でも、僕にできることもあると思う。
自分の考えた方法が正しいかどうかはわからない。
でもこの方法が正しいかなって、ちゃんと考えることは大事だと思っている。
いろいろ考えて出した結果が間違っていたら、何が間違っていたのか考えればいい。
誰かに迷惑を掛けてしまったのなら、謝ればいい。
なんとなく皆がこうやってるからやってます、というのは良くないと思う。
SIerの現状を考えると、本当に詳細な設計書を作るのが正しいのではないかと一時期思っていた。
でもこれにはいろんな問題があることに気付いた。ひがさんが書いていたのは、ほんの一部だと思う。
これについてはまたいつかどこかで。
ちなみにid:manameさんは、いまはどんな設計書を書いているんだろう。
