このエントリーをはてなブックマークに追加LINEで送る

12.7. 品質は作り込まれる

ハッピィ・エンジニアリング表紙


品質とは、計画・設計・作り込みによって達成されるものであり、検査によってではない。
A Guide To The Project Management Body Of Knowledge: Official Japanese Translation, Project Management Institute著, Project Management Institute, ISBN:1930699751

 

 品質とは「作り込まれる」ものである。さらに、ソフトウェアの品質には、技術的な、あるいは専門的な要素が非常に多く、プロジェクトマネージャや品質管理担当者が的確な管理を行うことは非常に難しい。

 

 例えば、「レビューとテスト」は品質を低下させないために重要な活動のひとつである。しかし、それ自体が品質を高めるものではない。レビューとテストの限界は、レビュー担当やテスト担当よりも、設計・製造担当者のほうが明らかに内容を熟知している点にある。

 

 結果として、レビュー担当は枝葉末節のどうでもいい重箱の隅をつつく行為に終始しがちである。レビューでチェックできるのは、形式的なミス、明らかな誤り、(皮肉な話だが)レビューを行う側の知識の整理、(設計者よりレビューをする側がミドルウェアに熟達している場合に起こる)ミドルの使い方の誤り、といった本質的でない問題点の摘出などにとどまってしまう。

 

 システム開発における組織論の大きなテーマとして、「協力型組織論」と「敵対的組織論」の問題がある。システム開発の歴史の黎明期は敵対モデルが優位にあった。要するに、開発者を信頼せずレビューとテストで「あら探し」をすることで要求仕様への適合性と高品質の保証を行おうとした。

 

 ところが、現在ではシステム開発の分業化による影響で、発注側よりも開発側のほうが知識・スキルともに勝っている。そのため、レビュー自体が枝葉末節のチェックになり、本質的部分については開発側の設計に異を唱えることが技術的に困難になってきている。
 一方で、プロトタイピングに始まりスパイラルを経てXP(eXtreme Programming)やアジャイルに至る発注側のユーザを巻き込んだ協力モデルは、うまく適用できた場合には好結果がもたらされることから、種々の欠点を持ちながらも、影響力を強めている段階である。*1

 

 このような一連の流れの中で、協力モデル・敵対モデル、どちらにも欠点があることが明らかになり、正解はその間のどこかにあるのだろうと漠然と考えられている。

 

 しかし現場では敵対モデルの無力さが明らかになるにつれて、チェック機能が極端に失われてきている点が、大きな問題として認識されている。古典的な敵対モデルの中では、各プロセスについて関係者一同の合意があって初めて次のプロセスに進むことができた。お互いの利害が相反すると考えている以上、性悪説に立っているため、あいまいさを残すことは許されなかったのである。

 

 こうした敵対モデルに基づく組織論とウォーターフォールモデルは、本来まったく別物である。*1 しかし、ともに「仕様凍結」という儀式を行うことから妙に混同され、ウォーターモデルの否定とともに敵対モデルが力を失ってしまった。

 

 敵対モデルにあったチェック機能が弱体化している現状での解決策としては、次の3つが考えられる。

 

  • チームリーダによる強烈なリーダシップに基づく意思決定
  • 外部からのレビュー強化によるチェックの復活
  • 開発規範の徹底による作業標準化

 

 結論をいえば、現状の解決策は、「チームリーダによる強烈なリーダシップに基づく意思決定」をおいてほかにはない。

 

 「外部からのレビューによるチェック」は、敵対モデルの復活と位置づけることができる。しかし、システムの細部を知っている設計者やプログラマに対して外部のレビュー担当が太刀打ちできるものではないことは、経験的に明らかである。よほど力の差があるレビュー担当を置かない限り、実質的な効果を出すことは非常に難しい。

 

 「作業標準化」はこれから先々の課題である。本来であれば、品質をプロジェクトメンバ個人の意識やスキルに頼るばかりでよいはずがない。組織としての向上を望むべきである。しかし、品質面を考慮した作業の標準化を行うには、全社レベルでの品質基準やガイドラインを設ける必要がある。さらに、それを徹底していくには、品質に対する教育や訓練を行うことが条件となる。しかし、全社レベルの明確な基準やガイドライン、教育・訓練のプログラムを持っていない上に、システム屋への教育が不足している現状では、すぐに適用できる解決策とはなり得ない。

 

 「チームリーダによる強烈なリーダシップに基づく意思決定」というのは、それほど新しい考え方ではない。おおまかな基準を定め、各プロセスの成果物のチェックを早い段階から、かつ短いサイクルで、その都度チェックしていくことが活動の基本である。

 

 チームリーダが、1日1回、あるいは数日に1回のタイミングで、非公式なレビューや成果物検査を行い、作業の方向性やプロセス、成果物品質をチェックしていく。短いサイクルでのチェックは、見るべき成果物のボリュームが少ないため、大きな作業負担とはならない。さらに、短いサイクルでチェックすることにより、担当者とのコミュニケーションが密になる上、作業を詳細まで理解することができる。このようにすることで、作業の手戻りを大幅に減らせるのである。

 

 このような短いサイクルによりチェックをするうえでの判断材料となるものは、プロジェクト計画書をはじめとする上位プロセスのドキュメント、適切なワークパッケージを網羅したWBS、作業のインプット・アウトプット・プロセスを明示したWBS辞書やSOWなどである。これらをよりどころとした合理的判断により、品質の向上と作業効率化の両者を同時に成立させることが可能になる。

 

 このような短いサイクルによるチェックを行わずに、公式なレビューに期待したとしても、実際には、

 

  • レビューのチェック機能が失われている
  • 成果物の完成時点で間違いを指摘しても、修正する時間が不足する

 

という状況になる。

 

 チームリーダは、成果物を細かくチェックし、ボタンを掛け違えたままの状態で成果物を作り込むことがないように、プロジェクトメンバの進捗状況に合わせて成果物の状況も把握しながら進めていかざるを得ない。

 

 システム開発のプロジェクトリーダやチームリーダは、このような技術的要素が多く、専門性の高い分野に介入せざるを得ない。現時点では、似たようなシステム開発の経験を持つチームリーダがアサインできれば、成果物品質を高めた開発を行えると思われるが、今後ますますシステムが多様化していくことを考えると、リーダに必要とされるスキルも今まで以上に高まっていくだろう。プロジェクトマネジメントの基礎になるものは、「ソフトウェアエンジニアリングの知識」である。ソフトウェアエンジニアリングの知識を前提とし、さらにプロジェクトマネジメントの知識を重ね合わせて初めてプロジェクトリーダの実務がこなせると言っても過言ではない。さらには、ネットワーク、データベース、プログラミング言語などの個々の技術要素に対する基礎知識までもが求められる。

 


*1 これらのモデルの最大の欠点は、「ユーザは、自分の作りたいシステムを自分でわかっている」という無意識の大前提に対する否定が出てきたにも関わらず、それに対するなんらの反論もできていない点あろう。

*1 敵対モデルは手戻りを禁じているわけではなく、単純に合意や承認を必要としているだけのことである。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

12.7. 品質は作り込まれる ハッピィ・エンジニアリング関連ページ

12.1. 品質とは何か?
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.2. テストのプロセス区分
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.3. 現状のシステム品質
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.4. 品質低下の根本要因
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.5. 欠陥とは何か?
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.6. 品質向上の手法
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング