プログラム設計の考え方
プログラム設計時における注意点をしめします。
設計一般
- イメージとモデル化
図や自然言語で簡素（要素をよりすぐって）に表現します。 - シンプル
単純・同型・対称・階層・線形・明証・安全の観点から、とことんシンプルを追求します。 - 自然であり、わかりやすく
不自然な形、素直に考えてその結論にならない場合、設計が間違っている。自然体で美しい設計をめざそう。 - 機能仕様は、｢外｣（仕様：使い方）の設計であり、内部仕様（実現方式）と区別します。
外部仕様が絶対優先。内部仕様と区別して設計します。
一言でいえば、「美しい」設計になっていることが重要です。「動けばいい」とか「論理的にミスがない」というレベルでは、プロとしては失格です。
美しい！といわれる設計をめざしましょう。
全体設計
- 全体からみた機能のバランス
使い方、順序からみてバランスがとれた機能となっているか。 - わかりやすい動作か
利用者からみて、アウトプットは直感的に想像でき、わかりやすくする。 - 実現可能性の見積もりをしているか
単位時間あたりのデータ処理量や計算量が実現している機能にマッチしているか。いくらいい機能を開発しても、現状の環境で実用にならないレスポンスや使用資源量では意味はない。 - 機能は盛り込みすぎていないか
新規開発では最初は基本機能に絞って提供するのがよい。提供後にユーザの要望を盛り込んでいく方が機能面でも開発面でも効果的。
仕様書の改版
機能仕様や構成仕様は、プログラミングへの入力となるもので、必ず参考にして作成する。また、プログラミング以降の開発工程で、仕様書の変更が発生した場合は、すみやかに仕様書を変更する。また、関連部門がある場合は、変更情報をタイムリーに通知する。
内部仕様の都合で外部仕様を変更（改悪）してしまったり、単純化のつもりで大事な仕様を落としてしまうことがあるので注意して欲しい。
工程完了時のセレモニー
各工程の完了時に、完了した根拠（数値等）、反省点を明確にし、担当者で意識合わせするセレモニーを行うとよい。
メリハリをつけられるし、下手な進捗管理よりいいのでは。その後、宴会なんていうのもいいねえ。
軌道修正の提案を誰がするか？
責任と権限を定めて仕事していると思いますが、プロジェクトの失敗をみると自分に権限がないと決め付けて、何もせず後で、のっぴきならない状態になる事があります。
権限というのは、最終決定者であり、軌道修正の提案は、誰でもできます。それを取り違えると、一番よくわかっている人、一番苦労している人がさらに苦労する循環におちいることになります。
例えば、企画書や開発計画書で機能範囲を決めたので変更できない。とか、
出荷スケジュールをこう決めたからずらせない。とか、
よく考えもしないで、全ての前提条件をクリアして問題を解決しようなんて、ムシがよすぎます。
どんな前提条件も変えられるという認識をした上で最良の解を考えるべきです。極端に言えば、製品開発を中止することだって選択枝として存在するわけで、やり続けることで何百億も損して（ビジネス損失）回収するメドがないなら、製品開発の中止が一番よい解決方法です。
早くしたほうがいい。（現実そういうことがあるが、諸般の事情で中止できないでいるプロジェクトをいくつも知っているが・・・）
最良の解の基準は、最大優先事項はビジネスです。ビジネス（売上[利益]、顧客満足度、ブランド）を最優先に考える。
自分やプロジェクトのメンツではないことを考えて欲しい。 開発担当者だけでは、どうにもならない（工数や工程の再調整など）こともあるが、そうしたこともトータルで考えて提案をしていくようにすべきです。
