「派生開発」を成功させるプロセス改善の技術と極意

いつまで「派生開発」で疲労し続けますか? 派生開発にはそれに適したプロセスがある! 合理的なプロセスと成果物で構成された「XDDP」でデスマーチから脱却を! 確実に派生開発プロジェクトを成功させる実践的方法論の登場。

既存のソフトウェアに変更や機能追加を加える「派生開発」は、ゼロから作る新規開発とは別の難しさを持ちながら、長く新規開発向けの技法で扱われてきました。『「派生開発」を成功させるプロセス改善の技術と極意』 (清水吉男 著、技術評論社、2007 年 10 月刊、A5 判) は、著者が現場で培ってきた方法論を派生開発専用のプロセス XDDP としてまとめた本で、版元は「トラブルが頻発する「派生開発」を改善するにはどうしたらよいか」という問いから本書を紹介しています。対象として版元が挙げるのは「派生開発をスムーズに進めたいプロジェクトマネージャやエンジニアに」「派生開発でデスマーチに陥った経験のあるエンジニアに」「システムの変更を発注する側の人にも」の 3 者で、開発者だけでなく発注側も読者に含めている点が特徴です。

全 5 章の構成、派生開発の失敗分析から XDDP の効果まで

構成は全 5 章です。第 1 章「派生開発の現状」は、動いていたシステムが止まる、わずかな変更でも納期をはずす、変更モレが頻繁に発生している、といったトラブルの列挙から入り、「変更要求をつかんでいない」「全体を理解しようとして失敗している」「既存の分析・設計技法はすべて新規開発向け」など失敗を繰り返す理由を掘り下げます。第 2 章「派生開発プロセス「XDDP」の提案」で XDDP の誕生とライフサイクルモデルとしての位置づけ、変更要求仕様書の導入、変更要求用と機能追加用という 2 つの PFD、成果物の一覧を示します。第 3 章「XDDP による変更のプロセス」が本書の中核で、変更要求をまとめる、ソースコードから変更仕様を探す、変更要求 TM を作成する、変更方法を変更設計書にまとめる、ソースコードの変更は足並みを揃える、と作業の順に節が並びます。第 4 章「追加のプロセスと XDDP を支えるものたち」は機能追加のプロセス、移植、品質要求、レビュー、要件管理、サイズ見積りを扱い、第 5 章「XDDP の効果」で納期 / 工数 / バグ / レビューの面から効果を述べ、日本版 SOX 法への対応 (刊行時点である 2007 年の文脈) やソフト以外への応用にも触れて閉じます。

変更要求仕様書 / TM / 変更設計書、3 つの成果物で変更を追跡する

XDDP の骨格をなすのは、目次の 2.5 節に並ぶ成果物です。変更要求仕様書、追加機能要求仕様書、トレーサビリティ・マトリクス (TM)、変更設計書が挙げられ、第 4 章のレビューの節では「3 つの成果物の役割とレビューポイント」として、変更要求仕様書 / TM / 変更設計書の 3 つを検査の要に置いています。変更要求を「before」「after」で表現し、変更する理由を必ず添え、ソースコードを調査して変更仕様を拾い出す「スペックアウト」を経て、どの要求がどのソースファイルに影響するかを TM に記し、変更方法を変更設計書に文章で書いてからソースコードに手を入れる、という流れです。「ぎりぎりまでソースコードを変更していないことの効果」という節題が示すとおり、コードを触る前に変更の全体像を文書で確定させる規律が、この方法論の性格をよく表しています。要件定義 の技術を新規開発ではなく「差分」に適用するという発想が、本書の独自性です。

派生開発がなぜ難しいか、2007 年刊行の本を読む技術背景

派生開発の難しさは、変更の正しさが「変更した箇所」だけでなく「変更しなかった箇所への影響」で決まる点にあります。他人が書いた、設計思想の崩れたソースコードを部分的にしか理解できない状態で変更を重ねると、変更モレやデグレードが起き、それを通常のデバッグで潰そうとして納期を失う、という第 1 章の失敗パターンは、組込みソフトウェアでも業務システムでも変わりません。バージョン管理システムや自動テストが整った 2020 年代の環境でも、どの要求がどこを変えるのかを実装前に言語化する作業は自動化されず、影響範囲の分析は人の仕事のままです。目次には「リファクタリングとのコラボレーション」という節もあり、コードの内部構造を整える リファクタリング と、要求から変更箇所を追跡する XDDP を組み合わせる視点が示されています。一方で本書は 2007 年刊行で、想定される開発環境や文書の作り方はその時点のものです。アジャイル開発やプルリクエストを前提にした軽量な変更管理とは道具立てが異なるため、手順を丸ごと採用するよりも「変更要求と変更箇所の対応を可視化する」という原理を自分の環境に翻訳して読むのが実践的です。古い本から原理を取り出す読み方については、古い本からでも学べること も参考になります。

派生開発の本を選ぶべき人と、前提知識 / 向かない人

前提知識としては、ソフトウェア開発の工程 (要求 / 設計 / 実装 / テスト) と、既存コードを変更する実務の経験があれば読み進められます。版元プロフィールによれば、著者は 1968 年からソフトウェアの世界に入り、途中から組込みシステムの世界に転じ、CMM との遭遇を機に要求の仕様化 (USDM) や派生開発に特化した XDDP などの開発方法をまとめ、95 年にプロセス改善のコンサルティングに転向しています。要求の仕様化そのものを学びたい場合は、同じ著者の『要求を仕様化する技術・表現する技術』 (技術評論社) が対になる一冊です。なお第 2 章には XDDP は 100％近い成功率を誇るとする節題 (2.8.1) がありますが、これは著者の主張として読むべきもので、効果の再現は導入する組織の運用に左右されます。新規開発が中心でレガシーコードの変更にほとんど関わらない人、軽量なアジャイルの実践手順を探している人には本書は遠回りです。逆に、保守 / 改修案件で変更モレやデグレードに繰り返し悩んでいる開発者、品質保証や発注側で「何をどう変えたのか」を追跡できる文書を求めている人、組込みソフトウェアの派生開発でプロセス改善を任された人には、変更を属人的な勘から追跡可能なプロセスへ移すための具体的な成果物の型が手に入ります。派生開発の失敗を構造から断ちたい人にとって、投じた時間が現場で回収できる一冊です。