豆寄席第13回『今更聞けないシリーズ 第3回ソフトウェア工学（要求工学編）』参加レポート
2021年12月22日に、豆寄席第13回として、『今更聞けないシリーズ 第3回 ソフトウェア工学（要求工学編）』を開催しました。
本稿では、豆寄席の参加レポートとしてご紹介します。
なお、当日参加者は社内外を問わず、100 名以上の方が参加されており、大盛況となりました。
私自身はアーキテクチャ構築フェーズ以降に関与することが多く、それより前の上流工程を担当する機会はほぼありませんでした。しかし、今回の豆寄席に参加したことで、要件定義を行う際に気をつけなければならないポイントを学べました。また、実際にどのようなフェーズを経てシステム要件を固めていけばよいかについて、一つの指針を知ることができました。
世の中にあるシステムの 2/3 は使われていないといわれています。そんな中、今回の豆寄席の題材に取り上げられているようなソフトウェア工学の手法を用いて要件を分析することで、本当に価値のあるシステムを開発できるというのも、豆蔵の大きな特長の一つではないかと強みを再発見できました。
登壇者のプロフィール
今回、講師として登壇したのは、弊社豆蔵の CTO 井上樹です。
創業当初から豆蔵に入社し、組込ソフトウェアを中心に、様々なプロジェクトでオブジェクト指向開発の導入や、ソフトウェア・エンジニアリングの導入に関するコンサルティングやトレーニングを担当しています。
社内でも井上さんの講習を受けたい?という声はとても多く、満を持しての豆寄席登壇となりました。
講演内容
- はじめに
「要求が大事」の前提
- 要求?要件?
- 「要求」の特徴
- 「要求」エンジニアリングのポイント
- 最後に
はじめに
「要求が大事」の前提
正常に動いている他の機能を壊さずにコードの修正や追加を行うことは、ソフトウェア開発の中で最も難しいレベルです。
作業工程のフェーズが進んでいくにつれ、修正に必要な時間と費用は指数関数的に高くなっていくそうです。上図のとおり、要求に問題があり、要求の段階で見つけて修正する場合のコストは、１件あたり80,000円のコストで済みます。一方で、設計、実装、テストとフェーズが進んでいき、テストの段階でようやく問題が発見されて修正した場合、1件あたり4,175,000円のコストが掛かり、要求段階よりも50倍のコストが掛かると言われているそうです。
最近はアジャイル開発が席巻しており、動くものを作り成果物を見せながら作業を進めていくのが主流となっています。
しかし、闇雲に作れば良いということではなく、作らずに済むものは作らなくて良いというお話がありました。
とりあえず作ってみよう?というのは実際のプロジェクトでよくある光景で、クラス設計などをよく考えずに作成したプロトタイプであってもそのままプロダクトコードに組み込んでしまうシーンを沢山見てきました。
初期のプロトタイプであるが故に修正を加えづらかったり、障害発生時に調査に時間が掛かったりと、過去苦い思いもしていたため、胸にストンと落ちました。
要求?要件?
開発の中では、「要求」や「要件」など色んな言い方をされます。ここでは「要求」と「要件」の言葉を定義します。
要望?
システムの初期段階で一番最初に関係者が好き勝手言ってくるもののことを「要望」と定義しています。
やるべき事、やらなくていい事がごちゃまぜの状態です。
要求?
システムで実現しなければならないことをまとめたものを「要求」と定義しています。
要望を出した側と開発側で合意形成がなされたものです。要望を出した側が勝手に変更や追加を行ってはいけません。変更や追加を行いたい場合、再度開発側と合意形成が必要です。
要件?
成果物視点で書かれており、「要求」を満たすために完成したシステムが実現することを「要件」と定義しています。テストケースが作成可能なレベルで記載されているものであり、開発側で検証が可能とのことでした。
仕様?
要件と同じ内容ですが、要件を全て網羅したものを「仕様」と定義しています。
誰が作っても同じアウトプットを出すために、もうこれ以上書くことがないレベルで詳細に記載するとのことです。
※ なお、この言葉の定義はあくまで豆蔵内部での定義ですので、一般論とは異なる点には注意が必要とのお話でした。
この「 要求?要件?」で私が一番印象に残ったのが、要求の定義における「要望を出した側が勝手に要求の変更や追加を行ってはいけません」という点です。要求側が勝手に要件を変更するという理不尽な出来事自体は、かなり珍しいケースといえます。
しかし、要求側が勝手に要件を変更する出来事を、私自身も豆蔵へ入社する前の開発プロジェクトで経験したことがあります。その際には、人的リソースやスケジュールの変更を余儀なくされ、多大な負荷が生じました。そして、開発チームの作業工数が増大し、ソフトウェア品質が低下してしまったのです。また、何より大切な開発メンバーのモチベーションが低下してしまいました。
ここでは、言葉の定義の認識を関係者間で予め合わせておくことが大事であり、「要求」の合意形成の重要度を再確認することができました。
要求の特徴
要求の種類には、レベル感、分類（プロダクトに対するもの、プロジェクトに対するもの）があるとのことです。
要求は要求元が関心・興味を持っている範囲のものしか出てこないため、要求元が関心・興味のない部分に関しても、開発側が要求元と一緒になってやらなければならない事に関して提案をしていかなければならなそうです。つまり要求元から出てくる要求の内容だけでは要求が揃わないという事になります。
また、要求にはその要求が必要である目的・理由があり、その要求の背景にある目的・理由を把握しなければ、要求を本当の意味で理解したとはいえないということが重要とのことでした。
要求エンジニアリングのポイント
要求の理解と整理をキチンと実施する必要があるとのことです。
要求の整理における漏れの確認として、ソフトウェア要求品質のフレームが役立つというお話でした。
私はソフトウェア開発工程において、各フェーズ毎に要求を定義できるというのは始めて知りました。が、このように様々な観点から要求を整理することで、それぞれのフェーズ毎に隠された要求を網羅できると感じました。
最後に
今回の講座を受講して重要なポイントのおさらいとして、以下にポイントをまとめました。
今の開発には要求分析が圧倒的に足りません
ハッピーな開発を行う為にも、すぐに作ることは止めましょう。
作り始めるまえに一度立ち止まり、今何を作らなければならないか?今何を求められているか?を考えることが重要です。
スケジュールの超過、コストの超過が常態化しているなら、要求分析をやりましょう。
ソフトウェア開発なんてそういうものなんじゃないの?と思われている方には一度実践してみてほしいです。
以上が豆寄席『今更聞けないシリーズ 第3回ソフトウェア工学（要求工学編）』のレポートになります。
ソフトウェア開発に関与されている皆さんも、脳に大粒の汗をかきながら、日々苦闘をされているものと思います。ご自身のプロジェクトの中で、様々な問題を抱えられている方も少なくないのではないでしょうか。
例えば「せっかく作ったシステムなのに、エンドユーザ様からの評価がイマイチ」、「リリースのたびに不具合が発生して品質が悪い」、「内部設計に規律がない為、機能の変更がしづらく、残業が多くなっている」などなど...
そういったプロジェクトの問題解決に、今回の講演内容であるソフトウェア工学の手法を使ってアプローチするのはとても効果のある事だと感じました。
豆蔵 CTO 井上曰く、「ソフトウェア工学は、実際のソフトウェア開発を通じて実際に効果があると結論づけられたノウハウの集積」である。
この講演内容に触れることで、実務で苦しんでいる方が問題解決のヒントになっていれば幸甚です。
今後の豆寄席にも是非ご期待ください。