開発のしやすさを重視した仕様を作成しよう

開発のしやすさを無視した仕様は成功しにくい
に関連した記事です。

「最終実装のCPUボードはこれだから、全ての開発はそのボードでいいよね」

間違っている理由：
　・最終実装の外部仕様・内部仕様、設計の詳細が全て自明になっていることはまずない。
　　開発しながら明らかにしていかなければならない要素がある。
　・開発に必要なコンパイラ・エディタなどのツールの使い勝手が
　　開発の速度を上げるの必須。
　　（場合によってはクロスコンパイラが必要）

　

「製品には画像の表示はないから、開発中でも画像の表示ができないCPUボードでいいよね」

間違っている理由：
　・画像の扱いが適切であることを確認するための枠組みが必要。
　そのボードでXの表示ができて確認ができれば
　プログラムの実行中に不具合を目視で見つけることが可能だが、
　Xの表示がない場合、
　結果の画像を保存して、ftpで画像を転送して
　別のマシンで表示するという方法しかできなくなる。
　
　　問題の発見や対策がとても限られた状況になる。

「実装はC言語と決まっているから、プロトタイピングでもC言語でお願いするよ」、「僕は○○言語なんてわからないから、C言語でお願いするよ」

間違っている理由：
　プロトタイピングは、楽をしてアルゴリズムの妥当性を検証することです。楽ができる理由は、目的のライブラリが充実している言語を使うことにあります。ここでC言語を使ってしまうと、本来の実装と同じ開発量を必要としてしまって、少ない工数で設計の妥当性を検証しようすることを達成できなくなります。
　設計が正しいのか、要求仕様が適切なのかが、プロトタイピングをしてみないと気づかないことがあります。プロトタイピングをせずに実装して、そのプログラム中の関数の要求仕様が期待したものではないことが判明したりすることもある、
　早い段階で設計の妥当性を検証しておくことが、製品のプログラムの開発を成功させるポイントです。

「どうせ、それは開発時点でしか使わないんだから、そんなものにお金をかけられないよ。最終製品に使うもの以外に金をかけるのは言語道断だ。」

間違っている理由：
大きな建物を建てるときには、建物の中にクレーンが設置されることがあります。
家を建てたり、外装を補修する際にも足場を組みます。どちらも、建物を建てるという「開発段階」でしか使わないもので、最終成果物に残るものではありません。でも必要のあるものにはお金をかけています。
　ソフトウェアといういわば”建築物”を作りあげるには、クレーンや足場が必要であることを理解してください。

「昔はそんなのがなくたってちゃんと開発していたんだ。それがないと開発できないなんて言うな。」

間違っている理由：　
　SVNやgitなどのバージョン管理ツール、Redmineのようなオープンソースのプロジェクト管理ソフトウェアなど、今の時代の開発には必須のツールです。動いている例を見せてもらうことです。また経験者の声を聞くことです。バージョン管理ツールが(ファイル単位の管理だった)貧弱だった時代と、今ではソフトウェアの生産性が10倍近く変わっているように思います。
　開発者がいうことには、それだけの根拠があります。

「製品として残るコード以外書くな。デバッグをしやすくするためなどいうコードを書いている暇があったら、さっさと製品のコードを書け。」

間違っている理由：　
　製品として残るコードは正しいコードであることが必須です。間違った製品コードのリリースは、多額の損失を発生させます。間違ったコードを製品として書くよりは、コードをリリースしていない方が格段ましだと私は思います。
　ソフトウェアの開発を進めていく中で品質をどう確保するのか、そのことを考えてください。

「どうせ自分たちで書かなければならないコードなんだから、市販のライブラリを買ってみるなんて言うな。」

間違っている理由：
　ソフトウェアを開発する時点では、対象のライブラリについて、必ずしも正確な理解をしきっているわけではありません。もし、そのライブラリが有用であって、無理のない価格であったら購入する価値はあります。ある関数の動作についての解釈が正しいのかを検証するための比較のライブラリになります。
　FTPのソフトウェアを開発していると仮定しましょう。既存のFTPのソフトウェアと動作を比較することは、開発しているソフトウェアの健全性を検証するのに役立ちます。
　製品の中で、他社のライブラリを購入して利用することは、価格の上昇につながるので、自社でライブラリを開発したいとします。そのような場合でも、当初の開発は、他社のライブラリを購入して開発し、それ以外の部分の開発を進めて、製品のソフトウェアの見通しを早めにつけることを推奨します。その後、必要な関数だけを自社開発すれば、他社ライブラリを使わなくて済むようにできます。
　ですから、自分たちで書かなければならないコードでも、市販ライブラリを買うことは、開発速度を上げるのにとても有効なのです。

「成果物としてのライブラリのインタフェースには、そんなのないんだから、『単体テストをするためのインターフェース』だって、いい加減にしろ。」

間違っている理由：
ソフトウェアの品質管理の近年の動向をつかんでいますか。マネージャーとして組織の方向性を導いていくとき、必要な動向をおさえてみてください。単体テストでのカバレージが一定水準を超えていないと、製品として受け入れないという組織もあります。
　単体テストを可能にしないライブラリは、後々トラブルを引き起こす可能性が高くなります。

「とにかく、うまく動きゃいいんだ。『設計がおかしい』だなんて抜かすな。」

間違っている理由：
どうやってソフトウェアの品質を確保しますか。
品質が不十分だったことが判明したときに、どれだけ損失を発生するのか考えたことがありますか。

関連する追記：

開発速度が上がる順序を考慮して実装を行っていこうとして別記事にしました。