SQiPシンポジウム2022 併設チュートリアル "演習で学ぶソフトウェアエンジニアリング" の後記

去る2022年9月7日の13時～17時、SQiPシンポジウムにて "演習で学ぶソフトウェアエンジニアリング" というチュートリアル(講座とも言う)を開きました。この講座は、原著が大学の教科書として採用されている実践ソフトウェアエンジニアリング第9版 (以下、本書)を主な参考文献として、ソフトウェアエンジニアリング(工学)の主な領域と、分野そのものの意義を演習形式で学ぶという講座であり、7種の演習問題を4人で開発しました。

Q	題名	学習目的
Q1	寿命	長く使われるソフトウェアには様々な変化が起き、それらを乗り越える技術の必要性を知る
Q2	プロセス	プロセスは固定されるものではなく適応させるものであることの理解を深める
Q3	見積り	見積りの価値はコントロールにより達成可能な程度に現実的か判断できることの理解を深める
Q4	設計の意義	同じ外身のソフトウェアが複数あったとして中身は全く異なりうることと、中身の品質が行く末を左右することを理解する
Q5	品質の概念	ソフトウェア品質は捉えどころが難しい概念であり、その表現と評価方法が発明されてきたことの理解を深める
Q6	レビュー	早い段階で入り込んだエラーは増幅されることと、レビューがエラーを早い段階に安く見つけられうる手段であることの理解を深める
Q7	分野の理解	ソフトウェアエンジニアリングという分野が何を指すか、指さないかの理解を深める

以下、Q1 から Q7 の概要と受講者から提供された回答を紹介します。演習問題そのものも公開したいと考えていますが、どのように公開するか決まっていないので、ここでは概要のみ示します。また、演習の区分けとしては Q1～Q7 で全てなのですが、割愛している演習問題もあります。

Q1. 寿命

Q1-1. あなたが仕事で手掛けるソフトウェアはどれほど長く生きている（生きた）か？ソフトウェアが生きた長さとは、新規開発が始まってから、提供とサポートを終了して市場から撤退するまでの時間を指す。
Q1-2. 長く生きているソフトウェアを1つ以上思い浮かべよ。あなたが仕事で手掛けているものでも、そうでないものでもよい。それは、長い時の中でどれほど変化しているか？ユーザー、要求、ソフトウェアの構造、開発組織に着目して考えよ。

Q1 の学習目的である「ソフトウェアの長い寿命の中で起きる変化を乗り越える技術の必要性を知る」は、本書1章の記述に対応します。

ソフトウェアエンジニアリングのゴールは…進化論に基づく(ソフトウェアシステムが変化し続ける状況に対応する)方法論を考え出すことである。

チュートリアルでは扱いませんでしたが Google のソフトウェアエンジニアリングにある ソフトウェアエンジニアリングとは時間で積分したプログラミングである という定義はこの言い換えだと考えています。寿命の長いソフトウェアほどソフトウェアエンジニアリングが必要になるとも言えるでしょう。

最初にこれらの設問を受講者の経験をもとに考え、その後に解説を聞くことにより、受講者の手掛けるソフトウェアに訪れる変化を乗り越える技術の必要性に気づけるようにデザインしました。解説では、実際のデスクトップアプリ、Web サービス、鉄道、自動車といった長寿のソフトウェアを挙げ、機能や規模が大きく変化していることや、別の製品に転用される場合もあることを述べました。

実際の受講者の回答を抜粋します。

Q1-1.
- 10年
- 5年くらい
- 10年ぐらい。（まだ生きている
- 約5年（継続中）
- 顧客向けシステムで、導入から廃棄までの期間として、短いもので2-3年、長いと5-10年くらいでしょうか。
- 15年～20年くらい
- 数年～10年
Q1-2.
- Microsoft Office (UIデザイン)
- 銀行システム、窓口対応 → ATM対応 → オンライン対応、統廃合によるシステム統合
- 組み込み。自動車(ECU)のブレーキ（自分が担当したもの）国や車のグレードによって変化するが、一度リリースされればリコール無い限りは変化はしない
- 前職で新規開発したシステム（CMS）が約15年。お客様からの要求に合わせて機能を追加していった結果、開発メンバーの中にも全体を把握する人が少ない状況。別の会社で手がけた成果卸センターの売上・請求システム（30年以上）。データのやり取りにフロッピーを使っていたが、Webシステムに移行
- 生産管理システムと連携している業務システムとかグループウェアとか。法律改正によるへんか、ユーザの使い方による変化。
- 一部安全機能を追加することはあるが、一度市場に出て行ったら、そのまま故障するまで動作し続ける。基本機能に大きな変化はない。新製品になると、新たなハードウェアが追加になり、それに伴う機能追加をしている。
- 月単位で機能改造されている。ユーザのアクセス挙動も変化する。

5年10年は共通のようです。どのような変化があるかはそれぞれのようです。例えば、「一度リリースされればリコール無い限りは変化はしない」と「月単位で機能改造されている」という回答は対照的です。

オンラインゲームや Web サービスのように、利便性と娯楽が進化することが求められる製品であれば、毎月や毎週といった程度の頻度で市場投入することが望ましいでしょう。また、その利便性と娯楽がユーザー層によって異なる可能性があるのであれば、ユーザー・機能・期間を限定した市場投入ができることも望ましいでしょう。

自動車のブレーキのように、少数の機能が絶対の信頼性をもって稼働することが市場から求められている製品であれば、市場投入後の変化は無いことが望ましいでしょう。ただし、1つの製品における変化は少なくとも、車種という製品シリーズの中でソフトウェアは継続的に変化してゆくはずです。また、ユーザーから認識できる機能に変化はなくとも、原価と調達費を抑えるためのハードウェア変更によってソフトウェアも変更する場合もあります。新たなハードウェアが追加になり、それに伴う機能追加をしている というのもその一種ではないかと想像しました。

この演習では、受講者の手掛けるソフトウェアに変化があることを気づかせるきっかけを提供するに留めました。より深く考えるには、その変化の源泉が何か、製品・業界・市場によるのか、それを乗り越える技術に違いがあるのかを議論すればよさそうです。

Q2. プロセス

広く受け入れられたアプリケーションを別のOSに移植する開発(A)、新企画・新市場・新技術の開発(B)という対照的な開発があるとする。そして、要件定義→設計→コーディング…というフェーズとレビューを設けるプロセス(X)と毎月リリースするプロセス(Y)という対照的なプロセスがあるとする。開発A, B をそれぞれプロセスX, Yで進めることを想定すると、どのような適切さ・不適切さが考えられるか？

受講者の回答には次の傾向がありました。

A-X
- ほとんどの受講者が適切と回答していました。一部の受講者は「あらかじめ作るものが決まっているとはいえ、上流で遅れが発生した時に取り返せなそう」という理由で適切とは言い切れないと回答していました。
A-Y
- ほとんどの受講者が不適切と回答していました。理由を以下に抜粋します。
  - 月１回のリリースは不要そう。。。
  - 根本部分の変更なので、少しずつリリースするというのは難しい。また、やるべきことがハッキリとしているので、前準備をしっかりとやるのが良い
  - 新規に盛り込む機能等があればわるくはないかもしれませんが、そうでなければ無駄が多いように思う。
  - しっかりアーキテクチャと機能を作りこんでいかないと、テストフェーズで破綻する
B-X
- 全ての受講者が不適切と回答していました。理由を以下に抜粋します。
  - 新規事業になるので探索的になる可能性が高い
  - 新企画なので、要求が決まらなさそう
  - ギリギリまで要件が定まらない可能性がある
  - 後工程で要件変更多発、技術課題発生
B-Y
- ほとんどの受講者が適切と回答していました。理由を以下に抜粋します。
  - 月1回のレビューがあるので、方針ずれの修正とか、ゴールの設定しなおしが出来そう
  - X よりは

この演習の目的は、要件が決まっていれば(A)ウォーターフォール(X)がよい、新規開発(B)ならイテレーティブ(Y)がよい、という固定のパターンを伝えるものではありません。プロセスは固定されるものではなく適応させていくものであることを短時間で実感するために簡略化した題材です。この目的を伝えるために、本書に書かれている代表的なプロセスモデルを列挙し、プロセスモデルの教訓をいくつか紹介しました。

2章より

規範的なソフトウェアプロセスモデルはソフトウェア開発に秩序と構造をもたらすことを目的として長年適用されてきた。

3章より

規範的なプロセスモデルは重大な欠点があり「ソフトウェアを構築する人間の弱さを忘れている」と述べている。… 仮に現場で使われるプロセスモデルが存在するなら、そのモデルは規律を守る現実的な仕組みをもつか、ソフトウェアエンジニアリングに従事する人へ「寛容さ」を示さねばならない。

また、プロセスモデルを表現する方法として Process Flow Diagram も紹介しました。

より深く学べる演習にするのなら、開発の特徴の選択肢を増やしたり(例：モバイルゲーム、ネット家電)、プロセスモデルの選択肢を増やしたり(例：DevOps と RUP とカンバン)、プロセスモデルを白紙から記述する演習にすればよいと考えています。

受講者の回答を深掘りするのもよいでしょう。例えば、「Aの場合月1回のリリースは不要なのか？リリースをシステムテストに置き換えるとどうか？」「なぜ根本部分の変更だと少しずつリリースするのが難しいのか？」「XよりYの方が良いということはYが最適ではないと考えているようだが、より適したプロセスをどう考えているか？」というものです。

また演習の機会があれば演習の方法を洗練させてみたいものです。

Q3. 見積り

この演習は本書の25章に載っているものです。

ソフトウェアプロジェクトの企画や計画中、つまりソフトウェアの要求分析や設計を実施する前に、コストと期間の見積りを出すことは奇妙にも見える。なぜこのような見積りを実施するのか。また、実施すべきではない状況があるか考えて述べよ。

講師として模範回答の1つを示します。

プロジェクトのために必要である。プロジェクトの成功基準として、一般にはスケジュール、コスト、スコープがある。工数と期間の見積りはプロジェクトの成功基準となる。
経営のために必要である。ビジネスでは売上と利益の目標を定める必要があり、どれほどの資金を投資して、いつ、どれほどの利益を得られるか想定しておく必要がある。ステークホルダーへの説明のためにも必要である。
見積りには、要求の内容、未来の要求、設計の難易度、既存ソフトウェア資産の再利用可能性、投入できそうな人員の数とスキルなど、不確定であり定量化しづらく確率分布を伴う様々な情報が必要となる。多くの情報が確定すれば見積りの精度は良くなるが、確定してからでは経営とプロジェクトのためには遅い。プロジェクトを始める前という不確定性が高い状況であっても見積りには意義がある。見積りに影響すると考えられる情報が何か、その範囲はどれほどかを複数の経験者が示して議論することで、経営とプロジェクトのために考慮する情報として見落としがないか、楽観的・悲観的に見ていることがあるかを共有することができ、より的確にスケジュール・コスト・スコープを予測できると考えられる。
見積りに必要な情報が少なすぎる場合は、見積り以前の問題である。ただし、少なすぎることの判断基準は教科書には無く、組織で持たなければならない。また、見積りの算出方法が他者が理解できないほど複雑になった場合は、いったん見積りを諦めて開発を始めた方が見積りのためにもよい。

続いて、受講者の回答を抜粋します。

規模感の把握のため
大規模な開発であれば、ソフトウェア以外のメンバーがどれくらい必要か等、開発規模を把握するため
予算を取るために必要
事前にリソースを確保したいから
どれくらいでリリースできそうかの目途をつけなければ損失(や手戻り)になってしまうから
人を確保するのにも時間が掛かってしまう
組織としての少し長いスパンで経営的な視点で計画を立てたい場合必要になる。(コストや利益、人の計画とかとか)
見積もりの前提・想定は明確にしておく必要がある
見積もりの種類も関係者で共有していないと予算のギャップになってしまったりする
対外的に報告する必要があるから
投資判断をするために実施する
委託等との契約上必要な情報だから

プロジェクトのために見積りをするという回答が多いようです。経営のために必要という趣旨の回答もあるように見受けられます。ほか、講師は想定していなかったのですが、協力会社に提示する必要を示す回答もありました。見積りの結果を示す主体と相手が回答にどう表れるか、受講者の所属企業と立場によるのかもしれません。

問題文では見積りをする状況を想定しづらい方向けに補足を入れておきました。SaaSのビジネスでスタートアップから成長し、年に数億以上の売上となった。今後のビジネスのスケーリングへ向けてシステムを換装することを決めた。この段階で見積りを行うか。その判断に対して理由を考えよ。 というものです。ただ、それが勘案されたかは回答から読み取れませんでした。

問題文にある "奇妙にも見える" について触れている回答は見受けられませんでした。見積りを実施すべきでない状況に触れている回答も見受けられませんでした。回答時間が短く、見積りの理由しか書けなかったのかもしれません。本問に限らず、回答時間を増やす必要があると考えています。

より深く学ぶには、見積りを左右する代表的な情報に何があるか、それらの情報を即値ではなく確率分布として表せるか、なぜそれらは不確定な情報なのかを問う演習が考えられます。こちらも機会があれば洗練させてみたいものです。

Q4. 設計の意義

https://masskaneko.github.io/design-choice/ という2Dシューティングゲームのプロトタイプがある。このプロトタイプの設計案として A, B の2案 ( https://github.com/masskaneko/design-choice/ にある A/, B/ ) があり、どちらも同じ動きをする。A, B どちらの設計が良いか？なぜか？

A は全ての処理をメインループに書き、多くのデータを外部結合グローバル変数とした設計です。B はゲームの要求からオブジェクトを見出してカプセル化と情報隠蔽に基づいた設計です。

受講者の回答を抜粋します。

A について
- mainファイルのみ。すぐコンフリクトしそう。どこに何がわかりにくい。
- 複数人で開発を進める上で、mainプログラムだけの作りだと作業を分担しずらい。
- 完全に捨てる前提のプロトタイプならAでもいいのかも
B について
- 複数人の開発に向きそう
- クラスごとに責務が分かれている、変更が容易、分業可能、テストしやすい
- アーキがあり、設計されている。複数人での開発やりやすい。
- 機能を追加する際も、オブジェクトを分けることで改修が楽になる。
- コードが構造化分割されている → 改修範囲が絞りやすい、変更時にテストしやすい
- Bはモジュール分割されている。またクラス構造がドキュメント化されており、メンテナンスしやすい。

全ての受講者が B を選択し、理解のしやすさ、変更のしやすさ、テストのしやすさ、分担のしやすさを挙げました。

完全に捨てる前提のプロトタイプならAでもいいのかも というのは鋭い意見で、Q1.寿命に関連します。2022年の参議院選挙の前に登場した選挙ゲームは Twitter で数千RTされるほど楽しまれました。このゲームは1人が1日で制作したものであり、今後の変更予定はありません。そして、そのソースコードを見ると、この演習における A 案と同じく、ほとんどの処理がメインループに書かれていることがわかります。1人がすぐに完成させられるのであれば保守性のための設計をしなくてもよい、保守性はユーザーからの人気には関連しないことを示す良例ではないでしょうか。ただし、受講者が Q1 で答えた寿命を持つソフトウェアであれば別であると理解する必要があるでしょう。

A, B の質をどれほど離すか悩みました。少しでも仕事としてプログラミングをした経験があれば B を選ぶことは簡単だからです。とはいえ、A に対する B の特徴をどれほど記述できるかは差が出ると見込みました。また、SQiP シンポジウムの参加者は必ずしも日常的にプログラミングをしている職種ではないことも考慮し、A, B の選択自体では迷わないようにしました。ただ、受講者の回答を見ると物足りなかったのかもしれません。再演の機会があれば A, B のバランスを再考したり、選択肢を増やすといった検討をしてみます。

解説では、本書9章に記された設計の概念、19章に記されたユニットテスト環境、コードの品質を測るツール CCCC、外部特徴と内部特徴の関係を示す ISO 25010 の図を紹介しました。ソフトウェアの実行とコードリーディングを経た後での解説なので、実感をもって理解できたのではないかと期待します。

Q5. 品質の概念

あなたが大学を志願するとしたとき、何が評価項目として挙げられるか。
それらを3段階の重要度に分けよ。

この演習問題は本書15章に載っているものを一部改変したものです。

ソフトウェアの品質ではなく大学の品質を問われたので、戸惑った受講者が多かったのではないかと推測します。この問題を選んだ理由は、捉えどころが無く感じる品質を記述することの難しさを実感するためです。

複数の受講者の回答を合わせたものを抜粋します。

重要度：高
- 学習と研究の内容、学費、通学時間、入試の難易度
重要度：中
- 学習と研究の内容、学費、知名度、通学時間、入試の難易度
重要度：低
- 学習と研究の内容、入試の難易度、学費、卒業生の進路、留年率、性別比、知名度、通学時間

"学習と研究の内容" や "入試の難易度" など、多くの受講者が共通して評価項目として挙げたものがありますが、その重要度は受講者によって異なりました。

この演習問題では、さらに本書15章に記載されている David Garvin の5観点にもとづいて上記の評価項目を分類しました。これもまた同じ評価項目であっても受講者によって異なりました。

これを例に、品質は捉えどころがなく、人・立場・状況によってばらつき、優先度もばらつき、観点があったとしてもばらつくことを説明しました。その文脈で解説はソフトウェア品質に続き、McCALL, SQMAT, Wulf, SQuaRE を引用して、品質のモデルが多様なバックグラウンドを持つ人々とソフトウェアの進化と共に発明されてきたことを述べました。

そして、ソフトウェア品質を評価するときに利用できる技術を本書の章を参考に挙げよ、という演習も行いました。受講者の回答傾向は概ね以下に分かれました。

テスト(19章と20章)、レビュー(16章)、メトリクス(23章) を挙げた方
それに加えてプロセス(2～5章)、プロセス改善(28章)、マネジメント(24～27章)を挙げた方
ほぼ全ての章を回答した方

「ほぼ全ての章」が模範回答に最も近いものです。この解説は本書15章の次の記述を起点としています。

最も一般的な意味においてソフトウェアの品質は、「作る人と使う人に重要な価値をもたらす有用な製品を作り出すための、効果的なソフトウェアプロセス」と定義できる。

そして、プロダクトの品質を 直接的に 評価する技術は、本書で言えばテスト(19章と20章)、レビュー(16章)、メトリクス(23章)ですが、プロダクトを生み出すプロセスの品質も評価が必要であり、そうなるとそこで使われている全ての技術が評価対象となると解説しました。

もう少しくだけて言えば、どう設計されているかわかればより良いテストができる、要求がどのように生まれて関連づけられているかがわかればより良いレビューができる、プロセスモデルとマネジメントがわかればボトルネックを特定しやすくなる、といった具合でしょう。そして、本問についてより深い演習をするなら、こうした具体化を考えることが効果的ではないでしょうか。

Q6. レビュー

この演習問題は本書の16章に掲載されているものです。

要求モデルに10個のエラーが入り込み、設計時に要求エラーが2倍に増幅され、さらに20個の設計エラーが追加で入り込む。さらに、コーディング時に前段までのエラーが1.5倍に増幅され、30個のコードエラーが入り込むと仮定する。その後、すべてのユニットテストでエラーの30％を発見し、結合テストで残りの30％を発見し、妥当性確認で残りのエラーの50％を発見すると仮定する。エンドユーザへリリースするときに残っているエラーは何個か。この例において、要求レビュー、設計レビュー、コードレビューのそれぞれで60%のエラーを検出できるとすると、エンドユーザへリリースするときに残っているエラーは何個か。

この問題では、要求に基づいて設計し、設計に基づいてコードを書くというプロセスを想定します。また、ソフトウェアが期待通りに動作しない問題には "バグ", "欠陥", "不具合" など様々な呼び名がありますが、本書では問題の発見されたタイミングがエンドユーザーへのリリース前であれば "エラー", 後であれば "欠陥" と呼んでいます。この演習問題でも同様です。答え自体は単純な計算で出せます。

要求に含まれるエラー数 re = 10
その要求に基づいて設計した時点でのエラー数 de = re*2 + 20 = 40
その設計に基づいて書いたコードに含まれるエラー数 ce = de*1.5 + 30 = 90
ユニットテストで30%、結合テストで30%、妥当性確認で50%のエラーを発見すると、残りのエラー数は 90 * 0.7 * 0.7 * 0.5 = 22

60%のエラーを検出できるレビューをする場合は

要求に含まれるエラー数 re = 10 * 0.4 = 4
その要求に基づいて設計した時点でのエラー数 de = (re*2 + 20) * 0.4
その設計に基づいて書いたコードに含まれるエラー数 ce = (de*1.5 + 30) * 0.4
ユニットテストで30%、結合テストで30%、妥当性確認で50%のエラーを発見すると、残りのエラー数は 19 * 0.7 * 0.7 * 0.5 ≒ 4.58

となります。この後、エラー1件あたりの費用を仮定して、レビューによって節約できた費用を算出する設問も設けました。こちらも本書に載っている問題です。

この演習の目的は簡単な四則演算ができることではありません。間違った元情報に基づいてプロセスを進めると新たな間違い(エラー)が生まれることを実感することです。本書16章には次の記述があります。

早い段階で入り込んだエラーが検出できなければ、設計中に複数のエラーに増幅される可能性があり、これらの効果的なレビューを使用して発見しなければ、コーディング中にさらに多くのエラーに増幅される可能性がある。

また、早い段階でエラーを見つけるとコストが安くなることを本書15章の図15.2(Boehm 2001)も合わせて説明しています。

どのようなエラーがレビューで見つけやすいかも JSTQB Foundation Level シラバスを引用して紹介しました。

そして、レビューでは見つけにくいエラーを見つけようとし、事前準備や人数をかけすぎてしまう場合も説明しました。本書16章の冒頭には端的にこう書かれています。

ソフトウェアレビューは…「フィルター」である。荒すぎると汚れが残ってしまい、細かすぎると流れ自体が遅くなる。

本書でレビューを扱う16章の本文には学びのある記述がたくさんあります。ただ、章末の問題は必ずしも良い問題ではないのではないかと疑うようになりました。 4章で (Q2.プロセスで) イテレーティブなプロセスを推奨したのに、この問題では逐次的なプロセスを前提としています。要求のエラー、設計のエラー、コードのエラーの検出しやすさは検出方法によって異なるはずですが、どの種類のレビューとテストでも一様に検出できる前提となっています(例：ユニットテストで要求のエラーは見つかりやすいか？)。誤った要求に基づいて設計するとエラーがどれだけ増幅するか、要求が正しくても発生する設計のエラーはどれだけあるのか、誤った設計に基づいてコーディングするとエラーがどれだけ増幅するか、設計が正しくても発生するコードのエラーはどれだけあるのか、という実測データは本書にありませんし、講師も補足していません。早い段階でエラーを見つけるとコストが安くなることの根拠として本書の Boehm 2001 を引用していますが、20年前のデータなのでアップデートしたいところです。時間制限のあるチュートリアルだから簡単な計算問題が合うだろうという目算で選んだのですが、安直だったかもしれません。また機会があればこれらを見直して出題しようと思います。

Q7. 分野の理解

最後の演習はソフトウェアエンジニアリングという分野を理解することです。

Q7-1

まず次の問題を出しました。

SQiPシンポジウム2022本会議プログラム2日目の C3-2 アジャイルプロセスにおけるリードタイムの可観測性を『3階層』に分けたことで見えた開発力向上の勘所の発表概要を読み、この発表が本書におけるどの章の要素を強く含むか予想せよ。

この発表概要をSQiPシンポジウムのサイトから引用します。

アジャイル開発を成功させるには、限られた予算の中で、イテレーティブさを保ちながらユーザー価値を提供する開発プロセスが必要となってくる。プロセスの中で「何を証明したいのか」を仮説として考える。施策を実行する中においては、できるだけ速く機能開発を行い、ユーザーフィードバックをもとに、どれだけ柔軟に対応できるかが、とりわけ求められる。そこで、よくボトルネックとなるのは、リードタイムの問題である。「開発が遅くてリリースができない」「組織内の承認がおりず、手戻りが発生した」等の問題に対して、どこに問題の根源があるのか、何に時間がかかっているのかの詳細な洗い出しが困難な現場が多い。または、それらの問題に対して定量的ではなく定性的で感覚的な意思決定を下すことも多い。本研究では、それらのリードタイムの可視化難化について、定量的であり且つチームに伝えやすい粒度で改善が進むように可視化するアプローチを行った。また、そこから派生する形で、リードタイムを可視化するだけではなく、アジャイル開発における生産性の指標についても見えてきた部分があるのでご紹介できればと思う。

この出題意図は、SQiPシンポジウムのような発表概要を見たときに、それがソフトウェアエンジニアリングという分野のどの部分なのかを推測できれば、望む知識に辿り着きやすくなることです。

以下、模範回答例を示します。

「アジャイル開発」は3, 4章で扱われる。「イテレーティブ」「仮説」「ユーザーフィードバック」「リードタイム」というキーワードもアジャイル開発に強く関連するものである。2章のプロセスモデルも関連する可能性がある。
何に時間がかかっているのか詳細な洗い出しが困難、定量的であり且つチームに伝えやすい粒度で改善が進むように可視化するアプローチ から、28章(ソフトウェアプロセス改善)の関連が考えられる。
生産性の指標 メトリクス は23章で扱われる。
リードタイムの見積りを扱うなら24章(プロジェクトマネジメントの概念)と25章(実行可能で役立つソフトウェア計画)、リードタイムのリスクを扱うなら26章(リスクマネジメント)の関連が考えられる。
何がリードタイムのボトルネックになっているのかによって、6章～22章を含む可能性が考えられる。
発表者の所属がWebアプリ主体の企業なので、Webアプリを扱う13章と21章が関係するかもしれない。

受講者の回答では、3章と23章が多く挙げられていました。発表概要に「アジャイル」「メトリクス」という本書の章名になっているキーワードがあるので推測しやすかったのだと思います。次点で25章(実行可能で役立つソフトウェア計画)と28章(ソフトウェアプロセス改善)も挙げられていました。発表概要の意味を理解していることの現れだと思います。7章(要求エンジニアリング)という回答もありました。おそらく 何を証明したいのかを仮説として考える ユーザーフィードバック からの推測であり、良い着眼だと思います。

1つか2つの章を挙げている回答者が4割、3つ以上の章を挙げている回答者が6割でした。強く含むか予想せよという問題文だったので1つか2つに絞ったのかもしれません。関連の強い順に3つ以上挙げよ、であれば頭を使って関連を見出す演習にできたのではないでしょうか。 3章と23章だけ挙げて終わりでは勿体なかったと思います。

Q7-2

Q7-1 と同じく発表概要から関連する本書の章を挙げる問題です。 Q7-1 との違いは、本書に載っていないことが何かを見出すことです。本書が大学院生向けの教科書であり、ここ数年の技術もいくらか載っているとはいえ、分野の全てが載っているわけではありません。それを体験できる演習問題として出しました。詳細は割愛しますが、本書と同じく体系的な記述をしている本として SQuBOK V3 を挙げ、違いを述べました。両者は似たような分野の似たような量の本ですが、誰のために書かれたか、誰が書いたか、どれほど編集されてきたかによって、その内容と構成は変わってくると説明しました。

Q7-3

最後の演習問題Q7-3に続きます。

ソフトウェアエンジニア(職種)の実務が成功するため知識はソフトウェアエンジニアリング(工学分野)だけではない。これを説明せよ。

これが、Q7の学習目的である ソフトウェアエンジニアリングという分野が何を指すか、指さないかの理解を深める をより直接的に問う問題です。

模範解答を示します。

他のコンピューティング分野の知識が必要となりうる。情報処理技術者試験のシラバス、情報処理学会の研究会一覧、ACM Computing Curricula を見れば、ソフトウェアエンジニアリング以外にどのようなコンピューティングの分野があるかがわかる。代表的にはコンピューターサイエンスと関連する数学である。サイエンスの素養がなければ、ソフトウェアエンジニアリング以前に最低限の価値があるものですら実現できない。どれほどサイエンスの知識が必要かは作ろうとしているソフトウェアによる。
証券取引、医療、自動車、建設、工場、ゲーム、映像、音楽といった、製品・業界に固有の知識が必要である。数理的な理論や経験則としての理論、国際標準、デファクト標準、法規、商習慣、ビジネスモデル、ユーザーと他のステークホルダーの理解が必要となりうる。そうした知識が不足すると、要求を見いだせない、法規に違反する可能性が大きくなる。そうした知識はドメイン知識と称され、ソフトウェアエンジニアリングという工学分野では一般的に扱われない。
バックオフィスと呼ばれる職務にはソフトウェアエンジニアの実務の成否に強く関連するものがある。リモートワークできるか、開発に適したマシンとネットワークを整備できるか、リリースされて間もない OSS やクラウドサービスを試用できるか、定額と従量課金が混合しクレジットカード決済が基本クラウドサービスの支払いに対応できるか、大きな貢献のできそうなエンジニアを高待遇で採用できる人事制度があるか、というバックオフィスの職務が挙げられる。これらはソフトウェアエンジニアリングという工学分野では一般的に扱われない。

受講者の回答を抜粋してフィードバックします。まず他のコンピューティング分野の知識に関する回答から。

コンピュータサイエンスの分野が、含まれていない。まずその内容が必要である。
- まず という表現にサイエンスあってのエンジニアリングという意図を読み取ることができます
システムを構築するためのITスキル
- 直接的な構築技術が必要という意味だと考えると、これもコンピューターサイエンスを指しているのではないでしょうか
開発ドメインの知識
- この受講者は業務知識については別に記載しているので、開発ドメインとは製品・業界に特有のドメイン知識とは異なるものと考えられます。おそらく、不特定多数のユーザー・多数の計算機・ベストエフォートであるWebシステムと、特定ユーザー・少数の計算機・ハードリアルタイムである組込みシステムという意味で開発ドメインと呼んでいるのではないでしょうか。だとすると、これもソフトウェアエンジニアリング以外で主に扱われるコンピューティングの分野の必要性を回答しているものでしょう。

ドメイン知識に関する回答：

システム化対象領域の業務知識
- 企業向けシステム (エンタープライズシステム) では、ドメイン知識と同じ意味で業務知識と呼ぶことがありますね
ソフトウェアエンジニアリングは方法。目的に関する部分は工学分野に含まれない
- ここでいう目的とはソフトウェアエンジニアリングらしく言えば要求です。要求を扱う方法はソフトウェアエンジニアリングに含まれますが、要求の具体的な内容については含みません。この回答はそれを意味しているのだと思います。
特定のドメインであったりビジネスを成功させることを考える必要があること
- これもおそらくドメイン知識についての回答ですが、ビジネスを成功させるというとそれを超えた意味があるように思えます。ユーザーに提供した価値が金銭的な利益につながるまでの導線を設計して成功させるには、当然ながらソフトウェアエンジニアリングを超えた知識が必要になり、この回答はそれを意味していると考えられます。

人間とコミュニケーションに着目した回答：

人が介在する以上、コミュニケーションスキルが最重要だったりする
ヒト(ユーザの知識や感情、開発者のスキルとか)を含めて考える必要があること
ソフトウェアエンジニアリングを知らない他の職種との良好なコミュニケーションができなければ、要求を獲得することができないなど、成功を収めることはできない。
文化や生活習慣といった人の行動とその遷移を含めて考える必要があること
コミュニケーション能力や広い技術が必要で、技術だけでは実現できない部分が多くある。
- 本書にはソフトウェアエンジニアリングの人間的側面(5章)が記述されていますが、その焦点はソフトウェアエンジニアリングを担う人々に当てられています。これらの回答からは顧客や他職種という広い人々に着目しているように見受けられます。そうした人々とのコミュニケーションによっては要求・予算・設備が決まり、ひいてはビジネスの成否を左右するほど重要なものになりうるでしょう。
- コミュニケーションといっても、報告・交渉・討論・発想・親交といった種類があり、種類によって相手もテクニックも異なります。ここを掘り下げると、自身の境遇で必要なコミュニケーション能力が見えてくるでしょう。

その他の回答：

教科書通りにはできないこともある(スキル、リソース、環境などの制約によって)ので応用力が必要
- 制約を考慮して実践可能な方法に仕上げるのも応用力ですし、教科書通りの基本からできるだけ外れないようにするのも応用力ですし、制約を取り払うことも応用力ですね。
- 応用方法を決めたら普及の方法も考える必要があります。ちょうど最近、普及の方法をメタに考えられるスライドが公開されましたのでリンクしておきます。https://speakerdeck.com/teyamagu/ideas-for-introducing-new-methods
現場固有のKnowHowやTipsがある
- 社内ライブラリ、社内ツール、ビルドとデプロイの手順、ネットワークの設定など、社内固有(さらには現場固有)のノウハウはよくありますね。それが一般的に良いノウハウなのか、ときどき再考することをすすめます。
委託、協力会社管理などのマネジメントスキルも必要
- CMMI と SPICE では協力会社に対するマネジメントも入っていたはずですが、解説書であってもそのノウハウまで書かれていたかというと覚えがありません。また、近年では内製化を推奨するムーブメントが続いているせいか、講師の周りでは聞かなくなった話題です。
技術や知識は常に進化するので勉強し続けなければならない
- 勉強の仕方というのも技術ですね。これもQ7-3の回答としてふさわしいと思えました。

全ての受講者は、工学分野としてのソフトウェアエンジニアリングよりも、実務者としてのソフトウェアエンジニアに求められる能力の方が広いことを示す何らかの回答ができていました。人間とコミュニケーションに着目した回答をした受講者が半数以上と最も多く、実体験から理解しているのかもしれません。逆に、ソフトウェアエンジニアリング以外のコンピューティング分野について回答した割合は1/3程度でした。「コンピューターサイエンスとの違い」というヒントをスライドに出していても1/3だったので、もしかすると違いのイメージを言葉にできるほど持っていなかったのかもしれません。分野とは多数の識者の持つ主観的な範囲なので厳密さはありません。あるトピックは何と呼ばれることが多くて、どの本棚・論文誌・カンファレンスで扱われることが多いという分布があるだけです。ですが、それを知っていると、自身と組織の強みと弱みがより明確に見え、望む知識にはどこで出会えるのか推測できるようになります。配布したスライドを見返し、参考資料を1つ開けばその意味がわかるのではないでしょうか。

総括

SQiPシンポジウムでは毎年多くのチュートリアルが開催されてきましたが、ソフトウェアエンジニアリングを正面から扱ったものは今回が初めてでしょう。初めてであるゆえに、企画が始まった4月にはコンセプトの議論をしていたのを覚えています。最初はソフトウェアエンジニアリング技術の組織標準に決定権を持つ職種を対象にするという野心的な案もあったのですが、それは初回にしてはあまりにも狭いだろうと考え直し、新人にとっては難しくシニアエンジニアにとっては7割既知くらいのレベルにしようとしました。7割というのは、本書の何章分を知っているといった量の意味でもあり、方法は経験的に知っているが文献は知らず、理由も明確にはわからないという質の意味でもあります。

受講者それぞれの回答を見ると、得意な分野と苦手な分野があること、深く考えようとしているか否かが読み取れます。答えられなかったQ、深く考えられなかったQについてはぜひ解説を読み直してほしいと思います。

回答には Google スプレッドシートを用いました。全ての受講者で1つのブックを共有し、1人の受講者に1つの回答シートを与えました。これにより、講師が受講者の回答をリアルタイムに見て反応するインタラクションを実現できました。ただ、中には Google スプレッドシートを利用できないネットワーク環境で受講している方もいましたので、その方々には同じ回答欄の Excel ファイルを配布しました。

講師としても反省するところが色々あると考えています。受講者がより深く多様な示唆を得るために、考えさせる問い方をし、回答時間を増やし、回答を共有する時間を設けても良かったように思えます。主たる参考文献とした実践ソフトウェアエンジニアリング第9版(本書)をどれだけ重視して問題と解説を作ったかは講師による差が出ていたように思えます。私はどちらかといえば本書の演習問題はチュートリアルには合わないと早々に判断して切り捨てたのですが、ほかの3人は違ったように思えます。個々の問題と解説は何かしらの示唆を与えられるものだと思いますが、Q1～Q7というセットがソフトウェアエンジニアリングという分野そのものを伝えるにふさわしいかというと、まだまだ詰められると思います。最初のコンセプトを実現できたのか、このコンセプトで良かったのかといった振り返りを講師陣でしたいところです。またの機会に向けて、洗練させてより学べるコンテンツを提供したいと思います。