「宇宙開発の方法論から学ぶ『要求分析』のモデリング講座」セミナーレポート(レヴィ×バルテス)

最終更新日時:2021.04.01 (公開日:2021.04.01)
「宇宙開発の方法論から学ぶ『要求分析』のモデリング講座」セミナーレポート(レヴィ×バルテス)

2021年2月25日(木)に、株式会社レヴィとバルテス株式会社によるWebセミナーが実施されました。テーマは「要求分析」。ソフトウェアテストのバルテスのセッションでは、テストの要求分析が、テスト計画にいかに重要かを解説。宇宙開発の知見を元に集結したシステム設計のプロ集団レヴィは、「モデリング」による要求分析について講演が行われました。視聴枠が満員となった同セミナー。密度の濃い内容からその一部をレポートします。

セッション1/テストの要求分析、テストアプローチ、テストマネジメント

テストプロジェクトでの「要求の分析」について、バルテス株式会社で品質コンサルタントや、ソフトウェアテスト・分析の技術開発を担当する堀明広が講演を行いました。

講師紹介

堀 明広

バルテス株式会社 クロス・ファンクショナル事業部 R&C部 部長

組込み系プログラマー、ソフトウェア品質管理を経て、現職はバルテス株式会社 R&C部 部長 兼 上席研究員。担当業務は社内人材育成、検証・分析の技術開発、標準化、セミナー講師。訳書は『ソフトウェアテスト293の鉄則』(日経BP、共訳)、『ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書』(バルテス、監訳)。著書は『ソフトウェア見積りガイドブック』(オーム社、共著)、『続・定量的品質予測のススメ』(佐伯印刷、共著)、『IT業界の病理学』(技術評論社、共著)。 得意分野はバグ分析。

テストプロジェクトの成否の6~7割は、テスト計画で決まる

「テストプロジェクトの成否の67割は、テスト計画で決まる」というのが、品質管理の世界に20年以上いる私の実感です。

テスト計画は、テストの全体像をデザインし、テストの方向性を見出して、テスト設計やマネジメントの起点になるものです。

0331_1.png

テストプロセスの骨格

不十分なテスト計画書では、形式的・教科書的で分かりきったことしか書いていません。

よくある例だと、"単体テストの後に結合テストを実施し、その後システムテストを実施する"ということが書かれていて、スケジュールと体制表が提示されておしまい、というものです。

プロジェクトの固有の問題に対する配慮や戦略がなく、大雑把で、考慮すべき点にヌケモレがあるため、テスト計画が計画として十分に機能していないのです。

もし、テスト計画が疎かになっていると、テストに大きなヌケモレが生じたり、お客様の要望と合っていないテストを進めてしまったり、リスク管理を考慮せずに突進して後々に噴出した問題の火消しに追われることになったりする場合が多いでしょう。

前述しているようなアンチパターンのテスト計画にせず、テスト計画が計画として機能させるためには、次の3つの要素でテスト計画を設計する方法を推奨します。

1つ目は「要求の整理、分析」。
テスト計画は単なる書き物ではなく、テストという工程の設計書と捉えるのが良いでしょう。テスト計画を策定する際、いきなりその内容を検討することはしません。

最初に行うべきことは、そのテストに対してどのようなことが望まれているか的確に把握し、顧客の背景・現状はどうか、どんな課題・リスクがあるかを整理することです。

2つ目は「要求の実現方法」。
お客様がテストに寄せる要求やプロジェクトの課題やリスクなどを整理した上で、それらをどのように実現していくのか、リスクヘッジするためにはどんなアクションが必要か、テストを実施する側の視点でまとめます。

3つ目は「各種管理・計画」。
これは、課題管理、不具合管理等、プロジェクトを支えるマネジメント系の個別計画を整理します。

全体から見たテスト対象のポジションを把握する

今回のテーマに関連する「要求の整理、分析」について、セミナーではさらに詳しく解説されました。これに当たるテスト計画の項目としては、「スコープ」「開発・顧客の状況・背景」です。

0331_2.png

テストスコープの定義

「スコープ」では、2つの要素を明らかにします。

1つ目は、テスト対象の特定です。
具体的には、テスト対象の仕向け先・ドメイン(web系/業務系/組み込み系)、システム名・業務名・機能概要、システム対象の規模などです。システム名・業務名・機能概要で、テスト対象がシステム全体のどの部分に位置するかまで記載することがポイントです。

その際、テスト対象だけを切り抜いてはいけません。その周辺に別のシステムがあり、全体的に大きなシステムの中の構成要素の1つとしてテスト対象があるはずです。
テスト対象の周辺も合わせて定義し、テスト対象が周辺システムを含む大きなシステムの中で、どのポジションにあるかを明らかにします。

このことで、視野狭窄に陥ることを防ぎ、他のシステムとの連携についても注意を向けられると強調します。

このほか、テスト対象の規模では、画面数や機能数など、テストのボリュームがわかるもの定義することが有用です。

2つ目は、顧客から求められているテストの内容です。
テスト対象に適用するテストレベルや、求められているテストタイプ、主な観点などをまとめます。

テストタイプは、観念的な説明が多く、共通認識を得られにくい場合も少なくありません。

それをわかりやすくするため、「テスト目的」「テスト要素」「テストアングル」で整理する方法があります。これらの組み合わせ、または部分的に抽出したもので、テストタイプは表せます。

以上が、「テストのスコープ」を整理するためのポイントです。

「開発・顧客の状況・背景」をヌケモレなく整理するための4つの観点

「開発・顧客の状況・背景」の項目では、4つの観点から情報を整理することが求められることをお話します。

0331_3.png

開発・顧客の状況・背景

観点の1つ目は、テスト対象の開発状況についてです。
まずは、開発人員数やプログラムStep数といった開発の規模感がわかるものを整理します。

開発難易度も重要なポイントです。スクラッチ開発なのか、中核部分に大規模な改修があるのか、要素技術に新規性があるのかなど、開発する上でどこにどんな難しさがあるのかをはっきりさせます。このほか、テストベースの整備の状況、仕様の明確さ、開発でのレビューや前工程でのテストの実施状況なども調査して整理します。

これらによって、テスト対象の「品質の良さ・悪さ」を想定し、「ポイントとなるテスト対象」をピックアップします。

また、仕様不明点をどのようにカバーしていく必要があるかも考慮します。

観点の2つ目は、開発プロジェクトの開発スタイルとスケジュールです。
ウォーター・フォールなのか、アジャイルなのか、開発スタイルでテストの組み立て方も変わります。

開発がスケジュール遅延しているところがあればそれはどこか、また遅れているのはなぜか、テストへはどんな影響があるか整理し、お客様にどのように貢献していくかを考えていきます。

観点の3つ目は、顧客が重視するポイントとその理由です。
顧客からは「重点的にテストしてほしい」という要望を受けても、ただそのまま受け取るのはNGです。大切なのはその理由です。

なぜ、そこを重点的に見なければならないのか理由や背景をきちんと理解して、テストを組み立てたほうがよりよいテストになるでしょう。

最後の4つ目の観点は、お客様のプロジェクトの体制についてです。
たとえば、オフショア開発があるのであれば、コミュニケーションロスに対する備えが必要になるかもしれません。

また、仕様面やスケジュール管理、品質の管理を取りまとめているのは誰か、といったところも整理しておきます。

何か相談や報告があるときに、誰に連絡すればよいか、人探しから始まると生産性がガタ落ちになる。あらかじめキーマンを押さえておくことが、テストプロジェクトのスムーズな進行につながります。

テスト計画は、ビジネス的な領域から技術的な領域の仲介役

テスト計画の役割を改めて考えると、顧客からのふわっとした要望、あるいはビジネス的な必要性を、いったん受け止めて、実現の道筋をつくり、テスト設計のプロセスに引き渡していることにあります。

ビジネス的な領域から技術的な領域の仲介役として、テスト計画が機能しているのです。

そして、テスト計画にとって「要求分析」とは、「要求を正確に捉えるため」「要求・状況に合わせたテストアプローチを策定するため」「未決事項・懸念事項・課題・リスクを抽出するため」、それぞれの意味で、非常に重要なポジションを占めていることがお分かりいただけるのではないでしょうか。

セッション2/宇宙開発の方法論をもとにした要求分析の進め方。

株式会社レヴィは、JAXA宇宙科学研究所で研究していたメンバーが創業したベンチャー企業です。

宇宙を始め、システム開発の現場で培った経験を活かして、システムデザインのためのフレームワークを構築。価値あるシステムの構築に誰もが取り組むことのできる世界を目指されています。

今回のセミナーでは、同社のファウンダーの一人であり、エンジニアでもある萩原氏が講演しました。

講師紹介

萩原 利士成

株式会社レヴィ 共同創業者

JAXA宇宙科学研究所で宇宙物理学の研究を行い博士号を取得後、サイボウズ株式会社に入社。cybozu.comのインフラ開発に従事し、データ分析基盤の構築やNecoプロジェクトのオーガナイザーを行いながら副部長を務める。2016年8月より株式会社レヴィにて自社のサービス・研修開発や事業戦略、組織設計などを行いながら、株式会社スタディスト・株式会社PRECS・Quadcept株式会社の技術顧問として顧客企業のアーキテクチャ設計、チームビルディング、マネージャー支援なども行う。

プロジェクトの総コストの8割は、設計で固定される

宇宙開発の現場でも、要求分析は非常に重視されています。NASAの見解によると、プロジェクトの総コストは設計の段階で8割近くが固定されると言います。

その設計を決めているのが要求です。

そのため、大きな要求を見落としていると、後々コストが大幅に増えることや、要求を細かく見積もり過ぎて、本来やらなくていいことをやってしまうことがあります。

それぐらい要求のインパクトは大きいのです。

0331_4.png

何をやりたいかを決めることは大事

しかし、要求がそれだけプロジェクトに大きな影響を与えるにも関わらず、要求分析は簡単ではありません。

複数のステークホルダーがいて、方向性の違う要求を出されたり、つくってはみたけれど「これではない」と顧客から言われたりすることもよくあります。

どうしてこういうことが起こるのか。それは、要求を一律で明らかにすることが難しいためです。

階層の違う要求が入り混じるから矛盾を生む

システム開発の現場で"要求"というと、ベースライン要求のリストを思い浮かべる人が多いかもしれません。

0331_5.png

要求分析の難しさ

しかし、顧客の要求をいきなりリストにまで落とし込むには無理があります。

なぜなら、要求には階層があるからです。抽象度が高いと「幸せになりたい」、事業だと「売上を上げたい」「コストを抑えたい」、機能要件に近くなると「この画面を何秒以内に表示してほしい」「検索一覧に何件出してほしい」など。

これらが現実的には入り混じって出てくるため、その関係性を追えず、矛盾が生じることや、本来あるはずの要求が出てこないことがあるのです。

視点を「わけて」「つなげる」システミングを提唱

そのため、いろいろな階層の視点で要求を引き出すことが大切です。

しかし、階層が上がるほど、要求はふわっとしています。なぜかというと要求を出す側もわかっていないからです。たとえば家を建てたいと言っても、普段からすらすら要求を言える人はいません。

そのようなふわふわした要求を、ふわふわした状態で取り出してこないと、最終的なベースライン要求をつくるときに、ヌケモレ、矛盾が発生してしまうのです。

ここで、宇宙開発の方法論が生かされます。宇宙開発は、テクノロジーだけではなく、「複雑さに対する協働の方法論」でもあります。

NASAがこの方法論を重視するようになったのは、アポロ計画以降のこと。数十万人の人を率いるアポロのプロジェクトは、一人ひとりのプロフェッショナルが異なる視点で、ある意味別々に取り組んでいることを組み合わせ、「人を月に送る」というミッションを成し遂げました。

この実現のために行ったことをシステムエンジニアリングで体系化したのが、宇宙開発の方法論なのです。

0331_6.png

「わけて」「つなげる」基本的な考え方

株式会社レヴィでは、この方法論のフレームワークとして「システミング」を提案しています。

そのエッセンスは、視点を「わけて」「つなげる」ところにあります。ソフトウェアシステムの場合、システムへの視点を「コンテキスト(+価値)」「業務フロー」「ユースケース」にわけて考えることができます。

視点を分解することが重要で、視点を分けることで、スコープや認識が絞られて、「物事をばくっと」捉えられるようになります。

このようにして、それぞれの視点で出たものを「つなげる」、つまり整合性をチェックすることで、ヌケモレを防ぎ、上層の要求に立ち返って考えることができるようになります。

※システミングについて詳しくは以下をご参照ください
https://levii.co.jp/downloads/guidebook-02/

視覚的に捉えられるビューモデルが有効

システミングのフレームワークでは、ビューモデルを使います。

「コンテキスト」「業務フロー」など、それぞれのビューに対し、整合性をチェックし合うものどうしを整合性リンクの線で結ぶことで全体を捉えられるようになります。

そして、それぞれのビューの中身も、システムモデルという図で表現します。

システムモデルとは、システムの要素をノード、要素間の関係性をリンク(エッジ)で表現したネットワーク状の図のことです。自然言語で表現するより、要素と要素のロジック関係を正確に伝えられるのがメリットです。

0331_7.png

業務フローモデルとは

勤怠管理システムの開発を例に、「コンテキスト」「業務フロー」「ユースケース」のそれぞれのビューで、システムモデルを検証するワークを実施してみましょう。

「コンテキスト」のモデルでは、システムとステークホルダーや外部システムなどとの関係性を示します。これによって、ステークホルダーの洗い出しや、顧客との認識のすり合わせに役立てられます。

「業務フロー」のモデルでは、業務のプロセスや具体的なアクションを視覚的に捉えるのに有効です。

「ユースケース」のモデルでは、システムとのインタラクションが明確になります。

「ユースケース」はブラックボックスで表現されることもありますが、それだと何をしているのかわからなくなるため、"顧客がシステムに期待すること"ぐらいの粒度で表現することを推奨します。

いずれのモデルも、それぞれのモデルを行ったり来たりして視点を変えながら描き進めることが、ヌケモレを防ぐために大切です。

要求分析を進める際、必要に応じて視点はどんどん増やして構いません。たとえば、「画面デザイン」「画面一覧」という視点も考えられます。

視点どうしの整合性を確かめることで、要求分析したことと、システムの裏側をある程度つなげて考えられるため、要求に沿ったシステム開発を目指すことができます。

注意点としては、モデルは成果物ではないことです。モデルを顧客やメンバーと対話する際のツールとして役立ててほしいですね。

参加者の質問に、具体的なアドバイスも

以上がセミナーの内容でした。2時間という短時間ながら、非常に内容の濃いセミナーになりました。

セミナー後の質疑応答では、「モデルから要求定義につなげるときにオススメのフレームワークは?」「テスト計画は、単体ごとにわけたほうがいいのか」「テストにコストをかけることを顧客に理解してもらうためには?」といった現場のリアルな相談が寄せられ、両講演者から具体的なアドバイスがありました。

顧客の要求をいかに引き出し、向き合うにはどうすればよいのか、考え方や手法のヒントが詰まった実践的なセミナーとなりました。

株式会社レヴィについて

株式会社レヴィは、JAXA宇宙科学研究所で研究していた仲間たちが集まって創業したベンチャー企業です。宇宙開発の方法論をベースにして構築した独自のデザインフレームワーク「システミング」を使い、価値あるシステムの実現に取り組む企業やチームに対して、トレーニングやコンサルティング、システムデザインツールの Balus を提供しています。
https://levii.co.jp/

バルテス株式会社について

バルテス株式会社は、「品質向上のトータルサポート企業」を掲げ、ソフトウェアテストサービスをはじめ、ソフトウェアの開発工程における品質向上支援サービスを年間1,800以上のプロジェクトへご提供しております。業務基幹システムやWebサービス、モバイル、組込、IoTといった様々な業界、幅広い領域のお客様に対し、第三者テスト・検証、上流工程における品質コンサルティングや、セキュリティ診断をご提供しております。
https://www.valtes.co.jp/

執筆者:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。