ソフト開発監査の監査当日（３）組織の概要と規模の把握（前半）
ソフトウエア開発監査の４つの領域に分けて進めます
ここまでの記事で、監査当日までの準備や監査当日の進め方などについて紹介してきましたので、この記事からはソフトウエア監査のチェックリストも見ながら、もう少し具体的に監査の確認ポイントなどを紹介していきます。
ソフトウエア開発監査は、ソフト監査概要・方法その１：ソフト監査はプロセスかんさ＋技術力監査 の記事でも紹介したように、以下の４つに分けたソフトウエア監査のチェックリストを使って、相手先組織のソフトウエア開発力を確認します。この記事とその後に続く記事でもこの順番に沿って紹介を進めます。
- 開発プロセスの監査
- 開発技術の監査（要求仕様）
- 開発技術の監査（テスト）
- 開発技術の監査（設計・実装）
しかしその前に相手先から組織の概要について紹介を受けます
なので、４つのチェックリストの紹介に入る前にもう１つ別のお話をしておきましょう。ソフト開発監査概要・事前陣日その１：監査計画の説明 の記事で紹介した監査計画書をみてもらうと、オープニング会議に続いて相手先組織から開発体制/品質保証体制/開発フローの説明を受ける時間があります。
実はこの相手先組織による説明も、いくつかの点に注意して話を聞くと相手先のソフト開発能力を判断する上でいろいろな事が判ります。そこでこの記事では、グータラ親父がどんな点に注意して相手先の説明を聞いていたのかを紹介しようと思います。
開発組織の概要と規模
相手先による説明では、まずはソフト開発に関連する組織とその規模を把握します。具体的に言えば、どんな名称と役割の部署があってそれぞれ何人の人が居るかリーダの人は誰か、という事の確認です。
ソフト開発にどんな組織が必要なのかはこれが正解といのはありません。ソフトと一言で言っても目的や規模は千差万別なので必要な組織なんて決められないとう面もありますでも、殆ど全ての活動が人間の頭の中で行われるのでどのような組織が適切なのかよく判らないといのがが本当のところだと思います。
とは言え、組み込み系のソフト開発の現場で長年暮らしてきたグータラ親父としては、以下に紹介するよう組織があるかどうかを確認して、相手先組織のソフト開発力を判断の助けにしていました。それでは順番にこれらの組織に想定している機能や相手先組織からの説明を聞く時の注意点について紹介していきましょう。
（１）開発チームの状況
これは機能の説明の必要はありませんね。製品に搭載するソフトを開発するための、設計者/実装者/設計テスト者を集めたソフトを開発するためのチームです。通常は数名から多くても十名程度で１チームを構成していて、チームリーダがチーム全体を取りまとめています。ソフトの開発規模が大きい場合には、複数のチームが分担して開発を進めていると思います。
開発チームを確認する時の注意点はチームの規模です。ソフトの開発チームの規模は１人のリーダが面倒をみきれる人数からおおよそ決まってきます。グータラ親父の経験では、5名程度が最適で10名はちょっと人数が多すぎてチームメンバの全員に目が届かなくなります。この人数は、リーダが全メンバの設計や実装のレビューにすべて参加するという前提での判断基準なので、サブリーダをつけてレビューを分担するなどの対策をしていれば、まあ10名を少し超えていてもなんとかなる規模だと思います。
（２）テストチームの状況
テストチームは、開発チームが作ったソフトのテスト作業を受け持つチームで、開発チームとは別のチームとして活動しているチームを指します。設計部門の中で開発チームとは別にテストチームが存在する場合もあれば、設計部門とは独立した例えば品質保証部門などにテストチームが存在する場合もあります。もちろん、ソフトの開発組織が小さい場合には、開発チームと独立したテストチームが無い場合もあります。
テストチームについて確認する時の注意点は、まず開発チームとして独立してテストチームが存在しているかどうかです。またテストチームの行うテストが何を目的にしているのかも大切な確認ポイントです。
テストの目的の分け方にも色々あるのですが、大きくは①バグを発見する事と ②バグが無い事を確認する事 の２つに分ける事ができます。①のバグを発見する事を目的としたテストとは、単体テストや結合テストなどのように、ソフトの設計者や実装者がバグを見つけ出してこれを修正するためのデバッグ作業の一部として行うテストです。一方で②のバグが無い事を確認する事を目的としたテストとは、品質保証部門などがソフトにもうバグが残っていない事を確認して、リリースして良い品質に達しているかどうかを判定するためのに行うテストです。
どちらの目的のテストも、テストの設計方法や実施方法は同じなのですが、その目的が違います。しかし、開発チームではバグを発見するテストを実施して、開発チームとは独立したテストチームがバグが無い事を確認するテストを実施する、というように目的に合わせて別々のチームになっているほうが、ソフト開発組織としてはより安心です。
（３）アーキテクトチームは在るか、どんな役目を持っているか
アーキテクトチームといのは、聞きなれない人も多いかもしれませんが、ソフトの技術力の高いエンジニアで構成されたチームです。チームの呼び名はアーキテクトチームだったりシニアエンジニアチームだったりレビューチームだったりといろいろです。
呼び名はいろいろなのですが、このチームのエンジニアは高いソフト技術力や経験を持っているのですが個々の製品の開発チームには所属しません。その代わりに、製品の開発チームからの要請に従ってレビューに参加したり、技術的なコンサルティングを提供したりすることがこのチームの目的です。
技術的に優れたエンジニアというはどの会社でも人数が限られてます。それらの優れたエンジニアを特定の製品の開発チームには所属させずに、いろいろな製品の開発を幅広く支援するチームとしにして活躍させる、という組織の作り方をしている会社は、優れたエンジニアの能力を効率的に使いこなしていると見る事ができます。ですので、このような目的を持ったチームが組織に在るかどうか、在るならどんな活動をしているのかという事を注意して確認します。
後半のページに続きます
ちょっと説明がながくなってきたので、この記事はここで一旦終わって続きは次のページで紹介します。