システムの目的･･
システム設計書には、必ず「システムの目的」という項目があります。
企業がシステムを導入する場合は、必ず何らかの経営メリットを求めるはずです。
しかし、中には「これが目的ですか･･??」と思ってしまう内容の物もあったり、内容が抽象的すぎて、目的がぼやけている物もあります。
こんなプロジェクトの中には、崩れて顧客と開発ベンダーとの係争に発展するものもあります･･。
「･･効率アップ」
「･･基盤づくり」
「･･見える経営」
「パッケージありきの文言･･」
こんなキーワードが書かれていたら要注意！ですね。
もう１つ大切なのは、「顧客と目的を共有する」です。
ベンダーが勝手に設定する物でもなく、発注企業だけが思っている物でもありません･･。
お互いが目的を共有し、プロジェクトを進めていくことが重要です。
その機能、本当に必要･･?
ソフトウェアの複雑化・多様化にともない、求められる品質は日に日に高度化しています。
従来の品質は、書かれている仕様書通りの動きをするか?に注力されていました。
最近は、そもそも「この機能は本当に必要なの!?」と云う、『機能の妥当性』をチェックする必要性が言われています。
上流工程で、これを評価する仕組みや、テストエンジニアの育成が重要になってきているように思います。
スケープゴート
あまり使いたくない言葉ですが「身代わり」のことです。
プロジェクト崩れが発生すると、スケープゴートを作って自分は逃げようとする自己保身の人間がまれにいます。
この時、スケープゴートにされ易いのはPM（プロジェクトマネージャ）です。
プロジェクト崩れが発見されるのは、試験等の後半に多く手遅れになるケースもあります。
しかし、崩れは急に発生するのではなく徐々に悪化し、あるタイミングで発覚することになります。
実際プロジェクトを担当している人は、実は早い段階から「おかしいぞ･･」と気付いていることが多いのです。
崩れが発生してから騒ぎ立てたり、スケープゴートを仕立てるのは、母体組織の長であることが経験から多いです･･。
よくプロジェクトを機関車に例えます。
スタート段階では、母体組織の長も入って機関車をレールの上に乗せ、走り出すのを見守ることが大切です。
子育てと同じですね！
ソフトウェアの保守性･･
先日、このテーマで社員と少し議論をしました。この手の話しは、暗黙知の世界が多く、範囲を限定して話しをしないと発散してしまいます。
我々は、ソフトウェアを設計し、お客様に納品するまでは、多くのパワーを掛けます。また、管理手法もいろいろな物があります。しかし、開発以上にコストと時間を掛けている「ソフトウェア保守」についてはあまり関心が無いようにも見えます。
納品後に発生する要求に対し、いかに容易に対応できるようにしていくか･･という「保守性」についてはソースコードだけでなく、ドキュメントなども重要になります。
もう一つ重要なのは、ソースコードをいかに読みやすくするかという「可読性」という面も重要です。また、属人的なものをいかに排除していくか･･も大切なポイントとなります。
何か属人的な物ではなく、新たなメトリックス（物差し）が必要な気がしています。
難しい課題です･･。
