失敗のリスクを減らす目標の設定を #ソフトウェア開発

失敗する事例を見ていると、失敗するだけの理由があって失敗しているのが分かる。
「負けに不思議の負けなし」
というように、失敗を繰り返しているときはそれだけの理由がある。

開発テーマのマネジメントをするリーダーは、そのことを承知して開発目標を立てて欲しい。
開発メンバーの方としては、失敗の可能性を減らす目標の設定を、リーダー対して働きかけよう。
問題の切り分けができるように自分の担当分のコードを書くこと。
単体テストを実施すること。

潜在的な危険についての情報を、他のメンバーと共有すること。

自分の担当のコードで失敗をしないことは大切。
でも、仕事が成功するためには、全ての部分のコードで失敗させないことが大切。

全体で１つのシステムであるものを、対等な関係の3社に分割して発注する。そうするとその3社を調整する仕組みは働かなくなる。
- 某銀行のシステムです。
技術の評価と入札金額とがある官公庁の案件の開発で、入札金額が安いが技術の評価も一番低い業者を選択する。
「現行業務の延長でシステムを開発してほしい」と契約後に開発方針を大幅に変更してしまうこと。
- 某官公庁のシステムです。
現行の業務システムの業務手順の自体の見直しをすることなしに、新システムだけに無茶な期待をする。
- 新しいシステムで例外的な記述の少ない一貫性のある記述をしたいと望むのならば、現行の業務手順自体を単純化することが必要。
- もう既に意味をなさなくなっているコード、意味をなさなくなっている規定を削除して、実際の部分を単純化することなしに、新システムならばうまくできるだろうと期待すること。

要件定義に失敗している。
- 「要件定義が十分に明確である。その特定のモジュールの実装にだけ失敗している」ことで開発に断念となった事例は聞いたことがなし。
- 「要件定義が十分に明確である。その特定のモジュールに実装にバグを生じた」のが、本番の運用時に露見して失敗する事例はある。
変更の生じやすい部分と、変更の生じにくい部分とに設計を分離しないために、何か変更があるといたるところに設計変更を生じてしまう。
- 例：Model View Controllerは、View　（ユーザーインタフェース）を置き換えやすくするようになっている。
- オープン・クローズドの原則（OCP: Open-Closed Principle）

なんかオブジェクト指向という枠組みの中での話なので「抽象」という概念がフォーカスされてる感じあるけど、「（仕様）変更が起きた時に修正が少なく済むように設計する」というコンセプトが一番重要っぽい。そう解釈すると、プログラミングという行為において一番重要な原則に感じる。

ハードウェアも含む場合だと開発目標を十分に明確に絞り込めないままに、あいまいな開発をしてしまう。うまく行っているのかいないのか、うまくいかない理由が何なのかがはっきりしない状況を生み出してしまって、問題を解決することができなくなる。

ハードウェア・ソフトウェアの両方についてだと思うが、開発内容の要件定義をどれだけきちんと行なえるかというのが、開発において一番重要なことだと思う。要件定義は開発者に対してこう作ってあれば十分だよと言い切れるものでなくてはなりません。

チェックポイント

明快になっている技術要素は、調べまくる・聞きまくるで解決できる可能性がある。

　明快になっていないということは、何が課題なのかを自力で考えまくるということです。

不明確な部分が一部に残るということは十分ありがちな状況です。
　しかし、その不明確な部分の影響を一部におさえて、
　それ以外の部分は、不安要因がなく確定していると言い切れる状況を作ることです。

私がかつて関わったプロジェクトの中では、、どうやってもその不安定な要素に対して解決策を見出すことができなくて断念したものもありました。

付記：多数の改変を同時に行なえば失敗の率は高くなるのに対して、ソフトウェアの場合には工夫のしかたがあります。

バージョン管理ツールにgitを使って、ローカルでの管理をすることです。コンフリクトが生じないように分業しつつ開発をすることです。そして、それぞれの改変に対してテストを行なうことで、失敗しやすくなるのを防ぎやすくなります。

そうなる理由の違いは、SVNとgitのバージョン管理の違いです。gitの方がローカルでの開発がやりやすいのです。その様子については、既に書かれている記事を参照してください。

失敗のリスクを減らす目標の設定を