人間を支援するツールとしてプロセスを導入する ―― ソフトウェア品質シンポジウム 2012（SQiP 2012）（2）

●レビューで若手を育てるためにレビューする側も教育

　デンソークリエイトの竹下 千晶氏は，「技術者のスキル向上につながるピア・レビューに進化させる仕組み」について発表した．同社では，組み込みソフトウェアの品質を確保するためにレビューの強化や定量的管理に取り組んできたが，若手技術者が育っていないように感じているという．そこで竹下氏は，人材を育てるためのプロセス改善に取り組んだ．

　現場のプロジェクト・マネージャからのヒアリングや教育のアンケート結果によると，次のような若手技術者が多いのだという．同じ分野の業務を担当し続けているのに，本人が実際に開発した範囲のことしか理解していない，実際の運用場面を想定して考えることができない，何度も同じ指摘をしているのにできるようにならない，などである．

　これらは従来，「業務・開発経験を積めば身に付く」と思われてきた事柄である．業務のどのような部分で身に付けていたのかを考えてみると，上司や識者とのチーム作業，具体的には方針検討やピア・レビュー（査読）が，スキル向上に役立っていたと思われる．もちろん，現在でもピア・レビューなどは実施している．そこで，どのような内容のレビューであれば若手技術者のスキルを向上させることができるのかを考えて，ピア・レビューの内容を見直すことにした．

　現場で行われているレビューには，参加者が満足や充実感を感じる「いい感じ」のレビューと，そうでない「いまいち」なレビューがある．体裁や誤記の指摘ばかりだったり，観点・論点が発散する，指摘を受ける側（レビューイ）の考えが分からない，指摘する側（レビューア）もしくは指摘を受ける側が一方的に話して終わるようなレビューだと，満足度は上がらない．逆に，運用や再利用などの具体的な想定を基にした指摘が挙がったり，指摘する側が指摘の背景や根拠を説明したり，指摘を受ける側が簡潔に考え方や根拠を説明できているレビューだと，満足度が高いことが分かった．つまり，満足度の高い指摘とは，知識や経験に基づいたシミュレーションによって抽出されたものだと言える（写真7）．このように，指摘する側が知識や経験に基づいたレベルの高い指摘を行うことにより，指摘を受ける若手技術者もスキルを向上できるのではないかと考えた．

写真7　レビューで欠陥を抽出するときの観点とレビューに対する満足度

　レビューでシミュレーションを行えるためには，指摘を受ける側と指摘する側の双方に準備や説明力が必要である．そこで，指摘を受ける側や指摘する側，プロジェクト・マネージャ向けにそれぞれトレーニングを行った．また，若手技術者を1対1で支援する「フィールド・サポータ」役を配して，レビューの記録や結果を振り返り，一緒に対策を考える体制を整えた．これにより，レビューの内容が向上し，若手技術者の取り組む姿勢やレビューに持ち込む成果物の品質も向上したという（写真8）．

写真8　実践支援対象者（若手技術者）5名の測定値の変化
取り組みの姿勢を評価した値と，自己検出可能な不具合の割合の変化を調べた．活動開始から3カ月後，6カ月後と，成長が見られる．

●アジャイル手法で人材を育成，生産性も向上

　三菱電機の細谷 泰夫氏は，「アジャイルプラクティスを活用したチームとしての品質確保の取り組み」について発表した．同氏は，入社1年目の若手技術者2名とベテラン技術者2名の開発チームにおいて，若手技術者を育成しつつ製品の品質を確保するために，アジャイル開発の手法を導入した．意識したのは次の3点である（写真9）．

• 経験を積ませるために反復的な開発を実施．フィードバックを頻繁に与える
• 経験者が伝える（チーム設計）
• レビューやチェックなどのプロセスで支援する

写真9　課題へのアプローチ

　具体的には，要求を数日で開発できる単位に分解し，要求分析～設計～実装～テスト～レビューというプロセスを反復的に実施した．また，要求分析や方式設計はチーム作業で行い，ベテランの知見を共有できるようにした．詳細設計と実装，単体テスト設計，単体テスト実施は若手同士のペア・プログラミングで行った．詳細設計は，「原因結果グラフ」という組み合わせテスト設計技法を用いて行った．原因結果グラフは複雑な論理を表現するのが難しいため，簡単な設計になるように矯正する効果がある．無償ツール「CEGTest」を使って原因結果グラフからデシジョン・テーブルを自動生成し，実装のガイドとして利用した（写真10）．実装はテスト駆動開発で行った．

写真10　若手同士のペアで実施した内容
原因結果グラフを作成し，ツールを使ってデシジョン・テーブルに変換したものをプログラミングのガイドとして利用した．

　このような体制で開発を進めた結果，8カ月で若手技術者がベテラン技術者と対等に話ができるようになったという．また，開発したソース・コードやシステム・テストの結果などを社内の他のプロジェクトと比較したところ，メソッドごとの行数や複雑度，欠陥検出密度は低く，生産性は高いという結果が出た（写真11）．

写真11　メソッドごとの行数も複雑度も抑えられた
左が本事例の開発，右が経験者による類似の開発のデータである．

　細谷氏は，プロセスはルール（制約）ではなく，人を支援してくれるものであり，どういうプロセスだと支援になるのかを考えることが重要であると述べた．