ソフト開発監査ではソフトの設計・実装力の良否を４番目に判定する（前半）
ソフト開発監査ではソフトの設計と実装の能力の良否についても判定します
ソフト開発監査では開発プロセスの品質とソフト開発技術力の良し悪しを評価します。ソフト開発技術はさらにテスト技術と要件把握と設計・実装３つの分野に分けて評価するので、全体では以下の４つの項目に分かれます。ソフト開発技術にはこれ以外にも様々な観点があるのですが、限られた時間で開発委託先の技術力を評価するために、ソフト開発監査ではこの３点に絞ってソフト開発技術の良し悪しを判断していました。この記事ではソフト開発監査で４番目に確認する開発技術のうちの設計・実装の能力の良し悪しを評価する方法を紹介します。
- 開発プロセス （ソフト開発に使っている開発プロセスは良好か？）
- 開発技術：テスト技術 （リリースまでに実施しているテストの技術力は十分か？）
- 開発技術：要件把握 （開発要件を具体化し委託元と共有する技術力は十分か？）
- 開発技術：設計・実装 （ソフトの設計と実装の組織としての能力は十分か？）
設計・実装能力はソフト技術者の個人の技術力に依存する面も大きいのですが、ソフト開発監査では組織としての技術力に焦点を当てて良し悪しを判断します。それでは、実際にどんな観点で何を確認しているのか順に紹介していきましょう。
４．開発技術・設計と実装の能力は技術チームとプロセスチームと情報共有をまず確認する
ここまででの記事ではソフト開発監査の監査対象について、開発委託先への入り口である要件の把握と、開発委託先からの出口であるテストを紹介してきました。次は実際のソフト開この入口と出口を繋ぐ、ソフト設計・実装に関する技術力という監査対象についての紹介です。
設計と実装の技術力については、グータラ親父は以下の２つの領域に分けて確認をしていました。
- ソフト開発リーダの能力
- ソフト開発組織の持つ組織としての技術力
一つ目のソフト開発リーダの能力については、概要・監査の目的の記事でも紹介していますので、そちらをご覧下さい。ここでは２つ目の組織としての技術力について、少し詳しく紹介します。
組織としての技術力と言うと何の事か判らないですよね、これは、ソフト開発をどんな組織体系の中で行っているのか？ 開発の作業を支援するどんな仕組みがあるのか？ とう事です。ソフト開発の主役であるチームリーダやエソフトンジニアの開発作業を支援するための仕組みがどれだけ充実しているか？と言い換える事もできます。具体的には、ソフト開発監査では以下のような項目について、開発委託先の組織の状況を確認していました。
- 技術エスパートチームの有無
- ソフト開発プロセス改善チームの有無
- 社内の技術情報・バグ情報の共有システムの有無
- 設計レビューやコードレビューのチェックリスト
- ソースコードの静的/動的解析ツールの状況
- 自動テストの仕組みと利用方法
では、これらについて順番に紹介していきましょう。
技術エキスパートチームの有無
ソフトの開発には様々な技術が必要になります。採用するハードウエアに関する技術、使用するソフトライブラリに関する技術、開発対象のアプリケーションに関する技術、アプリケーションが使われる現場に関する技術。開発チームの中に、必要な技術を持ったソフトエンジニアが全て揃っていれば良いのですが、そんな理想的な開発案件は滅多にありません。
開発チームのメンバだけでは、ある技術を知っているソフトエンジニアが不足する時に、その技術を良く知るソフトエンジニアに、チームの外から支援して貰えると助かりますね。 しかし、そのソフトエンジニアも他の開発チームに所属していて自分の開発チームの業務が忙しいと、なかなか思うようには支援してもらえません。
そこで、技術に詳しいエキスパートエンジニアを集めて特別なチームを作り、そのチームは特定のソフトの開発チームとして作業するのではなく、他の開発チームからの要請を受けて、設計や実装のレビューを支援するような技術支援だけを行う、というような特別チームを持っている会社が良くあります。
特別チームの呼び名はエキスパートチームだったり、アーキテクトチームだったりと色々ですが、要するに技術に詳しいエンジニアの集まりで、必要に応じてレビューという形で技術支援をしてくれるチームです。このようなチームを持っていると、それは組織的な技術力が高いと考えて良いでしょう。
ソフト開発プロセス改善チームの有無
ソフト開発プロセス改善チームとは、一般には SEPG (Software Engineering Process Group と呼ばれる事が多いですが、ソフト開発プロセスの構築や改善を推進する責任をもったチームの事です。 この記事を読んでおられる皆さんの会社には SEPG の組織やチームは存在していますか？
良いソフトを開発するには、ソフトに関する高い技術力とソフト開発プロセスに関する高い能力の２つが必要になります。簡単に言えば、技術力があって開発手順も良ければ良いソフトができるね、という事なので実はとても単純な話です。そして、前の章で紹介した技術エキスパートチームが高い技術力のためのチームであるのに対して、ソフト開発プロセス改善チームは良い開発プロセスのためのチームです。
このソフト開発プロセス改善チーム（SEPG) が、通常のソフト開発チームとは独立したチームとして開発組織に存在するかどうかで、ソフトの設計・実装に関する能力も大きく変わってきます。自社の製品に適した全社標準のソフト開発プロセスを構築する作業や、個別の開発プロジェクトで全社標準の開発プロセスから必要な箇所を選択して開発チーム専用のソフト開発プロセスに仕立て上げるなどが、ソフト開発プロセス改善チームの活動です。
これらの活動の成果は、最終的なソフトとして実現される機能や性能とは直積関係しないので、ソフトプロセス改善チームの活動成果は目には見えない部分が多いのですが、組織としてのソフト開発能力に大きく貢献します。
ソフト開発プロセス改善チームの責任者は明確になっているか
そしてもうひとつ、ソフト開発改善チーム（SEPG) に関連して確認する必要があるのが、SEPG の責任者としてトップエンジニアが選定されているか？ という事です。CMMの生みの親と言われているハンフリー博士は SEPG の責任者に必要な資質として以下の４つを上げておられました。
- 責任者は変更プロセスの指導に熱意がなければならない。
- 責任者は技術的にも政治的にも問題を理解し解決する能力がなければならない。
- 責任者は関係者から尊敬を得なければならない。
- 責任者は管理者の支持を得なければならない
この全てを満たせるなら、その日人はまさにトップエンジニアとして、実際のソフトウエア開発チームの運営をバリバリこなせると思います。会社にとっては、そのような人は実際のソフト開発の現場で力を発揮して貰いたいと事だと思います。でもその様な優秀な人材を直接ソフト開発をする事のない SEPG の責任者に据える事で、経営トップがソフト開発プロセスの改善に掛ける意気込みが全社に伝わり会社全体として良い方向に進むでしょう、というのが何フリー博士の教えなのだと思います。
社内の時術情報・バグ情報の共有システムはあるか
社内の技術情報・バグ情報の共有システムというのも色々とありますが、例えば以下のような情報を集めたデータベースです。
- ある技術に関する仕様書や参考資料やサンプルコード等の技術データベース
- 自社製品のシステムテストの内容を機能毎に分類したテストデータベース
- 自社製品の開発で発見されたバグと修正方法を機能毎に分類したバグデータベース
要するに、技術情報やテストケースや、これまでに経験したバグに関する情報を、自社の過去の開発例から簡単に取り出せるようなデータベースです。ソフトの開発でゼロから設計を始めるのではなく過去の参考になる情報から始めたいという、過去の開発資産を再利用するためのデータベースと言っても良いですね。
ソフトの開発組織の規模が小さくて、ソフトエンジニアが全部で３人しかいないという様な状況なら、わざわざデータベースを作る必要などありません。ちょっと隣の人に聞けばそれで済みます。 しかしソフトエンジニアが 30人を超えてきて、それらの人が10年以上に渡って色々なソフトを開発していると、蓄積された技術情報も大量になるので、データベースに入っていないとなかなか取り出せません。
データベースを作ってそのコンテンツを維持するには、それなりの工数が掛かるのですが、その費用を上回る効果が期待できるので、このようなデータベースを作っている会社も時々見かけます。ただし、海外の場合は技術は個人に属していて、一人一人のエンジニアは自分の技術を武器により収入の高い会社に転職していくので、各自の持っている技術を無償で開示するという考えの無い国も多いですので、注意が必要です。
いずれにしても、このようなデータベースを整備している組織は、組織的な技術力が高いと考えて良いでしょう。
設計・実装力の良否を４番目に判定する（後半）に続きます
少し記事が長くなってきたので、残りの部分は後半の記事で紹介します。