「炎上プロジェクト頻発」という黒歴史をいかに乗り越えてきたか
ハートランド・データは、栃木県足利市に本社を置く従業員数約70名のソフトウェア／ハードウェア開発企業で、設立から44年の歴史を持つ。同社は組込み系を中心としたソフトウェア／ハードウェアの受託開発に加え、自社独自に開発したテストツールの外販も手がけている。
同社 セールス＆カスタマーサクセス部 部長 新井雅嗣氏によれば、同社では特に2010年頃から自社製品の開発プロジェクトにおいて不具合が多発し、その結果としてプロジェクトの炎上が頻発していた。ここで言う「炎上プロジェクト」とは、「問題が積み重なってスケジュールがどんどん遅延し、想定通りに開発を終えることが困難になったプロジェクト」のことを指す。
本来、プロジェクト管理においては「出荷日程から工程を逆算する」「開発リスクを織り込む」「スケジュールに余裕を持たせるためのバッファを設ける」といった原則を守ることで炎上を防ぐことができる。だが、同社の開発プロジェクトではこれに反して、前工程で生じた作業遅延を後工程で挽回しようとするも追い付かず、結果として無理な負荷がかかり、プロジェクト全体が炎上するというパターンが繰り返されていた。
こうした状況の改善を目指し、開発途中で見つかる大量の不具合とプロジェクト炎上の間の相関関係をあらためて整理した結果、以下の仮説に辿り着いた。
「開発プロセスの各段階でテストというフィルターを掛けるものの、プロジェクトが炎上している状態ではそのフィルターの目が粗くなり、結果的に多くの不具合が検出されないまま次の工程へと流れていきます。こうして徐々に蓄積されていった不具合は、最終的にリリース後に発見され、ユーザーからの厳しい反応を招くことになります」（新井氏）
さらに同社ではこうした状況を理論的に分析するために、「レイリーモデル」を用いてプロジェクトのどのフェーズでどの程度の不具合が発生するかを分析してみた。その結果、不具合発生のピークが単体テストフェーズまでに訪れた場合は、その後のフェーズを通じて不具合を無事収束できることが分かった。
しかし、統合テストフェーズの段階まで不具合発生のピークが遅れると、リリース直前まで不具合が収束せず、結果として製品リリースの延期を余儀なくされるケースも発生していた。新井氏はまた、炎上プロジェクトにおいてエンジニアが陥りがちな「認知バイアスの罠」についても言及した。
「『自分ならできるはず』という過度な自信や、『あの時できたのだから、今回もできる』という過去の成功体験に基づく思い込み、『自分が採用した手段を否定されたくない』といった心理が、適切な判断を妨げる要因になります。従ってプロジェクト炎上を避けるためには、こうした認知バイアスから脱却し、物事や人、自分自身としっかり向き合った上で最善の判断をすることが重要です」（新井氏）
デバッガやprint文では解決できない動作検証や不具合解析に
【動的テストツール DT+（ディーティープラス）】は、プログラムのトレース情報と時間情報を組み合わせたログ収集が可能。実行経路・変数値・実行時間・波形・通信・映像など、多角的なデータ解析ができるから、複雑な不具合の原因特定もスピーディー。
▶ 詳しくはこちら
ISO 26262準拠の開発プロセスの構築が状況好転の契機に
こうした窮状から同社が脱する転機となったのが、自動車の組込みソフトウェア開発で利用される同社のテストツール製品を、新たに機能安全規格「ISO 26262」に準拠させる必要性に迫られたことだった。ISO 26262は、主に自動車に搭載するシステムに関する機能安全規格であり、万が一ソフトウェアに不具合があったとしてもフェールセーフの仕組みによって安全を担保するという考え方に基づいている。
同社が開発・販売するテストツール製品を車載ソフトウェア開発プロジェクトで採用してもらうためには、この規格をクリアしなければならなかった。そのためには、まず社内の開発自体を、機能安全に即したものへと見直す必要があった。
そこで同社は、この規格に明るいコンサルタントの支援を受けながら、機能安全に準拠した開発プロセスをゼロから構築していった。さらにはこの活動で得られたノウハウを生かして、その他すべてのプロジェクトの開発プロセスを一気に改善し、長年悩まされ続けてきた「不具合の多発」「プロジェクト炎上の頻発」という課題の解決を図ることにした。
この転機において特に同社が強化したのが、自社の開発に即した開発プロセスの標準化と、生産性向上のためのツールの積極採用だった。
「開発プロセスの標準化については、それまで開発者一人ひとりの裁量に任せて開発を進めていた『個人商店的な開発スタイル』から、チーム開発を前提とした管理体制への移行を進めました。また開発のガイドラインや各種テンプレートを定義し、各工程における入出力情報や処理内容を明確化してフォーマットを統一しました。その一方で、プロジェクトごとにルールのテーラリング（カスタマイズ）を許容するとともに、開発プロセスの監査も実施するようにしました」（新井氏）
またツールの積極採用に関しては、これまで長年使い続けてきたエディター、コンパイラー、リンカーといった基本的なツールでは網羅できない機能を補うべく、用途に応じてさまざまな開発支援ツールを積極的に導入した。市販のツールを導入するだけでなく、自社の要件にマッチするツールが見付からない場合は自社で開発しつつ、情報共有ツールやデバッグツール、テストツール、影響範囲検出ツールなどの整備を進めた。
テスト自動化を短期間・低コストでスモールスタート
組込み開発向けの【テスト自動化プラットフォーム AUTOmeal】なら、「作業時間の短縮・削減」と「品質向上」を両立。実機を使うテストの自動化は難しい……という課題も、AUTOmealなら手軽にテスト自動化環境を構築できます。
▶ 詳しくはこちら
適材適所なツールの選択と「ツールチェーン」の構築
こうした方針に基づき、まず同社の動的テストツール「DTシリーズ」の開発における機能安全準拠開発プロセスの構築を行った。その結果、2016年に発売した「DT10AE」、2021年に発売した「DT+FS」ともにISO 26262のツール認証を無事取得することができた。
次にこの認証取得の活動で得られたノウハウを生かして、すべてのプロジェクトに適応する全社標準の開発プロセスを新たに構築した。全ての開発フェーズの規定を作成するとともに、ガイドラインやテンプレートの整備、要件からテストまでのトレーサビリティの確保、リリース後のカスタマー対応規定の策定などの施策を矢継ぎ早に打っていった。
またプロジェクトの適性に応じて、これらのルールを適切にカスタマイズして運用できる仕組みも整備した。さらには、「EPG（エンジニアリングプロセスグループ）」という品質保証チームも新たに設置した。同社には品質保証を担う専門部署がないため、各部署から持ち回りでEPGメンバーを選出し、メンバー間が相互監視を行うことで自然と品質が担保される仕組みを構築した。
開発支援ツールの導入については、「CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）」を参考に、「プロジェクトマネジメント」「エンジニアリング」「サポート」「プロセス管理」という4つのカテゴリーごとにツールを選定し、それらを連携させることでツールチェーンを構築した。
実際に採用されたツールは極めて多岐にわたった。一例を挙げると、情報共有ツールとして「Confluence」「Notion」、プロジェクトマネジメントツールの「Lychee Redmine」、構成管理・バージョン管理ツールの「GitLab」などを次々と導入した。さらに要求分析の用途には「XMind」、UI/UX設計には「Figma」、静的解析ツールの「Klocwork」「Axivion Suite」、CI/CDツールの「Jenkins」など、業界で広く使われているツールを積極的に採用した。
こうしたツールの選定・導入時に留意すべき点として、新井氏は「SaaSの無料ツールはどうしてもワンオフになりやすいため、有償ツールの活用をお勧めします。またツールの管理や運用促進、導入サポートなどを一元的に行う『ツール管理委員会』という組織を社内に設置することで、ツールの導入がスムーズに運びます」と述べる。
最後に本講演の締めくくりとして、新井氏は「木こりのジレンマ」について言及した。斧が切れなくなっても「時間がないから」といつまでも斧を研ごうとしない木こりのように、開発プロセスが望ましくない状況にありながら新たな施策を取り入れようとしなければ、「不具合多発」や「炎上頻発」の状況はいつまで経っても改善しない。
「このような『木こりのジレンマ』の状況に陥ってしまう背景には、認知バイアスがあります。それを打破するためには、まずは現在の悪い状態をしっかり自覚して受け入れ、いったん立ち止まって足元を見直して、さらにこれまでの動きを振り返って状況を改善するための具体的な方法を考えていくことが重要です」（新井氏）
組織内のプロセスが、現在のプロジェクトと合わない？
【Stages（ステージズ）】は、複雑化するプロセス管理をシンプルにする製品開発向けのプロセス管理ソリューション。「定義」「共有」「運用」の3つのコンセプトで、プロセスの最適化を実現します。
▶ 詳しくはこちら
※StagesはUL Solutionsの製品であり、ハートランド・データは国内の正規代理店です。
