ソフト開発監査の監査当日（６）ソフト開発に必要な機能と担当部署（後半）
（４）購入ソフトやフリーソフトの品質確認機能
ハードウエアの大規模化の恩恵もあり、最近の組み込み系ソフトもどんどん規模が大きくなってきています。その結果、全てのソフトを自社で開発する事はできなくて、多くのソフトを購入したりフリーソフトを導入したりして、ソフトのシステムを作りあげる事が増えてきました。特にインターネットとの接続が必要な製品では、LinuxやAndroidやWindows のような既存のOSの上にアプリケーションを載せて必要な機能を実装する事が殆どです。
ところで、これらの購入ソフトやフリーソフトの品質は大丈夫なのでしょうか？ ソフトである限り、どこかで誰かがソースコードを書いてコンパイルされた実行プログラムを誰かがテストしているはずです。でも、そのテストの量や質は自分達の製品が求める量や質とあっているでしょうか？ また、出荷後にバグや脆弱性が見つかった時にそれを修正したバージョンを提供するソフトの保守は、何年程度継続できるのでしょうか？
購入ソフトやフリーソフトを導入する時には、導入した時点でのそのソフトのプロダクト品質とともに、出荷後にソフトの保守が提供できるかどうかも、よく確認しておく必要があります。自社開発のソフトについてはわりとしっかりとテストしていても、購入ソフトやフリーソフトについては、案外テストされていない事もあります。
購入ソフトはフリーソフトの品質を誰がどんな方法で確認しているのか、そもそも購入ソフトやフリーソフトを自社製品に搭載しても良いかどうかを判断する仕組みがあるのかどうか、等が購入ソフトやフリーソフトについての大切な確認点になります。
（５）開発計画や開発プロジェクトの管理の機能
ソフトの開発プロジェクトは結構な頻度で工程が遅れます。工程が遅れる原因はプロジェクトの中にあったりプロジェクトの外にあったりと様々ですが、原因がどうであれ、工程遅れが良く起きるという現実には変わりはありません。
なので、ソフト開発プロジェクトでは開発進捗の管理がとても大切です。でも、開発進捗だけを重視していると別の点で失敗します。ソフト開発プロジェクトでは、大きく遅れていた工程を奇跡的に挽回する悪魔の一手があります。それはテストが終わっていないけどリリースしてしまう、という手です。 まあ要するにまだまだ潜在バグは残ってはいるけれど、基本的な機能はちゃんと動いてるのだから、納期が来たのでリリースしてしまいましょう！ という方法です。
という訳なので、ソフト開発プロジェクトでは当初に計画した開発日程と品質を守るために、開発管理がとても重要です。そして管理をするときの大前提が計画がある事です。管理とは、物事が計画どおりに進んでいるかどうかを監視して、計画からズレていたら計画に合わせるように対策をする事です。なので、元々の計画が無いと管理のしようがありません。
具体的には、ソフト開発の計画書に必要な事が書いてあるのかという確認と、開発プロジェクトが計画どおりに進んでいるのかを確認する仕組みと、もし品質や日程が計画からズレてきていたらそれを計画どおりに修正する仕組みがあるかどうか、が大切な確認のポイントになります。
（６）不具合事例の横展開や技術者教育の機能
不具合事例の横展開や技術教育とう点は、海外のソフト開発委託先に対してソフト開発監査を行う時には、ちょっと注意が必要です。何に注意が必要かというと、そのような活動の必要性についての考え方が日本とは違う場合が多いという点です。
日本だと、Aという製品で経験した不具合（例えばメモリーのリークで出荷後49日でシステムがハングしたというようなバグ）は、BやCという他の製品の開発チームにも伝えて、同じようなバグが潜んでいないか確認しましょう、という活動を普通の事だと考えます。もちろん、考えてもそれを実施する時間がなかったりして、実際には行われない事もよくあります。でも、そのような不具合事例の横展開は普通の事だという考えは持っています。
日本の場合、ソフトエンジニアも会社の社員であり、会社の中で昇進していく事で収入を増やすのが一般的ですので、この様な考えが一般的です。しかし、海外のソフトエンジニアは、会社と契約して自分の能力を会社に提供しその対価として給与を得ているといいう意識が高いです。極端な場合、１つの開発プロジェクトが終わると自分の能力値が上がるので、より良い条件の会社を探して転職していく事も普通にあります。
このようにして、自分の能力を元に会社と契約する事を前提としている彼らにとって、自分が経験した不具合事例は、大切な自分の技術ノウハウであり自分の価値を高めるための自分の能力の一部です。その大切な技術ノウハウを無料で他人に伝授する必要性は、余り感じません。会社としても、製品の開発にあたって必要な能力を持ったエンジニアが足りなければ募集し、多ければ今いるエンジニアを解雇します。
こんな環境で仕事をしているので、不具合事例の横展開や教育という概念自体が日本とは根本的に異なっている事を前提にする必要があります。それでも、不具合事例の横展開や教育はソフトのプロダクト品質を改善するために有効な手段なので、それを開発組織の中にどうやって取り入れているか、という点に注意して相手先の説明を聞くのた良いです。
組織の構成と場所
最後になりましたが、ソフト開発組織の存在する場所も注意して確認するのが良いです。ネット環境が充実してきてオンライン会議が普通に使えるようになってきたので、以前に比べて場所による影響は少なくなってはきています。しかし、会社の業務全般に言えるのですが、インフォーマルコミュニケーションで交換される非公式の情報には実はとっても役に立っている、という事は今もやっぱり生きています。
例えば、コーヒーの自動販売機の前での5分-10分の立ち話であったり、昼食を食べている時の意見交換だったりが、ソフト開発プロジェクトに結構役に立つ事があります。そんな事ができるには、同じビルや同じフロアにエンジニアが集まっている必要があります。
ソフトの開発に関係する部署が、一か所に集まっているのか複数のビルに分散しているのか、あるいは全世界に分散しているのか、実際のエンジニアがどこで仕事をしているのか、相手先の会社の説明を聞く時には心に掛けていました。
次からはチェックリストを使う時の注意点の紹介です
チェックリストの紹介の前に相手先からの説明を聞く時の注意点を軽く紹介しておこうと思ったのですが、思いのほか長い記事になってしまいました。次の記事からはいよいよソフト開発監査チェックリストの内容に沿って監査を進める時の注意点を紹介していきます。
なお、実際のチェックリストの各々の項目は、ソフト監査実務・チェックリスト詳細：開発プロセス（前編）の記事から順番に紹介していますので、チェックリストの詳しい項目の内容に興味のある方は、先にそちらの記事を見られるのが良いと思います。