派生開発カンファレンス2019参加レポート（２）

機能仕様書のリバース分析から、機能要求の見える化

本田技術研究所 オートモーティブセンター
小林 進一さま

 

～もくじ～

 

背景

　IVIの開発　

IVI = In Vehicle Infotainment 社にで利用できる総合情報提供
機能がここ10年で約10倍に 制御系ECUが約100倍に

 

　作業分担　

要求仕様書＝自社で作成

機能仕様書＝サプライヤが作成

 

　問題　

  • 要求仕様の章立てや記載内容が不統一
    →　横並びで機能比較を可能にする。
  • Q&Aが多発
    →　検討経緯を残す。
  • 機能仕様書に要求と設計仕様がごちゃまぜ
    →　要求を分離して明確にする。

 

役割が異なるドキュメントに異なる観点の情報が交り合っている状態。
同じ状態となっているドキュメントを目にすることが多いし、納品物の有無等に左右されて1つのドキュメントに詰め込んでしまった経験もある。
その結果として、機能の抜き出しや、要求の抜き出しなど余計な作業が増えてしまう。類似システムや前回のバージョンとの比較をとることが困難という状態にも陥る。
また、派生開発の場合、前回の開発とは無縁の人がアサインされることもあり、過去の経緯が不明ということが頻発する。その結果、処理の変更を行うことに恐怖を感じる。
すごく馴染みがある問題で、耳が痛い。

 

対策

　USDMの活用　
  • 要求仕様は、USDMで経緯とともに記載する。
  • 機能仕様は、機能構造図を利用してUSDMからアーキテクチャを導出する。
    →　手順を標準化する。

 

　リバース分析とUSDM化の方針　

  • 要求と機能仕様をExcelに列挙
  • 要求を目的でグループ化
  • 価値の抽出
  • システム要求の導出
  • USDM形式に流し込み

 

　実施手順　
  • 既存の要求仕様書と機能仕様書をExcelに書き出し
  • 要求のみを残して洗練
  • 目的別にグループ化
  • 目的ごとにゴール（価値）を抽出
    （何を可能とすることを価値として提供するか）
  • 要求仕様の詳細

 

何かを作り替える場合、怖いのは「抜けること」と「誤った変換をすること」だと思う。
今回の発表で紹介された方法は、インプットとなるドキュメントの内容を全て書き出してから分類するという方法。
この方法ならば、記載抜けするリスクを下げることができる。
特に、再構成時の過程を残せるところも大きいと感じた。
既存のドキュメントの内容を書き出す手順は、機械的に作業ができそうなので、WordやPDFの文書からExcelへ転記するツールみたいなものがあると導入の敷居をかなり下げることができると思った。

 

考察

  • システム要求をUSDMで見える化
    →　要求の共通部分が見れるようになった
  • 経緯を理由として要求単位で残すことができた
    →　理解しやすさの向上

USDM形式で表現することで、機能横断で記載内容を比較することができ、要求としての共通部分が見えるようになってきたとのこと。
この感覚を自分でも味わってみたくなった。
よくUSDMを使うと要求の不足が見えるようになると聞いたことがある。
やはり、USDMによる俯瞰視能力は貴重だなと感じた。
ただし、記載粒度には十分な注意が必要だと感じた。
すべてを詰め込んでしまうと見通しが悪くなってしまう。
この辺の感覚が慣れを要するといわれる所以なのだろう。

 

課題

V字プロセスとしては未完成
（テスト部分へのUSDMを活用はこれから）

 

一気通貫という意味では、テスト項目まで対応がとれると要求や機能仕様の検証を事前に実施できるようになると感じた。
ここまでくると、どう管理するかが次の問題になりそうだと感じた。
要求と機能仕様、テスト項目の対応を常に担保し続けることができれば、上流（サプライア側）だけで駆動し、洗練された仕様をベンダへ渡せるようになると感じた。

 

Q&A

  • Q:USDMを導入する上で周囲の抵抗はなかったか？
    A:もともと認識合わせに苦労しており、USDMを使ってみたらその点が解消した。(疎外障壁はなかった)
  • Q:他のシステムへの展開は？
    A:IVIが初の取り組みで、他のシステムはこれから
  • Q:経緯を理由欄に残すと理由欄が過多になるのでは？
    A:ユーザーのゴールに近い経緯のみを書いた。
    　他の経緯は省いた。（そのような記載粒度設定とした。）
  • Q:USDMへの記載粒度を整えるのは大変と思うが、知見はあるか？
    A:リバース分析を実施する際にIVIを外側からみて要求を分析した
    　→　外から見たときの上位要求のみを抽出した
  • Q:ユーザー視点を抽出するための知見は？
    A:もともとその機能がなぜ必要になったのか分析し、
    　経緯を担当者にヒアリングして分析した
    　抽象化とともに個別化も行う
    　（音声認識をする際、ドライバのみの音声を拾う方が良いとか。。。）
  • Q:USDMを導入したことによってどれくらい効率化できたのか
    A:開発中のため、効果の計測はこれから
  • Q:USDM化することで作業量の増加があるのでは？
    A:増加すると思うが、フロントローディングととらえている。
  • Q:過去システムをUSDM化する進め方は、全体を一括で進めたのか？
    A:部分部分を徐々に進めている状態