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
    • ほとんどの受講者が不適切と回答していました。理由を以下に抜粋します。
      • 月1回のリリースは不要そう。。。
      • 根本部分の変更なので、少しずつリリースするというのは難しい。また、やるべきことがハッキリとしているので、前準備をしっかりとやるのが良い
      • 新規に盛り込む機能等があればわるくはないかもしれませんが、そうでなければ無駄が多いように思う。
      • しっかりアーキテクチャと機能を作りこんでいかないと、テストフェーズで破綻する
  • 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. 設計の意義

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シンポジウムのサイトから引用します。

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

この出題意図は、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というセットがソフトウェアエンジニアリングという分野そのものを伝えるにふさわしいかというと、まだまだ詰められると思います。最初のコンセプトを実現できたのか、このコンセプトで良かったのかといった振り返りを講師陣でしたいところです。またの機会に向けて、洗練させてより学べるコンテンツを提供したいと思います。

ISTQB CTFL-AT (Agile Tester) 受験記

まとめ

  • この文章は ISTQB CTFL-AT というアジャイル開発向けテスターの基礎を問う試験の受験記。日本語の情報が乏しいので書いた。
  • 英語なのはちょっとネックかもしれないけど簡単でしょと踏んだら案外苦労した。
  • PearsonVue で iSQI または Brightest を選択すると申込み可能。非英語ネイティブ向けに試験時間を延長できる制度があるが、試験申し込みとは別の申請が必要。
  • 実際の試験はシラバスと参考書の模擬試験よりも難しい。それが有用な難しさなのかは疑問。
  • 知識が得られたというよりは、理解が浅いことがわかった、疑問が増えたという方が近い。

⬛️ 背景

職務経歴書を書いているときに資格を追加したい気分になりました。「英語で試験を受けるなんて面白いかも?でも中身は簡単そうなのがいいな~…もちろん勉強になりそうなものを」という軽い動機で候補を考えたところ、以前に取得した JSTQB FL の延長線上にある ISTQB CTFL-AT という試験があることに気づき、受けることにしました。

CTFL-AT とは Certified Tester Foundation Level - Agile Tester を表し、基礎レベルのアジャイルソフトウェア開発向けテスターの資格を意味します。 私は特にアジャイルソフトウェア開発向けテスターを目指しているわけではありません。 ですが、この前提資格である CTFL を勉強したときに、それまでの歯抜けな知識が補完されたり、識者と話せるようになったり、実務にも役立ったという利点を実感したので、CTFL-AT についてもきっと良いものだろうと期待しました。 CTFL を前提とした試験は他にもありますが、それらの中ではアジャイルが一番長持ちする基礎になりそうで、英語での試験なので中身は簡単そうなものにしようと考えて選びました。

JSTQB が日本語の CTFL-AT 試験を提供していたら、学習はしても試験を受けはしなかったかもしれません。*1

⬛️ 試験提供の仕組みと申し込み方法

さて、ISTQB の試験を受けるべく ISTQB のサイトから申し込みの窓口を探したのですが、なかなかわかりませんでした。 また、非ネイティブ話者は試験時間を25%延長することができますが、この方法も少し手間がかかるものでした。申し込み方法を以下にまとめます。

  1. PearsonVUE の試験プログラムの選択欄で iSQI または Brightest を選択し、アカウントを作る
    • 私は iSQI を選択しました。どちらでもいいと思います。
  2. https://home.pearsonvue.com/isqi/contact にある iSQI Extra Time Request Form という PDF に、作ったアカウントのID、受ける試験、個人情報を記入する。
  3. 作った PDF を timeextension@isqi.org へ送ると iSQI から延長を認めた旨が返信される
  4. PearsonVUE 日本拠点のカスタマーサービス にある電話番号へ、試験時間を延長して受験したい旨とメールアドレスを連絡する。
  5. 連絡したメールアドレスに PearsonVUE 日本拠点のカスタマーサービスから、iSQI から試験時間延長が認められた証拠を提供するよう連絡が届く。そのメールに、iSQI から試験時間延長が認められたメールのスクリーンショットを添付する。
  6. そのスクリーンショットを PearsonVUE 日本拠点のカスタマーサービスが確認すると、希望試験日時と支払い方法などを聞かれる。答えれば予約完了。
  7. 予約完了がメールで通知される。

まず、ISTQB 自体が試験を提供しているわけではなく、ISTQB の策定した試験要綱に準拠した試験問題を作成している団体として iSQI や Brightest があるようです。 また、日本ではオンラインで試験を受けることになるので、PearsonVUE というオンラインの試験環境を提供している団体を介する必要があります。 そして、実際に試験を受ける場所は日本各地にある試験施設であり、PearsonVUE と連携しているようです。

たぶん各団体には、ISTQB(試験要綱策定)→iSQIなど(試験問題作成)→PearsonVUE(オンライン試験予約と試験実施環境の提供)→試験施設(試験会場の提供)、という関係があるのだと思いますがはっきりはわかりません。

試験時間を延長するには上記のように面倒な手続きをこなす必要があります。 ですが、本番の試験は模擬試験より難しかったので、延長しておいて良かったと実感しています。 試験時間を延長しない場合は、電話やメールをせずとも PearsonVUE のサイトで予約できます。 予約の途中で試験会場と空き日時を確認できる画面があります。 延長する場合でも、この画面で希望する会場と日時を確認してから PearsonVUE のカスタマーサービスへ電話するのがよいでしょう。

⬛️ 学習方法

試験の学習には、合格するための学習と、活かせる知識を得るための学習があり、両者は重なるところも異なるところもあると捉えています。 ここに示すものはどちらかといえば合格するための学習であることにご注意ください。

使った学習材料は次の通りです。

学習のプロセスは次の通りです。

  • シラバスの日本語版を、学習目的と用語を把握できる程度に荒く読む。
  • 日本語版で把握した学習目的と用語が、英語版でどのように表現されているか確かめる程度に荒く読む。以降は英語版を使う。
  • シラバスで把握した学習目的と用語が公式模擬試験の問題にどのように登場するか確かめる。解かなくてもよい。
  • シラバスにある馴染みのない概念の記述を Agile Testing Foundations と Agile Testing with Lisa Crispin と Agile Testing Condensed Japanese Edition から探し、熟読して理解する。特に、図や例による解説を重視する。章末のサンプル問題も解く。
  • 馴染みのない概念がシラバスでどう解説されているか確かめるために熟読する。
  • 既知の概念がシラバスでどう解説されているか確かめるために熟読する。疑問があれば Agile Testing Foundations と Agile Testing with Lisa Crispin と Agile Testing Condensed Japanese Edition も併用する。
  • 公式模擬試験と Agile Testing Foundations にある模擬試験を解く。誤った問題はもちろん、正答した問題についても各選択肢の解説と自分の考えを比較する。
  • シラバスの学習目的に対して自分で説明できるか確かめる。
  • シラバスを熟読する。

合格を第一に考えるなら演習問題をこなすことが必要と考えて問題を探しました。 しかし、公式模擬試験をコピーしただけの粗悪な mock exam がいくつも出てきたので、結局は公式模擬試験と Agile Testing Foundations の問題のみ解きました。

⬛️ 試験の難しさ

公式模擬試験と Agile Testing Foundations の模擬試験では9割正答できましたが、本番では7割でした。 問題そのものが難しかったように思えます。 理解を問うための適切な難しさを感じられる問題もありますが、どちらかといえば誤答させるためにひねっている印象でした。 学習者の理解向上のために有用な難しさなのかは疑問が残ります。

実際の問題は紹介できませんので、問題を難しくする要素という抽象化した形で以下にまとめます。 例は私が考えたもので、出題されたものではありません。

  • どの選択肢も誤りではないが、最も適切なものを選ぶ必要がある
    • 例: Which of the following statements best reflects the Agile software development approach?
      • a) A set of practices including iterative process, automated testing and kanban board.
      • b) A collaborative and progressive approach performed by software engineers and business representatives focusing on delivering value to customers.
    • a) は誤りではありませんが b) の方がよりアジャイルソフトウェア開発を表しています。
    • 実際には4つ以上の選択肢があり、全ての選択肢を読んで比較する必要があります。
    • best reflects の類似形として most likely もあります。その反対として least likely もあります。もちろん not true もあります。true の選択肢を選べという素直な問題の方が少ない印象でした。
  • シラバスにおける複数の節と学習目的が混合されている
    • 例:
      • アジャイルテストの4象限と探索的テストの混合問題
      • ふりかえりの内容からシラバスにある有効なプラクティスを選択する問題
      • プランニングポーカーにチーム外の独立テスターが例外的に参加しており、チーム内のテスターと大きく異なる見積もりをした状況を設定し、独立テスターの有効性を正しく説明した文を選択する問題
    • シラバスには学習目的ごとに FA-1.2.3 といった番号が付与されており、だいたいは1問につき1つの学習目的が対応するように思えますが、複数の学習目的が対応するように見える問題もありました。
  • シラバスを逸脱した知識領域が問題文で解説され、シラバス範囲内の知識領域と混合されている
    • 例:
      • 問題文で累積フロー図(cumulative flow diagram)を説明し、バーンダウンチャートと合わせた問題
      • 問題文でキーワード駆動テスト(keyword driven testing)を説明し、アジャイルテストの4象限と合わせた問題
    • 結局はシラバスの範囲内の知識で正答できるように作られているはずですが、迷うものがありました。
  • うまくいっていない状況、またはシラバスで説明されたセオリーから外れた状況が提示される
    • 例:
      • POが不在のままプランニングポーカーを繰り返す
      • プランニングポーカーにおいてチームメンバーごとの見積もりの差は少ないが、ストーリーに関するタスクを終えられずにイテレーション終了を迎えることが何回もある
      • テスター不在のアジャイルチームが受け入れ基準を明確にできなかった結果、顧客から多くのバグを指摘される
      • 自動テストの結果が偽であることが増えたため、POが自動テストに疑いを持ち始めている
      • リスク分析の結果、何のリスクも見いだせなかった
    • 考えさせる良い題材と思えるものもあれば、本当に1つの正答があるのか疑わしいものがありました。
  • CTFLシラバスの内容も要求される
    • 例:
      • 振り返り会にて、あなた(テスター)以外のメンバーは、以前あなたが教えたアジャイルテストの4象限をもとに、最近よく見つかっている欠陥を効率的に発見するためのテスト強化策を考えている。それらの欠陥は、曖昧なユーザーストーリー、コンポーネント間インターフェースの不整合が多くを占めることがわかっている。あなたがテスターとしてこの状況を踏まえた提言をするとき、最初に提言することが適切なものを選べ。
        • a) Q2 に相当する自動の機能テストと統合テストの強化を提言する
        • b) Q3 に相当する受け入れテストの強化を提言する
        • c) Q4 に相当する性能テストの強化を提言する
        • d) アジャイルテストの4象限は動的テストのみ扱うことと、それらの欠陥は静的テストでの検出が向いていることを提言する。
    • この例は、CTFLシラバスに記載されている静的テストの方が検出しやすい欠陥と、アジャイルテストの4象限は動的テストのみ扱うことを合わせた問題で、正答は d) です。
    • 公式模擬試験にはCTFLで扱われるテスト技法を選択させる問題があります。ほか、テストの7原則とテストプロセスも CTFL-AT の内容と合わせて問われうると考えています。
  • 正答を左右する表現
    • 例:
      • "Test automation reduce regression risk." であれば正しく、"Test automation eliminate regression risk." であれば誤り。この例が参考書にあれば、「自動テストは回帰リスクを軽減できても排除できない」と解説されるでしょう。
      • "Testers are generally not involved in writing unit tests." であれば正しく、"Testers must not be involved in writing unit tests." であれば誤り。この例が参考書にあれば、「アジャイルはチーム全体アプローチであり、テスターと開発者がペアを組んでユニットテストを書くことはありうる。」と解説されるでしょう。
  • 出題されやすい題材のアプリ
    • 銀行、保険、小売、飛行機やホテルの予約に関する Web アプリがほとんどに見えます。
    • アプリが決まっていると、おのずと題材になりやすい機能も決まっているように見えます(例: アカウントの作成、アカウントの無効化、入出金のトランザクション、割引の条件、カートの上限、購入履歴の閲覧、予約のキャンセル、支払い方法やお気に入り品などのアカウントごとの情報保存)
    • なので、それらの題材に関連する語彙を知っておいたほうがよいでしょう (例: deposit, withdraw, bank teller, voucher, retail)
  • やや難しい単語
    • 例えば、公式模擬試験には In an agile project, which of the following would best denote product quality at the end of iteration 6 of a new system release consisting of 8 iterations? という問題文があります。ここに出てくる denote という単語がわからなかったので正答できませんでした。represent が使われていたら正答できたかもしれません。Weblio によると denote は英検準1級の単語だそうです。
    • 模擬試験でも実際の問題でも、1,2問は回答を左右する未知の単語が出てくるように感じました。
    • シラバスと参考書に出てくる未知の単語は覚えておくのがよいと思います。

⬛️ 役立つ知識が得られたのか

受かりはしましたが、果たして役立つ知識が得られたのかを改めて考えてみました。 ここだけ深掘りすると何本も書けそうなのですが、今回は印象論にとどめておきます。 総じて、知識が得られたというよりは、理解が浅いことがわかった、疑問が増えたといった方が近いように思えます。

  • アジャイルアプローチにおけるテストの方法を短くまとめた国際的な文書が手に入りやすいことは価値があると思います。だったら Agile Testing Condensed の方が解説があって良いじゃないの?とも思えるけど、問題で理解を確かめられる点は ISTQB に分があるとも考えられます。
  • テストに焦点を当てる場合でも whole team approach と early and frequent feedback が中核なのだろうと思います。
  • テスト担当者の役割に多くの記述を割いているので、役割分担の材料になると思います。
  • CTFL-AT に限った話ではないんですけど business representatives って具体例が浮かばないんですよね。プロダクトマネージャーか商品企画者ならわかるので、いつもそう置き換えています。特定企業向けソフトウェアの開発なら、その企業のビジネス代表者が出てくるのではないかと想像できますが、そういう開発をやったことがないのであくまで想像です。power of three の原典を読むと理解が進むかもしれません。
  • これはそもそも CTFL からそうなんですが、独立したテスト担当者であるからこそ効果的な欠陥検出ができるっていうのに納得していないんですよね。なので、CTFL-AT にある独立性の選択肢の部分について、選択肢があることは理解できますがそれぞれ固有の効果があることは理解できていません。
  • リリース計画は最初期に立てる、という説明しかなく、リリース計画を繰り返したり見直すことの説明がありません。新規開発のせいぜい半年くらいしか想定しておらず、何年も継続的にプロダクトを育てる視点で書いていないのではないか?と疑いました。
  • 継続性についてはもう1つ気になることがシラバスに書いてあります。
    • 2.2.2 テスト担当者は各イテレーションで、以前および現在のイテレーションの手動テストケースおよび自動テストケースをレビューし、回帰テストスイート用の候補を選択し、関連性のなくなったテストケースを削除する時間を確保する必要がある。
    • 3.1.4 デリバリー済みの機能と特性についての継続的なテスト戦略を可能とするには、根底にある機能とフィーチャの間のすべての依存関係を識別することが重要である。
    • 確かにイテレーティブな活動を継続するにはこれらは重要なんですけど、難しいことに思えます。より上級の試験範囲に入ってるんでしょうか。
  • 選択問題では「testable なユーザーストーリーはこれ」と選べました。でも実際は testable かどうかって、ある文章が論理的か?と同じように主観的なもので、チームのプロダクトに対する理解によって何かテスト条件を省略しても testable と思えるか、あるいは詳細に書き下すかが異なってくるものではないでしょうか。
  • うまくいっていない状況への対処を考えさせる問題は応用力がつきそうです。試験対策の問題集だけでなく、そういった問題集があれば実務者に役立つと思います。
  • ATDD は全く経験がなく BDD も個人で動かして「動いた!ふーん…」で終わったので、気が向いたら他の解説を読んでみようと思います。
  • テストピラミッドって言葉と図を作ってまで言う価値があることなのか、さっぱり理解できませんでした。これも原典を読めばわかるのかもしれません。
  • 4象限は最初のうちは雑に見えたのですが良さそうに思えました。未熟なうちはどこかの象限がぽっかり空いたり、Q2とQ3の区別がつかないのではないでしょうか。そして成熟してどこも埋まるようになっても、今のイテレーションで注力することのベースとして4象限は使い続けられると思います。ただし、Q1が左下で右回りなのは誤解を生むと思います。なんで数学の座標平面と違って右上から左回りじゃないんでしょうね。
  • 英語で勉強して英語の試験を受けると英語の能力が伸びるかというと、実感はありません。単純に実感を伴うほどの量に足りないからだと思います。きっとこの小さな努力の10倍を積むとちょっと実感できそうです。

8年前に CTFL を学習したときは「最初のうちは盲信してもいい」といえるほどの基礎知識が得られた覚えがあります。しかし CTFL-AT についても同じかというとそうではありません。CTFL を勉強したときは今よりも知識がなかったから盲信してもいいと思えて、今は疑問を持てるだけの知識がついたから盲信してもよいと思えなくなったのかもしれません。 …と、さくっと書くつもりが長文になって疲れたので自分を褒めて終わります。

*1:ISTQB(International Software Testing Qualifications Board) とはソフトウェアテストの国際資格組織であり、いくつかのレベルと種類に分けられた複数の資格試験を提供しています。ISTQB は各国のソフトウェアテスト資格認定団体と相互認証する制度を設けており、日本には JSTQB という International が Japan になった名前の団体があります。相互認証によって、JSTQB の日本語による試験に合格して得た資格は ISTQB の該当する資格に相当することを意味します。JSTQB は ISTQB の扱う試験を一部を提供しています。CTFL-AT の試験要綱(シラバス)は提供されていますが、試験自体は実施されていません。

家庭菜園 2021年度総括

貸し菜園(30m2)、実家の庭の一部(たぶん合計10m2)で行った2021年度の栽培結果を記録します。 区切りを年度にした理由は3月に冬野菜の収穫が終わるからです。12月に植えて5月に収穫するたまねぎのように年度をまたぐものもありますが、どちらかといえばきりの良い区切りは年度だと考えました。 栽培地域は静岡県沼津市です。年間平均気温は16~17度で暖地に分類されます。冬でも氷点下になることは少なく、雪も霜もほぼありません。

2021年度に栽培した品種、収穫した野菜の味、栽培方法、虫対策、日当たり、作業頻度、天候、夏冬品種の移行、栽培記録方法という項目別にまとめると以下の通りです。

  • 品種
    • トマト、キュウリ、ナス、大根、ブロッコリー、白菜といった定番や、さとうきび、バナナといった変わり種を含めて30種ほど育てました。順調に育ったもの、期待以上に育ったもの、ろくに実らなかったもの、収穫前に枯れてしまったもの、発芽すらしなかったものなど、品目よって結果は様々です。体感的な収量としては、毎日何かしら採れたものを食べられる程度には収穫できました。特に夏季は野菜を買わなくてもよいと思えるほどです。ただ、夏以外でそれほどの収量を得るには、計画的な種まきと苗作りと撤収、そしてさらなる面積が必要だと感じました。
    • 自分で作ったからおいしいという思い入れ補正を除けば、売ってるものよりおいしいということはありません。だいたい一緒か、それ未満です。プロが栽培、流通、保存、小売した野菜を素人の新鮮野菜が上回ることはないと実感しました。
  • 栽培方法
    • 栽培の起点は様々で、購入した苗、購入した種、前年に採取した種、購入した野菜のクズから再生した苗、購入した野菜に入っている種という場合があります。苗半作という言葉の通り、苗作りは手間がかかりますし、なかなか狙った定植時期までに育ってくれません。スーパーで買った野菜をもとに育てるのは楽しいですね。ねぎ、小松菜、チンゲン菜はお手軽です。トマトとカボチャも種から簡単に発芽します。
    • 育成方法は、ビニールマルチなし、堆肥や石灰などの土づくり材料購入なし、除草は野菜が埋もれない程度という、どちらかといえば慣行農法よりも自然農法に近い方法をとりました。化学肥料と農薬は時折使っていますので、自然農法というわけではないという程度のバランスです。多少の雑草があっても土作りの材料を購入しなくても旺盛に育つことは、2020年の経験と見てきた動画でわかっていたのでそうしました。実際やってみてまぁまぁ目論見通りでしたが、菜園ではオヒシバとメヒシバが地面を覆い尽くすほど盛んで、野菜が埋もれない程度にするための除草ですら疲れました。
  • 株間
    • 詰め込みすぎ。何の品目がどれだけ成長するかを考慮して株間を決める必要があることがよくわかりました。というと当たり前ですが、調べずに植えたので損しました。
  • 虫対策
    • 虫とは必ず対峙することになります。1番は夏の蚊対策です。対策なしだと3分で10箇所刺されます。暑くても長袖と帽子が必要です。あまりにうるさいのでヤブ蚊バリアというスプレーを使ったところ、とても役立ちました。作業前にまいておくとその場所では刺されません。試しに半袖で30分作業しても全く刺されませんでした。3ヶ月で1本半使用。食害を受けた時期は意外にも虫の少ない冬で、ブロッコリーロマネスコ芽キャベツが半分くらいボロボロになりました。姿は確認できなかったのですが、荒らされ方と糞からしてヨトウムシだと思います。ほか、夏秋にウリハムシをよく見かけ、きゅうりとかぼちゃの葉にはいつも穴があいていました。
  • 日当たり
    • 庭でも貸し農園でも日当たりの良いところと悪いところがあります。日当たりの悪いところでは何をやってもだめでした。例外は半日陰を好むあしたばくらいのもの。
  • 作業頻度
    • 作業頻度も季節によって全く違いました。夏は最低でも3日に1度は行かないと収穫適期を逃したり雑草が茂ります。そこから気温が下がって冬になると野菜も雑草も育つのが遅くなるので1週間放置だとかざらでした。
  • 天候
    • 8月の大雨により順調だった夏野菜が一気に被害を受けました。きゅうりとかぼちゃが枯れ、トマトは枯れこそしないものの実が全滅。オクラとナスは無事でした。雨を直接防ぐ手段はわかりません。できることといえば、秋植えの苗を準備しておき被害が大きければ入れ替えることくらいでしょうか。https://ja.wikipedia.org/wiki/%E4%BB%A4%E5%92%8C3%E5%B9%B48%E6%9C%88%E3%81%AE%E5%A4%A7%E9%9B%A8
  • 夏冬品種の移行
    • 冬野菜は12月中に収穫できることを見越して種まきや定植をすることが理想です。1月と2月は成長が急に遅くなるからです。ということを事前に学んでいたのですが、半分ほどは定植が遅れて収穫ができなかったことにより実感してしまいました。 9月下旬になったら、まだ収穫可能な夏野菜であっても片付けて移行すれば良かったと思いました。
  • 栽培記録方法
    • こういう総括をするためには記録が不可欠です。品目と収量をGoogle Sheetsに記録し、画像をGoogle Photoに、Twitterにメモを残しました。Google PhotoとTwitterには家庭菜園以外の情報もあるので、家庭菜園の情報を探すには品目名を検索キーワードに指定したり、目視で文章や画像を判断する必要があります。また、必ずしも全ての品目の栽培過程を記録しているわけではなく、記憶に頼っています。より適切に効率良く振り返るには、振り返りに適した情報の形と、日々の作業過程を残せる習慣と仕組みが必要と考えました。

全体としてはそんなところです。 2022年度の今はレイズドベッドを使ったより広い面積での栽培をしているので、雑草と害虫については顕著な改善を見込んでいます。 また、土壌と気候の流れを把握した上で、品目を計画的に扱うことは、どこでやっても同じことであり、今年は季節の変わり目を重視して移行に思い切りをつけることにします。 そして、土地を手に入れたので果樹の栽培に着手します。

以下、野菜別に概ね春から栽培した順に、文章のみで画像は使わず端的に書きます。 発芽しなかったり収穫できずに枯れたりといった失敗とみなした野菜も含めます。

ナス

  • 結果
    • 黒陽1株、千両二号4株の苗を4月下旬に定植。どちらも購入した自根苗。11月まで43本収穫。
    • 黒陽の方が草丈、葉の枚数、葉の大きさ、果実の大きさ、収量ともに良し。
    • 千両二号に食害と半身萎凋病は見られなかった。単純に成長が遅い。葉の色は少々紫がかった良い色だが小さい。
  • 感想
    • 1株20本を見込んでいたが少ない結果になった。黒陽と千両二号の結果の違いとして大きい要因と考えられるものは場所。黒陽は庭で千両は貸し菜園。土だろうか?虫に根をかじられたのかもしれない。
  • 次年度の方針
    • 黒陽と千両二号をできるだけ同じ条件で栽培する。

トマト

  • 結果
    • 中玉の凛々子を4株、ミニトマト4株を5月上旬と9月に定植。加えて、庭に生えてきたミニトマト1株。12月下旬に枯れるまで、中玉65個、ミニ500個以上を収穫。凛々子の苗は購入品。ミニは買った実にある種を育てたもの。
    • 8月に1週間続いた大雨で実が全て落ちる割れるなどの被害を受け全滅。株は無事。
  • 感想
    • 大雨が無ければ収量は倍だったのではないか?痛い
    • 凛々子は背が低く誘引の手間がミニより少ない。「世話のいらない」と銘打たれているだけある。果実同士が密接すると腐りやすいので摘果するのがよい。
    • 庭に生えてきたミニトマトが一番元気。2020年に育てたミニトマトの子である。
    • もっとたくさんの苗をストックしていたが、植える場所がなかった。
    • 誘引が必要になる前に支柱を骨組みになるように作っておく必要がある。猛暑のなか骨組みを作るのはつらい。
    • 収量が少なかった株がいくつかある。日照時間がやや短い場所に植えたからに思える。
    • 株間30cmにしたが他の区画のミニトマトと比べて狭かったように思える。50cmでいいかも。
    • 小学生でも育てられる手軽な野菜というイメージのあるミニトマトだが、手間を抑えてきれいなものをたくさん収穫するにはこまめな工夫が必要。あるいは完全放置できるような骨組みを作る手はありそう。1人で何株もこまめに誘引したり芽かきをするのはつらい。
    • 10月から12月も収穫可能だが遅くなる。収穫までの積算温度が900という通説は納得できる。
  • 次年度の方針
    • トマト用レイズドベッドでは6月中に骨組みを完成させる
    • 大玉トマトに挑戦

オクラ

  • 結果
    • 購入苗3株を7月中旬に定植。11月に枯れるまで81本収穫。
  • 感想
    • 簡単。支柱はなくてもよいし必要だとしても1本でよい。収穫時期はすぐに大きく固くなるので可能なら毎日みるのがよい。
    • まだまだ収穫できそうなのに3株とも急に元気がなくなって枯れた。葉からは病気らしい兆候がみられない。気温はまだ問題なさそうなので虫による根への攻撃だろうか。
  • 次年度の方針
    • 同じように栽培する。ただ、レイズドベッドなので低めにする。定植は4月5月でもよい。

キュウリ

  • 結果
    • 購入した接木苗2株を5月中旬に定植。8月下旬に枯れるまで38本収穫。
  • 感想
    • 初めての接木苗。2020年に育てた自根苗は途中でうどんこ病になって枯れたが、この苗は2株どちらもうどんこ病にならなかった。接木苗だからなのか。
    • すぐ大きくなる。何本か40cmを超えた。それでも食べられる。見栄えが良いのが欲しいなら収穫時期は毎日通う必要がある。というのはオクラと一緒だが、3日放置しても食べられるのが違うところ。
    • 38本のうち半分以上はお化けきゅうりと言われるような大きいものにした。売ってるものと違う姿に育てるのが楽しい。
    • 8月の大雨の直後に枯れた
  • 次年度の方針
    • 自根苗と接木苗どちらも育てる。たぶん2株。3株かも。

カボチャ

  • 結果
    • スーパーで買ったニュージーランド産かぼちゃに入っていた種から苗を4株つくり、6月上旬に定植。8月の大雨の後、実が1個を除いて全滅。その1個のみ収穫。
  • 感想
    • 虫まかせではなかなか受粉しないようで、雌花の元にある実のほとんどは大きくならなかった。人工授粉を試みたが実感できる成果なし。朝に受粉させることをすすめる情報が多かったが、実際に受粉させたのはいずれも午後だったのが原因かもしれない。朝に受粉させるためには起きてすぐ畑という立地でないとつらい。
    • 唯一収穫できた1個は見かけこそ立派だったものの味が薄く硬かった。追熟が必要なことは知っていて1週間置いたのだけど短かったのだろう。
    • どんどんのびて場所をとるのはトマト、きゅうりと一緒だが、支柱を組むなら重い実を支える工夫が必要。きゅうりと同じ支柱だと強度が足りない。いっそ地這いさせられる面積があれば楽そう。
  • 次年度の方針
    • 同じくスーパーで買ったかぼちゃから苗を作る。空中栽培と地這いの両方を試す。朝に受粉させる。

トウモロコシ

  • 結果
    • ピーターコーン、赤白、七色を計40株ほど種から育成。第一陣は5月中旬に定植したがまともなものは1本も収穫できず。第二陣を8月下旬に定植し20本ほど収穫。アワノメイガほか虫による食害なし。いずれも売り物より小さい。
  • 感想
    • 第一陣は場所が悪かったのではないか。菜園の中でも日照時間が比較的短い場所。雄穂を切る時期が早く切りすぎた一方で受粉させる時期は遅かったかも(花粉が飛んでいるのが見えない)。
    • 第二陣は日当たりの良い場所にした。秋に収穫する方法はアワノメイガを避けられた。あとは量と味の問題。1株1本に絞るのが良いかもしれない。
    • 振り返ってみると、日照も1本に絞るのも受粉も基本の栽培方法に従っていない。3割食害されるが7割はおいしいものがとれる程度の結果が家庭菜園レベルで基本的な栽培をしたときの結果に思える。
  • 次年度の方針
    • 基本の栽培方法に従う

ジャガイモ

  • 結果
    • 余りものの芋を何個か土に埋め、芽かきで2本に絞ったあと放置。30個ほど収穫したがいずれもピンポン玉程度。
  • 感想
    • 大して力を入れなかった。いつ育てたかも記録していない。成功例はいずれも耕していて複数の材料を土に混ぜている。無肥料で耕さず放置だとこんなもんなのかも。
  • 次年度の方針
    • やらないかも。同じいもならサツマイモを優先。

葉ねぎ

  • 結果
    • スーパーで買った根つきの葉ねぎの根を植えて放置。40本くらい?時期はいつでも。収穫もいつでも。
  • 感想
    • 簡単。年中どこでも育つ。世話もいらない。余った場所に植えておくとよい。
  • 次年度の方針
    • 同じく努力せずに栽培する

パクチー

  • 結果
    • 2020年度に自家採取した種から1株だけ栽培。小売されている3パック分ほどを収穫後、近くの雑草と栽培品種に紛れて姿を消した。
  • 感想
    • 植えた場所の日当たりが悪く、近くの冬瓜が旺盛に育ったせいか、いつのまにか消えてしまった。栽培していることをいつしか忘れていた。
  • 次年度の方針
    • 2株以上、まともに栽培する。

マクワウリ

  • 結果
    • 購入苗1株を栽培。18cmの果実を2個収穫。長雨の後枯れた。
  • 感想
    • 物珍しさに栽培した。味はメロンの方がよいという事前情報はそのとおりだった。
  • 次年度の方針
    • やらない。ずっとやらないかも。

サトウキビ

  • 結果
    • 購入苗8株を5月に定植。11月から12月にかけて一部を収穫。以降も味見しながら栽培を継続したが、甘みが酸味に変化していることから3月に栽培を断念。
  • 感想
    • 冗談のつもりで栽培したが冬まではうまくいっていたように思える。越冬できずに枯れ、酵母菌が糖を酸に変えてしまったのではないか。そもそも サトウキビは、12ヶ月から18ヶ月で生長し、気温が下がる冬に完熟します https://www.shinko-sugar.co.jp/process02.html とある。暖地とはいえ本州で栽培するには下調べが足りていない。
  • 次年度の方針
    • やらない。そのうち再挑戦したい。

紫ニンジン

  • 結果
    • 種を5月末と8月にまいた。どちらも発芽率は5割以上。5月にまいたものは枯れてしまった。8月にまいたものを2月~3月にかけて5本収穫。
  • 感想
    • 何も世話をしていなかったのでこんなもんかもしれない。難しいと言われている発芽は突破できた。残る課題は土作りと世話だろうか。
  • 次年度の方針
    • 余っている種を慣行農法で栽培する

明日葉

  • 結果
    • 2020年に植えた株Aに加え、新たに3株B,C,Dを6月に植えた。A株から小売10パック以上の量を収穫。Bからも小売2パック分を収穫。C,Dからは収穫なし。
  • 感想
    • Aは2020年8月に食害によって葉が一枚もない状態に追い込まれたが現在は最も旺盛に育っている。
    • 苗を植えた年には収穫できず、翌年から安定した収穫ができる。「明日また生えてくる」と思えるには、Aほど育った株が何株か必要ではないか。
  • 次年度の方針
    • 今の株をそのまま育てて収穫する

モロヘイヤ

  • 結果
    • 購入苗2株を6月に定植。場所はミニトマトの隣。10月に処分するまで、ゴミ袋をいくつか満杯になる量を収穫。
  • 感想
    • 何も世話をしていなかったが、想像の2倍大きくなり、想像の10倍収穫できた。近くに植えたバジルは死んだのに。強すぎる。
  • 次年度の方針
    • 未定

バジル

  • 結果
    • 購入苗2株を6月に定植。場所はミニトマトの隣。いつしか枯れた。
  • 感想
    • トマトのコンパニオンプランツとして有名であり、栽培も簡単と踏んで放置していたら消えてしまった。雑草に負けてしまったのかもしれない。
  • 次年度の方針
    • トマトのレイズドベッドで2株以上栽培する

枝豆

  • 結果
    • 購入苗1株を5月に定植。小売1パック程度を収穫。冬瓜に覆われ、いつしか消えた。
  • 感想
    • 場所が悪い。詰め込みすぎた。
  • 次年度の方針
    • 枝豆用のレイズドベッドで2株以上栽培する

ピーマン

  • 結果
    • 購入苗2株を5月に定植。9月に処分するまで70個収穫。
  • 感想
    • 無肥料の割にはいい方?味はいまいち。
  • 次年度の方針
    • 未定。場所があればやる。

万願寺とうがらし

  • 結果
    • 購入苗2株を5月に定植。9月に処分するまで102個収穫。
  • 感想
    • 数も大きさも味もいい。
  • 次年度の方針
    • ピーマン類用のレイズドベッドで2株以上

とうがらし

  • 結果
    • 購入苗2株を5月に、自家採種から育てた苗2株を6月に定植。200本以上収穫(途中で数えるのをやめた)。
  • 感想
    • これもそうだがピーマン類は放置で簡単に育つ。香味油、醤油漬けとして楽しめた。
  • 次年度の方針
    • 2株以上。キムチに使える辛みの少ない品種を育てる。

ししとう

  • 結果
    • 購入苗2株を5月に定植。9月に処分するまで238個収穫。
  • 感想
    • よく食べた思い出。調理はヘタを切るだけなので簡単。辛い果実の割合は5%未満に感じる。
  • 次年度の方針
    • ピーマン類用のレイズドベッドで2株以上

紫とうがらし

  • 結果
    • 購入苗3株を7月から鉢で育成。わずか2ヶ月で枯れた。
  • 感想
    • せっかくの頂き物だが早々と枯れてしまった。他のピーマン類と同じ場所に植えていれば豊作だったのではないか。土は買った培養土なので原因とは考えにくい。鉢の置いてあった場所からすると潮風だろうか。
  • 次年度の方針
    • 未定

落花生

  • 結果
    • 購入苗2株を5月に、頂き物の苗3株を7月に定植。1株は近くのサツマイモに覆われた後に枯れた。収量は合わせて小売4パックほど。
  • 感想
    • サツマイモの近くに植えたのが間違い。
    • 掘って、洗って、取り出して…と食べるまでの労力に対する量が少ない。要はめんどい。同じ豆なら枝豆の方が簡単。
  • 次年度の方針
    • なし。枝豆を優先。

サツマイモ

  • 結果
    • 購入苗4株を5月に、自前苗1株を6月に定植。8月、9月にツル返しが必要なほど大きく育ち、隣の隣の野菜に届いてしまったのでツル返しではなくツル切り。10月と11月に収穫。合わせた収量は、本数として15本、重さとして5Kg以上。収量の良い2株からは1株あたり2Kg以上収穫できた。
  • 感想
    • 夏野菜に比べると収穫までに時間がかかるが、世話いらずで収量も多く味も良い。
    • 株あたり収量の差は多分日当たり。ツル返し、ツル切りはどの株でも同じようにやっていたので。
  • 次年度の方針
    • サツマイモ用レイズドベッドを2つ以上作って6株以上栽培する

シソ

  • 結果
    • 貸し菜園に自生しているものをゴミ袋数袋分収穫
  • 感想
    • 前の借り主が育てていた株のこぼれ種が発芽したのだと思う
    • 茂り方が雑草レベル
    • 好きだけど主菜にはならないので食べきれない。しそジュースを試したけど砂糖が多すぎてたくさん飲みたくない。レンジで殺菌殺虫してからスムージーにするのはありかもしれない。
  • 次年度の方針
    • なし

パセリ

  • 結果
    • 購入苗1株を5月に定植。8月にサツマイモと冬瓜が覆いかぶさり、いつしか消えた。
  • 感想
    • さすがのパセリも覆われるとだめらしい。これも詰め込みすぎによる失敗。
  • 次年度の方針
    • 未定。1株くらい日当たりのいいところに適当に植えるかも。

冬瓜

  • 結果
    • 購入苗1株を5月に定植。隣の柿の木に絡みつきながら成長し、草丈としては2021年度最長で推定5m。12月に枯れるまで31個を収穫。根に近い茎の太さは直径4cm。
  • 感想
    • 2021年度MVP。10-12月はほぼ毎日冬瓜を食べており、消費し切れずストックが増していった。1玉あたりの大きさも1.5Kg以上。買うと1玉1500~2000円なので5万円分は食べたことになる。
    • 木に絡みついたのが大きい。柿は貸し菜園の区画外だから処分される可能性があったのだけど大丈夫だった。
  • 次年度の方針
    • 未定だけど1株は育てたい。絡みつく木がないので代わりになる骨組みを設ける。

ゴーヤー

  • 結果
    • 購入苗1株を5月に定植。場所は冬瓜の隣。冬瓜と絡み合うように成長するが、冬瓜より草丈は短い。12月に枯れるまで7個を収穫。
  • 感想
    • ツル性の野菜を並べたら絡み合って面白そうという理由で冬瓜と並べたら冬瓜が勝った。こんな好奇心のためにまともに育てられずすまん。
  • 次年度の方針
    • 未定だけど2株をまともに育てたい

ミョウガ

  • 結果
    • 庭に自生しているもの。8月から10月まで80個以上収穫。
  • 感想
    • 育てたものではないのでここに含めるか考えたけど採れたことを重視して載せた。
    • いつもは家族が戯れに採っているのだけど自分も手伝ったので例年より多く収穫。薬味、汁の具、漬物としてうまい。
  • 次年度の方針
    • おなじ

バナナ

  • 結果
    • 6月、耐寒性のドワーフナムワと間違えてドワーフモンキー2株の貸し菜園、自宅庭それぞれに定植。10月に草丈が1mを超えた。12月に地上部が枯れた。春に再生することを期待したが、3月に根も枯れていることを確認。
  • 感想
    • 品種を間違えたのが敗因としか言いようがない。夏秋にかけての成長速度はとても早い。耐寒性品種も同じ速度ならば1年で人の背を超すのではないだろうか。
  • 次年度の方針
    • 耐寒性の品種を2株以上植える

ビーツ

  • 結果
    • 6月から9月にかけて15粒以上の種をまいた。収量は2玉。ほかは雑草に負けて消えた。
  • 感想
    • 発芽率は100%近く、草丈10cmまでは順調だったが7月8月の雑草に埋もれてしまった。長雨で腐った可能性もあるが確認できていない。
    • 収穫できた2玉も売り物より小さい。平均的な野菜より多くの肥料を必要とするのかもしれない。
  • 次年度の方針
    • 20玉以上を目指し、市販の培養土または同等の肥料を含む土で栽培する

フォックスフェイス

  • 結果
    • 果実を食べられないとは知らずに買った苗1株を5月に定植。草丈は1.3mになったが実った果実は3個。
  • 感想
    • 食べられないとは知らずに植えたのがだめ
  • 次年度の方針
    • なし

小松菜

  • 結果
    • 5-6月にかけて生ゴミとなるヘタを10株定植し、1ヶ月後に5株収穫。残り5株は虫の食害により収穫を断念。
    • 11月に前年の自家採種をまき、4株を栽培。2月~3月にかけて株を維持しながら葉のみを収穫し、3月下旬から4月はトウ立ちした芽を収穫した。
  • 感想
    • とても簡単に育ち収量も味も良く調理しやすい。売っている小松菜の捨てられる部分から簡単に苗を作ることもできる。
    • とはいえ、虫の多い時期にノーガードで育てることは無理。不織布でトンネルを作っても突き破ってきそう。レイズドベッドならどうなるか試す価値はある。
    • トウ立ちした芽の天ぷらは最高。株を維持しながら葉のみを収穫したのは正解。
    • 素人の強い味方でありレギュラーメンバーといってもよい
  • 次年度の方針
    • 通年、レイズドベッドで育てる。夏にどうなるか着目。

白菜

  • 結果
    • 購入苗3株を10月上旬に、もう3株を10月末に定植。前者3株のうち1株が3月に結球し、2株はトウ立ち。後者3株は草丈10cm程度で成長が止まった。
  • 感想
    • 暖地での冬野菜とはいえ定植時期は10月上旬がギリギリなのだろう
    • 小松菜と同じく、トウ立ちした芽はおいしい。結球しなくても多くを食べられる。
  • 次年度の方針
    • 冬の主役として10株以上を目標とする。9月下旬に定植する。

ブロッコリー

  • 結果
    • 前年の自家採種から育てた苗6株のうち、3株を9月頭に定植、もう3株を10月末に定植。前者3株は11月末~12月に市販品と同等の頂花蕾を収穫でき、以降3月まで側花蕾を継続的に収穫した。後者3株は草丈20cm程度で成長が止まった。2月3月にはどの株も食害を受けており、葉には食害した虫によると思しき黒い糞があった。
  • 感想
    • 白菜と同じく、後者3株は定植時期が遅かったのだろう
    • 葉をくまなく探したが食害の主を見つけることはできなかった。ヨトウムシではないか。
  • 次年度の方針
    • 冬の主役として5株以上を目標とする。9月に定植する。
    • 同様の食害が見られた場合にはヨトウムシを疑い、土中の探索や薬剤散布などの対策をする。

ロマネスコ

  • 結果
    • 市販の種から育てた苗3株を10月中旬に定植。市販品と同等の頂花蕾を収穫できたものは2株。ブロッコリーと同じ日に定植し、ブロッコリーの苗と同程度の大きさだったが、ブロッコリーよりも頂花蕾ができる時期が1ヶ月ほど遅かった。残り1株は草丈こそ最も高いものの、頂花蕾ができなかった。ブロッコリーと同じ食害を受けていた。
  • 感想
    • ブロッコリーよりも育ちにくいのだろうか。少し調べただけではわからない。
  • 次年度の方針

たまねぎ(アーリーレッド)

  • 結果
    • 購入苗16株を11月中旬に定植。2022年5月1日現在栽培中。3月まで無肥料で育て、貸し農園の期間終了を機に自宅の庭に移植。3月と4月に化成肥料を追肥。玉の大きさは直径2-3cm程度。半数以上の株の茎が倒れている。
  • 感想
  • 次年度の方針
    • 50個以上を目標とし、レイズドベッドにて慣行農法で栽培する。

大根

  • 結果
    • 青首品種の種を10月中旬にまき、3月に10本収穫。うち又根は2本。葉を除いた長さは20-30cm。
  • 感想
    • 耕さなくても又根は2本。関係あるのだろうか。
    • 近くの他の畑では11月から収穫に入っていた。まくのが遅い。12月を収穫ピークにするように育てるべきだ。株が市販品に比べて小さいのも時期が大きいのではないか。肥料よりも。
    • 味も食感も市販品より悪い。おでんの具にはふさわしくない。おろしになら使える。太くなれば味もよくなるだろうか。
  • 次年度の方針
    • 20本以上を目標とし、8月下旬に種をまく。

芽キャベツ

  • 結果
    • 購入苗2株を9月頭に定植。12月頭から徐々に下葉を除去。1月2月に収穫。玉の大きさは市販品より小さい。
  • 感想
    • 定植の遅かった他の冬野菜と違って適した時期に植えたつもりだが育ちが悪かった。肥料不足だろうか。下葉は慣行農法に従って除去したが、もっと早くすれば玉が肥大したのではないか。
  • 次年度の方針
    • 4株以上育てる。市販品同等の玉を目標とする。

Software Engineering: A Practitioner's Approach 1st edition (1982)に見る歴史

まとめ

  • Software Engineering: A Practitioner's Approach 1st edition (1982) はソフトウェアエンジニアリングの教科書として最初期のもの。9版(原著2019、邦訳2021)が最新。
  • ソフトウェアエンジニアリングはソフトウェア危機(software crisis)に呼応して生まれたと書かれている。ただし、ソフトウェア危機を示す参考文献として NATO Software Engineering Conference の議事録は挙げられていない。
  • ソフトウェア危機は表面的にはコストとスケジュールの問題であり、その背景には「開発の実績データがない」「生産性の指標がない」「開発プロジェクトの拠り所は曖昧な顧客の要求しかない」「テストの重要性に気づいたのはつい最近」「既存ソフトウェアの保守は難しい」という難しさがある、と書かれている。問題も難しさを増しているため現代でも克服できていないことは多い、というのが私の所感。
  • 計画、開発、保守というライフサイクルに沿った章構成となっている。その背景にはライフサイクルをフェーズとみなした逐次的なプロセスモデルが伺える。ただし、プロセスモデルウォーターフォール、Winston Royce は参考文献に無い。
  • 保守が工数的に最も多くを占めることは1982年の時点で認識されている。ただし、それに対応する技術は未開拓であり、逐次的なライフサイクル(フェーズ)の最後に保守があるというプロセスモデルしか見いだせていなかったのではないか。
  • 初版にはプログラミング言語選定指針とコーディングスタイルの章がある。これの現代版に需要があるのではないか。
  • 初版は Amazon.com で入手。昔の学生が使っていた教科書かもしれない。えもい。

この文章を書いたきっかけ

米国の大学を中心に教科書として採用されており、40年に渡って改訂されてきたベストセラーであるという Software Engineering: A Practitioner's Approach 9th edition の訳書 "実践ソフトウェアエンジニアリング第9版" が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の15日目(2021/12/15)に公開するはずでしたが、1月になってから書いています。

今回は1982年に発刊された初版 Software Engineering: A Practitioner's Approach 1st edition を扱います。 最新の9版を知る共訳者の身からして、始まりは何だったのかという興味がわいて入手しました。 入手先は Amazon.com で、値段は10ドル未満でした。

f:id:masskaneko:20211021212315j:plain
初版(左)、9版(右)

始まりを示す記述

一般に、ソフトウェアエンジニアリングという分野の始まりは 1968-1969 年の NATO Software Engineering Conferences *1 とされています。 そして、1982年に出版された本書はソフトウェアエンジニアリングを冠した最初期の教科書です*2。 であれば、本書にはソフトウェアエンジニアリングという分野の始まりが書かれているはずです。

それは本書のPREFACE(まえがき)に書かれていました。

  • 電子コンピューターの時代を振り返ると、1950年代と1960年代はハードウェアの時代だった。1970年代はソフトウェアを認識する転換期だった。そしてソフトウェアの時代が目の前に訪れた。現に、強力な1980年代のプロセッサを使いこなすほど質の高いソフトウェアを生み出せず、コンピューター技術が進歩する足を引っ張りつつある。
  • 1970年代において、我々は「ソフトウェア危機(software crisis)」と称される状況を認識するに至った。ソフトウェアに関するコストは爆発的に増大し、コンピューターを使用したシステムにおいて最も高価な要素となった。開発計画の通りに進むことはほとんどなかった。ソフトウェアが大きくなるにつれ品質が怪しくなってきた。参考となる過去の開発データは乏しく、プロジェクトのコントロールは失われていった。
  • そして、ソフトウェア危機に呼応する一連の技術、すなわち「ソフトウェアエンジニアリング」が誕生した。これらの技術はソフトウェアを工業製品として扱うものであり、計画、分析、設計、実装、テスト、保守というプロセスが必要な工業製品だと位置づけた。本書の目標は、そうしたソフトウェアエンジニアリングプロセスをまとめて紹介することである。

NATO Software Engineering Conferences は1968-1969年であり、その議事録に software crisis が登場します。 その crisis と称されるほどの大問題が広く業界に認識される時期が1970年代だった (転換期だった) ということでしょう。

Software Crisis の内容

本書の2章は The Software Crisis です。 日本語ではソフトウェア危機と呼ばれ、Wikipedia に載っています。

本書の 2.1 The Problems でその問題が解説されています。

  • ソフトウェア危機は多くの問題によって特徴づけられる。だが、ソフトウェア開発の責任者(あるいは経営者)は、スケジュールが何ヶ月や何年も遅れることや、費用が予算を著しくオーバーするといった表面上の問題に関心がある。そうした問題はソフトウェアの難しさの結果として見えてくるものだ。
The software crisis is characterized by many problems, 
but managers responsible for software development concentrate on the "bottom-line" problem:
schedule and cost estimates are often grossly inaccurate.
Cost overruns of an order of magnitude have been experienced.
Schedules slip by months or years.
These problems are the most visible manifestation of other software difficulties:

続いて、その難しさが列挙されています。

  • ソフトウェア開発プロセスの実績データを収集していない。データがないので見積もりの精度は悪い。生産性の指標もないので、新しいツール、技法、標準の効果を評価できない。
  • 顧客が "完成" したシステムに不満を抱くことは日常茶飯事である。開発プロジェクトの拠り所は曖昧な顧客の要求しかない。顧客と開発者のコミュニケーションはお粗末である。
  • ソフトウェアの品質は大体怪しい。我々が体系的で技術的に完全なソフトウェアテストの重要性に気づいたのはつい最近のことだ。定量化の概念が信頼性と品質保証に持ち込まれたのも最近のことだ。
  • 既存ソフトウェアの保守は非常に難しい。大半のコストは保守にかかっている。だが、ソフトウェアの保守性は受け入れ条件として重要視されていない。

現代に至るまで、これらの難しさを克服するための技術が生まれてきました。 それによってどれだけ克服できたか考えてみると40年の進歩が明らかになりそうです。 問題も難しさを増しているため現代でも克服できていないことは多い、というのが私の所感です。

初版の構成とプロセスモデル

PREFACE(まえがき)によると、初版の構成はソフトウェアライフサイクルに沿ったものだそうです。

The contents of this book closely parallel the software life cycle.

1.4.3 にはソフトウェアエンジニアリングの主目的が示されており、計画(planning), 開発(development), 保守(maintenance) というソフトウェアライフサイクルに対応する方法論を確立することが挙げられています。

The key objectives of software engineering are
(1) a well-defined methodology that addresses a software life cycle of planning, development, and maintenance,
(2) an established set of software components that documents each step in the life cycle and shows traceability from step to step, and
(3) a set of predictive milestones that can be reviewed at regular intervals throughout the software lifecycle.

この後、Plannning phase, Development phase, Maintenance phase の説明が続きます。 実際に、本書の構成はこれらの phase に沿う物となっています。

まず、1, 2章はソフトウェアライフサイクルを語る前提に位置するものとなっています。

  1. Computer System Engineering
  2. The Software Crisis

そして、計画を扱う章が始まります。

3. System Planning
4. Software Planning
5. Software Requirement Analysis

次に開発。

6. The Software Design Process
7. Software Concepts
8. Data Flow-Oriented Design
9. Data Structure-Oriented Design
10. Detailed Design Tools
11. Programming Languages and Coding
12. Software Testing and Reliability

最後に保守で締めくくられます。

13. Software Maintenance

本書において、計画、開発、保守はライフサイクルであると共に一定の期間を表すフェーズです。 それを表す図として、manager と technical staff がどのライフサイクルで参加するかを示したものがあります。

f:id:masskaneko:20220105023845p:plain

また、ライフサイクルによる工数の推移を示した図もあります。

f:id:masskaneko:20220105023927p:plain

これらの図からすると、本書ではライフサイクルをフェーズに対応させたプロセスモデルを置いていることがわかります。 言い換えれば、ウォーターフォールと称される逐次的なプロセスモデルです。 ただし、プロセスモデルという言葉も、ウォーターフォールという言葉も、ウォーターフォールの祖と誤解された Winston Royce も本書には載っていません。

現代では、ライフサイクルをフェーズに対応させるのではなく、より多くのライフサイクルを円滑させたフェーズを反復するプロセスモデルが重要とみなされるようになりました(例:XP, DevOps)。 また、これらのライフサイクルにない領域も定義されるようになりました(例:構成マネジメント、システムモニタリング、プロセス改善)。

では、本書にはそのような現代的な事項に関係することが全く書かれていないか? というとそうではなく、13章 Software Maintenance に全部押し込まれているというのが私の見解です。

最初の開発コストよりも保守コストが多くを占め、増してゆく図があります。 言い換えれば、リリースしてからが本番であることは40年前からわかっていたということです。

f:id:masskaneko:20220105025153p:plain

保守要望(maintenance requests)を基点としたプロセスフローを示した図があります。 これを現代的に見れば、バックログアイテムの認識と優先度づけ、それに対する変更マネジメントです。

f:id:masskaneko:20220105032043p:plain

ほか、既存コードを読み解くことの難しさ (maintaining alien code)、保守による思わぬ副作用(side effects)、変更日時や変更理由などを記録することの大切さ (record keeping)、デバッグを可能にしておくこと(built-in debugging facilities) が挙げられています。 13章に書かれた内容は現代に至るまで、構造化設計、オブジェクト指向設計、静的コード解析、保守性のメトリクス、バージョン管理、継続的インテグレーション、自動テスト、リファクタリング、イテレーティブ&インクリメンタルプロセスモデルに進化してゆきます。

本書が書かれた1982年の時点では、リリースしてからが工数的に本番であることは認識しつつも、それに対応する技術は未開拓であり、逐次的なライフサイクル(フェーズ)の最後に保守があるというプロセスモデルしか見いだせていなかったのではないでしょうか。だから、保守を扱う章は13章のみなのだと思います。

最新版にあってもいいんじゃない?と思う初版の内容

最新の9版では、1章にソフトウェアエンジニアリングの定義と意義と概要が書かれています。 ですが、ソフトウェアエンジニアリングが無いとどのような問題に直面するのか?それらの問題はコンピューターサイエンスでは解決できない領域なのか?という切り口では書かれていません。 なので、ジュニアクラスの実務者やコンピューターサイエンス専攻の学生が9版の1章を読んでソフトウェアエンジニアリングを学ぶ気になるかは怪しいと考えています。 そこでソフトウェア危機(software crisis)を持ち出し、歴史的にどのような問題があったか、それらの問題は現在ではどう形を変えて残っているのかを記述すれば、学習動機が生まれやすいのではないでしょうか。

9版にコーディングの章はありませんが、初版の11章は Programming Languages and Coding です。 プログラミング言語の種類と特徴、言語の選択指針、コーディングスタイルが扱われています。 40年前の本ですので、出てくる言語は FORTLAN, PL/1, Ada といった古いものですが、これの現代版があったら嬉しいのではないでしょうか。 現代のメジャーな言語をいくつか取り上げ、言語選択指針、コーディング規約、コード解析、コードメトリクスを扱うことは、 実際のソフトウェアエンジニアリングにおいて需要があると思います。

感想

初版を全て読んだわけではありませんが、分野の誕生と保守に着目して現代とのつながりを見出すことができました。 今後、教育資料を作るときに出番があるかもしれません。 実務で参照することは無いと思います。コレクター的に持っていてもいいんじゃない?という程度です。 私が入手した本にはハイライトやメモ書きが残っていました。 40年前にアメリカの学生が読んでいた教科書が日本の暇人の元にやってきたのでしょうか。エモし。

f:id:masskaneko:20220105052727p:plain

*1:http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html

*2:ソフトウェアエンジニアリングの教科書例は CMU/SEI が1991年に調査した文献 https://resources.sei.cmu.edu/asset_files/TechnicalReport/1991_005_001_15932.pdf の Table 2 に掲載されており、本書はその筆頭として挙げられている。その中に、本書と同様に数十年に渡って改訂されている Sommerville 著の Software Engineering があるが、こちらの初版は1985年である。

Googleのソフトウェアエンジニアリング、実践ソフトウェアエンジニアリング第9版の関係

まとめ

  • 両者のソフトウェアエンジニアリングの定義は大体似ている。「規律」が共通点。規律でありながら適用が厳格でないと述べている点も一緒。「時間で積分したプログラミング」が SEatGoogle での独特な表現。
  • SEPA はソフトウェアエンジニアリングの全体を示している。対して SEatGoogle では全体を示しておらず、設計、プロセスモデル、品質保証といった章になりそうな領域でさえ省かれている。代わりに、SEPA におけるソフトウェア構成マネジメント(22章)が最も関係している。
  • SEatGoogle がそのような構成になっているのは Google 最初期のプロダクトである検索と広告が商業的に大きく成功したことによって持続可能性とスケーラビリティを追い求めてきたから
  • SEPA は基礎を学ぶための本。SEatGoogle はその基礎に基づきつつ、Google のソフトウェアとビジネスにとって重要な領域を独自に体系化した本。それにある程度近い業界であるほど役立ちそう。「そこは第一じゃない」と異論を唱える業界もいそう。

本編

この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の8日目です。 米国の大学を中心に教科書として採用されており、40年に渡って改訂されてきたベストセラーであるという Software Engineering: A Practitioner's Approach 9th edition の訳書 "実践ソフトウェアエンジニアリング第9版" が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。7日目は 複数名で進める翻訳環境と事前準備 のお話でした。

今回は、この第9版と Googleのソフトウェアエンジニアリング (原著: Software Engineering at Google) との関係を簡単に見出します。 Google のソフトウェアエンジニアリングは、その名の通り Google で行われているソフトウェアエンジニアリングについて記されており、そのページ数は体系的解説書である実践ソフトウェアエンジニアリング第9版よりも多く(640>520)、発刊時期も2021年11月下旬とほぼ同じです。 同じ分野の重い本が同時に世に出ましたので、ECサイトや本屋で両方を目にすることがあるでしょう。 重い本にチャレンジする気概がある読者候補であっても両方を読む方は少数で、「どっちにしようか」選ぶのではないでしょうか。 また、私は第9版の共訳者で、普及の意味でこのアドベントカレンダーを書いているのですが、「実はGoogle本の方が今時の役に立つことが書いてあるんじゃないの?」 *1という疑問と期待を持っていました。というのが、関係を見出す動機です。

この文章では、それぞれの原著名にちなんで、実践ソフトウェアエンジニアリング第9版を SEPA と、Googleのソフトウェアエンジニアリングを SEatGoogle と記します。 そして、両者の関係を見出す質問として以下のものを設け、これらを本文章の構成とします。

  • ソフトウェアエンジニアリングの定義は同じか?
  • SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?
  • なぜ SEatGoogle の SEPA に対する特徴がそうなっているのか?
  • 誰が読むと役立つのか?

両者の関係を 簡単に 見出すと書いた理由は、私が SEatGoogle を全体的に浅く読んだだけであり、この文章を書くのも1日しかかけていないからです。 より深く正確に、多くの人にとって意義ある関係を見出すには時間がかかるでしょう。 また、そこに集中して労力をかける意味はそれほどなく、今後の活動の中で両者を参照していくうちにわかっていけばよいと考えています。

ソフトウェアエンジニアリングの定義は同じか?

どちらの本も序文でその定義について触れています。共通要素はあるものの、SEatGoogle には独特な記述があります。

SEPA の "まえがき" では次の文があります。

経験をもとに失敗の真因に立ち向かうためには、設計や構築における規律(discipline)が必要である。すなわちエンジニアリングというアプローチの必要性を意味する。 … その成果である手法、プロセスモデル、ツールは、多種多様な産業分野において活用されている。

国際的には ISO/IEC/IEEE 24765:2017 で定義されているそうで、SEPA では次のように訳されています。

ソフトウェアの開発、運用、メンテナンスに対するシステマティックで規律(discipline)ある、 定量化できるアプローチの適用、すなわちソフトウェアに対するエンジニアリングの適用[IEE17]。

対して、SEatGoogle の "はじめに" では、定義の後に「規律」が同じく登場し、その定義を別の独特なフレーズで示し直しています。*2

我々が提案するのは、「ソフトウェアエンジニアリング」とは単にコードを書く行為のみならず、組織が時間の経過に応じてコードを構築し保守するために用いるツールとプロセス全てをも包含するということである。 … エンジニアたちはどのようにして、コードベース(codebase)をさらに持続可能にしつつ、ソフトウェアエンジニアリングの規律自体を厳格化できるだろうか。 … 本書が共有する重要な認識に、ソフトウェアエンジニアリングとは「時間で積分したプログラミング」とみなせる、というものがある。

仕事で、特定のプロダクトのコードを何年も書き続けたことがある人にとっては SEatGoogle が提唱する定義の方が納得できるかもしれません。私はその一人です。 というのも、私はプログラミング以上にソフトウェアエンジニアリングが必要になる理由の主要要素を「時間」「他人」「要求(または品質)」だと認識してきたからです。 「時間」と「他人」は SEatGoogle の全編で触れられています。

そして、定義の周辺にも共通する記述があります。規律とはいっても適用が厳格でない点です。

SEPA ではこう書かれています。

マネージャも開発者も規律の必要性を認識している。一方、規律の適用方法については意見が分かれている。たとえ最先端技術を扱う開発であったとしても、規律が適用されていない現場は珍しくない。…規律の適用方法まで含めて完全に成熟するまでには、すべきことがまだまだ山積みだ。

SEatGoogle にも似た記述があります。

比較的確立された他のエンジニアリング専門職と異なり、現在のソフトウェアエンジニアリングの理論やプラクティスは、同程度に厳格であるとはいえない。 …ソフトウェアが我々の生活にさらに統合されていくに従い、ソフトウェアエンジニアリングもさらに厳格なエンジニアリングの方式を採用し、そうした方式に頼らなければならない。 …Google自身も、本書のページ内に収められている概念の多くをいまだに不完全にしか適用していない。

この業界では、多様な状況下で規律の仮説と実証が繰り返され、規律が練り上げられてきました。 ただ、規律がどのような条件下であるほど有用か、その条件を示す変数(例:ライフサイクル、品質特性、コード量、計算機資源、人数、ビジネスモデル)が何なのかは明らかにされていません。 また、特定の状況に有用な規律が判明したとして、その適用過程は個々の事例レベルにとどまっておりパターン化が進んでいません。規律の適用条件と適用過程が解明されれば、これまでに蓄積された規律の価値が爆発的に向上するという未来を私は見ています。*3 *4

というわけで、定義が同じか?という疑問に私が出した答えはこうです。

  • 両者のソフトウェアエンジニアリングの定義は大体似ている。「規律」が共通点。規律でありながら適用が厳格でないと述べている点も一緒。「時間で積分したプログラミング」が SEatGoogle での独特な表現。

SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?

全然そうではないというのが SEatGoogle を浅く読んでわかったことです。 SEatGoogle の "はじめに" には "本書が扱わないもの" という節があり、次のことが書いてあります。

ソフトウェア設計という、それ自体独立した書籍を必要とする専門分野を扱うことは、本書の目指すところではない。 …本書で扱っていないソフトウェア開発上の重要な問題も多い。 例えば、プロジェクトマネジメント、API設計、セキュリティ強化、国際化、ユーザーインターフェイスフレームワーク、その他のプログラミング言語特有の概念だ。 そういった問題が本書では省略されているからといって、各問題の重要性が失われることを意味するわけではない。むしろ、それらの問題が値する処遇を提供できないことを承知しつつ、 本書ではあえて扱わないことを選択している。 我々が心がけたのは、本書での議論を、プログラミングというよりエンジニアリングをめぐるものとすることだ。

実際に、プロジェクトマネジメント、API設計、セキュリティ強化、国際化、ユーザーインターフェイスフレームワーク、その他のプログラミング言語特有の概念は 主題として扱われておらず、出てくるとしてもきわめて断片的に登場するのみです。

SEPA の章に当てはめて言えば、ほとんどの章は主題として扱われていません。例えばプロセスモデルの話はありません。アジャイル (agile, agility) という言葉は度々登場し、Lean と DevOps の科学、Successing with Agile という文献も参照されていますが、Googleアジャイル開発あるいはリーン開発をどのように行っているかという切り口の文面はありません。iteration という言葉は本書に多く登場しますが、イテレーティブプロセスの iteration ではありません。ただし、多くの人から見て頻繁に思えるであろう程度のリリースをしている記述があります。24.4 では

ある時点では、Google検索のバイナリを本番環境に1回しかリリースしておらず、週1回の目標を達成することすら稀で、運次第のことが多かった。 …現在では、Google検索の新バイナリを本番環境へ1日置きに安定的にリリースできるようになっている。

16.2.3 では

製品の各リリース間の期間(またはリリースの存続時間)が数時間より長いならば、製品のリリースビルドに入ったコードを正確に表すリリースブランチを作成するのが賢明かもしれない。

という記述があります。

ほか、software requirements も quality assurance もヒットしませんし、diagram で出てくる文にはモデリングの話はありません。

代わりに、SEPA の 22章:ソフトウェア構成マネジメントで扱われている内容が SEatGoogle 第3部のほとんどの章に登場します。 16章:バージョンコントロールとブランチ管理、17章:Code Search、18章:ビルドシステムとビルド哲学、19章:GoogleのコードレビューツールCritique、21章:依存関係管理、22章:大規模変更、23章:継続的インテグレーション、24章:継続的デリバリーにて、SEPA で扱われている内容が具体的され、さらなる発展的な問題が取り上げられています。これら以外の章でも変更マネジメントに関する内容が部分的に登場します。

SEatGoogle の第2部は「文化」という名前で、2章~7章があります。SEPA での近い章としては5章:ソフトウェアエンジニアリングの人間的側面が挙がります。2章:チームでうまく仕事するには と比べると、どちらにも「チーム」「心理」「信頼」という言葉が出てきますが、起点も論旨も両者でかなり異なっています。SEPA ではトム・デマルコのピープルウェアを引用しているのに対し、SEatGoogle では独自論(部分的には Team Geek の内容を含む)がソフトウェアエンジニアの人間的な弱さを深堀りして展開されているように見えます。ほか、第2部文化に対する SEPA の記述としては、ポストモーテム(16.7)、マネジメントの要素としての人材(24.1.1)、人材構成(29.4.4)、協働的開発(29.5.3)、品質保証における教育(17.2)、プロセス改善における教育(28.2.2)という部分が相当するように見えますが、それらの細切れの節を集めても第2部文化の各章名に足る内容にはならないように見えます。そして、第2部の最後にある7章はエンジニアリング生産性の計測で、SEPA における近いようでそうでもない章が23章のソフトウェアメトリクスと分析です。SEPAの23章では、見積もり、品質測定など生産性計測以外の目的もその序文に書いてあり、多数のメトリクスが載っています。SEatGoogle では GSM 法に基づいた生産性計測の方法、具体例、注意点が載っています。GSM は SEPA に載せてもよかったんじゃないかと思います。

テストについては SEatGoogle では11~14章、SEPA では19~21章で扱われています。どちらも小規模なテストと大規模なテストの違いを述べており共通点があります。ただ、SEatGoogle には SEPA その他テストの書籍にあるような古典的テスト技法がなく、代わりに自動テストに大幅な紙面が割かれています。SEatGoogle の11~13章だけを切り出しても、Googleの文脈にそれほど関係のない一般的で有意義なユニットテスト本になりそうな出来です。

SEatGoogle の10章は「ドキュメンテーション」です。SEPA にドキュメンテーションの章はありませんが、21.12ドキュメントとヘルプ機能のテスト、9.4.1設計モデリングの原則、4章の冒頭に記述があります。ドキュメントはソフトウェアと共に成長すべき、という意見が両者で一致します。

SEatGoogle の最後25章は「サービスとしてのコンピュート」という名で、SSHログインによる手動のデプロイから始まり、スケジューリング、障害対応、監視といったタスクをプログラマブルに実現させきた歴史と方法が書かれています。23章からたびたび登場する Borg という自前のコンピュートサービスについて最も詳細に触れられ、Google 以外の会社がとれる代替手段も説明されています。この内容を1章として24章「継続的デリバリー」に続く最後の章にしているところは超絶的な規模でサービスを運用している Google らしいと感じました。これに相当する章は SEPA にはありません。次の版ではサーバーサイドに限定しない運用の章でこういう内容を扱ってもいいんじゃないかと思います。

浅いとはいえ重い2冊を扱ったので長くなってしまいましたが、SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?に端的に答えるとするとこうなります。

  • SEPA はソフトウェアエンジニアリングの全体を示している。対して SEatGoogle では全体を示しておらず、設計、プロセスモデル、品質保証といった章になりそうな領域でさえ省かれている。代わりに、SEPA におけるソフトウェア構成マネジメント(22章)が最も関係している。

なぜ SEatGoogle の SEPA に対する構成がそうなっているのか?

SEatGoogle の "はじめに" には、一般的なソフトウェアエンジニアリングに対してこのような文面が書かれています。

過去50年にわたり著されてきたこれまでのソフトウェアエンジニアリングに関する文献の全集に付け加えるに足る独特な観点を、何故Googleが持っていることになるのだろうか。

過去50年というのは、ソフトウェアエンジニアリングという工学分野が生まれたとされる 1968年の NATO 会議からの50年を指しているとみて間違いないでしょう。 そして、それを把握して文献の全集と言っているからには、SEPA に載っているような一般のソフトウェアエンジニアリング体系を把握している上で、 SEatGoogle として練り上げた体系は独特だと主張しているのでしょう。

その独特さは、ソフトウェアエンジニアリングとはプログラミングを時間で積分したものという定義に始まります。 続く章では、他のエンジニアと共にコードを持続的し、システムや組織を市場の需要に沿うよう(あるいは自身の目標に沿うよう)スケールさせる意義や方法が文化・プロセス・ツールという軸で語られます。 先の節で述べた通り、同じ "ソフトウェアエンジニアリング" を冠した重い本でも、その構成は SEPA と全く異なります。

個々の章の内容は「これまでのソフトウェアエンジニアリングに関する文献の全集」のどこかにあるのだと思います。はっきりとはわかりませんが。 とすると、独特なのはその構成ということになります。 なぜそのような構成になったのか?それは

  • Google 最初期のプロダクトである検索と広告が商業的に大きく成功したことによって、
  • ユーザーが世界的に増え、社員が増え、コンピュートが増え、コードの寿命が伸び、
  • 創業者ら初期メンバーが得意としていたであろうプログラミングを超えたソフトウェアエンジニアリングの必要性に気づき、
  • 既存の文献を参照しつつ持続可能性とスケーラビリティを追い求め、
  • その追求にふさわしい人材とコンピュートを投入し、
  • Piper や Critique や Borg といったツールを生み、
  • ツールの背景にはプロセスが、さらなる背景には文化があることを認識し、
  • システムのバグや人間関係のトラブルといった痛い目を見て、トイレに tips を貼るキャンペーンという地道な活動をし、
  • 続けてきた活動が正しかったと確信したから

ではないか、というのが SEatGoogle を浅く読んだ結果と、読む前から知っている断片的な Google の情報を直感的に結びつけた答えです。 なので、SEatGoogle をもっと深く読んだり、他に公開されている Google の文献 (例:How Google Works?) を読むと、商業的な要因まで含めた経緯がわかりそうです。

誰が読むと役立つのか?

SEPAは、読書感想文 の最後に述べた通り、 実務経験者がソフトウェアエンジニアリングの基礎を理解するのに役立つと思います。 入門書ではなく基礎が体系的に書かれている本なので、実務経験者が読むのが望ましいです。 学生や実務経験が乏しい方が入門書として読む場合は識者のレクチャーが必要だと思います。 (著者は、情報関連の学部4年生以上か、実務者が読むことを想定しています。)

SEatGoogle も実務経験者が具体的な経験と抽象化された知識を結びつけて理解を向上させる読み方ができると思いますが、 ソフトウェアエンジニアリングの全体を扱っていない(Googleが大事だとみなしている領域に集中している)点に留意しておく必要があります。

Googleと同じように持続可能性とスケーラビリティが求められるプロダクトを扱っている読者であるほど、 SEPA より先に SEatGoogle を読む方が合う情報にたどり着きやすいと思います。 そして、読者は別に Google と同じく巨大な Web サービスを扱っている必要はないでしょう。 例えば、大きなコードベースを組織的・持続的に成長させているというのは、 ローカルなサービスでも、デスクトップアプリにも組込みソフトウェアにも当てはまるはずです。 これから商業的に成功させるプロダクトを撃とうとしている若い企業には SEatGoogle は先の話に見えるかもしれませんが、 簡便化して取り入れ、目先や1年後に役立てることはできそうに思えます。

ただ、SEatGoogle は SEPA で言う「ソフトウェア構成マネジメント」を最も重視した構成になっていますが、 読者の扱うプロダクトが必要とするソフトウェアエンジニアリングにおいてもその構成が最適かというと複数の異論があるように思えます。 ゲームから見れば同じ構成マネジメントでもグラフィックスやサウンドやシナリオを扱うことが欠かせなかったり、 人命を扱う機器から見れば持続可能性よりも安全性から体系を組み立てるのではないかと想像します。 *5

SEatGoogle や、そのほか他社の包括的な実践事例を参考にするとしても、ゆくゆくは自社にとっての体系を作るはずです。 それを作る際には、一般的にソフトウェアエンジニアリングってどんなものなのかを知るリファレンスが盤石な土台になります。 SEatGoogle でも、過去50年にわたり著されてきたこれまでのソフトウェアエンジニアリングに関する文献の全集 を参照して 独特な観点 を加えています。

勘と運があれば、この種の重い本がなくても、ツール名やプラクティス名の検索結果である断片的な情報を思うまま組み合わせてなんとかなるかもしれません。 それに限界を感じたら選択肢に入る本だと思います。

*1:ここで「セガなんてだっせーよな?帰ってプレステやろーぜー」という構文を入れることを浮かべたが、公開寸前にポリコレ脳が機能し却下した。

*2:原著では、機械、土木、航空分野に discipline が存在する旨がソフトウェアエンジニアリングの定義より前に述べられている。

*3:特定の領域については書籍になっているものもあります

*4:モダン・ソフトウェアエンジニアリング のエッセンスを拡張するものか、ソフトウェア病理学における病気になりやすい条件として書けるかもしれない。

*5:ほか、受託開発で完成したら顧客企業にコードを納品しておしまいだったり、開発を外注して運用は塩漬け、みたいな場合には何の参考にもならないと思います。

初めての英日翻訳で学んだこと

この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の6日目です。 "実践ソフトウェアエンジニアリング第9版"(原著: Software Engineering: A Practitioner's Approach 9th edition) が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。

5日目では翻訳における日本語の難しさ が語られました。今回も英日翻訳の話になります。 私が英語の本を日本語に訳したのは本書が初めてです。 翻訳中に学んだことを細々と記していたのですが、本書の出版を機にそれらをまとめることにしました。 5日目とは別の切り口とし、以下の構成で記します。

  • 第一に語彙
  • 英和辞書ではなく英英辞書を使う
  • 参考文献を読まないと意味がわからないことがある
  • 機械翻訳は答え合わせの材料
  • 定番の訳があるか調べる
  • レビューでは直す理由を直感を超えて書き下す

第一に語彙

原著に出てくる単語はこの分野の論文、規格文書と比べて難しく感じました。 論文と規格文書では平易な語彙が選ばれているのかもしれない、ネイティブが手加減せずに書いた普通の語彙がこのくらいなのかもしれない、とも思わされました。 例えばこんな単語が出てきます。いずれも、Weblio では英検準1級以上の単語とされています。

もう少し易しく思えるものを選ぶとこうです。 易しく思えるといっても、本書を読む前は知らない単語でした。 どこかで出会った覚えはあるのですが意味はわかりませんでした。 いずれも、Weblio では英検3級~2級の単語とされています。

特に名詞と動詞を知らないと文の意味が全くわかりません。 それに比べれば形容詞と副詞は知らなくても文の意味を理解できる場合が多いです。 形容詞と副詞を除いても文として成立するからです。 しかし、形容詞と副詞が重要な意味を担っているがゆえに誤解し、後から誤解に気づいた場合が何度もあった覚えがあります。

私は前職で集中的な英語の研修を受けた際に Words are more important than grammar in both understanding and expression. と教わり、 英語に触れるたびにそれを思い出すのですが、今回の翻訳でもずっとそれが頭に残っていました。

英和辞書ではなく英英辞書を使う

英日翻訳のプロセスは、(1)英文の読解→(2)意味の理解→(3)日本語への翻訳というものです。 (2)は前の文章との意味的つながりを考えたり、自身の経験と対応づけたり、光景を浮かべたり、といったものです。 (2)では英語と日本語のどちらも使うことができますが、日本語を使わないことにしました。それは、

  • 原文の意味を理解し、意味を損なわない訳文を書くため
  • 英語を理解する能力を上げるため

という理由です。 英語のまま意味を理解できれば、(1)読解と(2)意味の理解を同時にできますが、日本語を使うと(1)と(2)は分かれて遅くなります。

だから、知らない単語を調べるときに英和辞書ではなく英英辞書を使うことにしました。 Cambridge Dictionary では知らない単語を記録することができます。 この機能を使って、知らない単語が出てくるたびに記録していきました。

また、英和辞書には英単語ごとに複数の訳が載っていますが、そのどれでもない訳語を使うことはよくあります。 典型的なのは discuss で、Weblioでは「論じる」「論議する」「話し合う」「検討する」「討論する」「検討する」という訳語が出てきます。 本書では As we discussed in Chapter 1, といった他の記述箇所を参照する文節が多く登場しますが、ほとんどの箇所では「述べた」と訳されています。 ほかの案としては、「説明する」「解説する」「後述する」「前述した」が考えられますが、いずれも英和辞書を見ても出てこない訳語です。

参考文献を読まないと意味がわからないことがある

原著のアクセシビリティテストを扱う節で以下の文があります。

As a profession, virtual environment development has not done a good job of providing access systems with rich graphical interfaces that rely heavily on touch interactions [Dia14].

virtual environment を「仮想環境」と解釈しようとすると文の意味がわかりません。 前後の文を見ても、Vitrual Reality の話も、Virtual Machine の話も出てこないからです。 ここで、Dia14 という参考文献 を読むと、その内容は、高齢者向けのUIを持つホームアプリと電話アプリをデフォルトAndroidアプリと比較する話でした。よって、virtual environment とは高齢者向けの代替アプリを指すことがわかります。つまり、ここでの virtual の訳は「仮想」でも「実質的な」でもなく「代替」となります。

このように、参考文献を読まないと意味のわからない文には、少ないですが何箇所か出会いました。 訳文の工夫だけでそれを補えない箇所には訳注を付けています。

機械翻訳は答え合わせの材料

ここ数年で DeepL と Google Translator に代表される機械翻訳の質が向上しました。 英文を入力すると、そこそこ自然に感じる日本語が出力されます。

私は本書の翻訳作業で DeepL を使いました。 といっても、最初から DeepL を使うことはなく、自身で訳文を作った後に使っています。 先のプロセスでいえば、(1)英文の読解→(2)意味の理解→(3)日本語への翻訳→(4)DeepL の訳文との比較、という順番です。 その理由も英和辞書を使わない理由と同じで

  • 原文の意味を理解し、意味を損なわない訳文を書くため
  • 英語を理解する能力を上げるため

というものです。 さきほど語彙の節で述べたように、知らない単語を除いて文意を誤解することがあります。 知らない形容詞と副詞を除いて文意が理解できたつもりになると、知らない単語があったということを忘れ、辞書で調べないことがあります。 DeepL は、その忘れを思い出し、誤解を解くのに役立ちました。

そして、母語が日本語である人々にとって自然に感じる訳文を出せるという DeepL の強みに頼って、自分では思いつかなかった表現を覚えられることも DeepL の利点です。

ただし、DeepL の英日翻訳も人が訳すと同様に誤訳がありますので、比較材料にとどめるのが良いと思います。 比較して意味に違いがあれば、どちらかが(どちらも)間違っている可能性が高いということです。 どちらが間違っているのか DeepL は教えてくれません。

定番の訳があるか調べる

初めてその分野の文献を翻訳する場合は翻訳者が訳語を考えますが、 本書ではそうでない箇所が多く、既存の翻訳文献に定番の訳があるかを確認することが必要になります。 これには語学力ではなく、内容の知識と調査能力が求められます。

わかりやすい例としては、テスト駆動開発継続的インテグレーション教師あり学習、といったものがあり、多くの文献で同一の訳語が使われています。 ガートナーのライフサイクル における「幻滅期」や「過度な期待のピーク期」というのも、公式的に提供された定番の訳にあたります。

そういう迷わずに済む場合ばかりではありません。 その分野に関する既存の翻訳文献が存在するものの、定番といえるほどの文献数がなく、既存の翻訳よりも適した訳が考えられる場合がありました。 例えば、オブジェクト指向におけるCKメトリクスと呼ばれている6種については、演習で学ぶソフトウェアメトリクスの基礎 という訳書で扱われていますが、この訳よりも助詞を減らして名詞に近くした訳としています。

既存の翻訳文献がありそうで見つからなかった場合もありました。 技術のイノベーションライフサイクルを示す BRETAM sequence という図があります。 最初はガートナーのライフサイクルと同様に定番の訳が存在すると想定したのですが、BRETAM sequence でググったり参考文献を参照した和文を調べようとしても出てこなかったので、「黎明期」「模倣期」「理論化期」という訳語をあてました。

レビューでは直す理由を直感を超えて書き下す

本書は共訳書です。10名ほどの共訳者がいます。互いに訳文をレビューすることによって、その意味が伝わるか、意味が原文通りかを確かめ、より良い訳案を出しました。 語句、文法、技術的内容に起因する間違いを正すのであれば比較的簡単です。 ただ、翻訳のレビューにおいては、間違いではないものの良くない、自分ならこう訳す、と直感的に思える訳文に出会うことがたびたびありました。 そして、直す理由を直感を超えて書き下さないと、レビューの相手に伝わりません。 ただの好みであれば直す材料にはなりません。 なので、指摘の発端は直感だとしても、できるだけ論理的、客観的に理由を伝えるようにしました。

間違い、間違いではない、という言葉を使いましたが、両者は明確に区別できるものではなく、連続的な良し悪しという方が正確です。 以下に実例を示します。

  • これは技術的な慣用に基づく語句の問題で、わかりやすい方です。 f:id:masskaneko:20211207041327p:plain

  • これは英単語のニュアンスの問題で、わかりやすい方です。辞書ではこうなっている、と伝えると客観性が増します。 f:id:masskaneko:20211207041339p:plain

  • よいの方がよい。 f:id:masskaneko:20211207043256p:plain

  • これは原文の意味を考えると原文に無い前置きを付加すると意味が伝わりやすい例です。 伝わりやすさと原文への忠実さは相反することがあります。 f:id:masskaneko:20211207041351p:plain

  • 構造が難しい文に対するレビューコメントも難しく、長くなります。 f:id:masskaneko:20211207041410p:plain

ということを書くのは大変です。 「ここは不自然です」と書くだけなら5秒で終わりますが、その理由と修正案を書こうとすると10分かかります。

最後は日本語の能力

英日翻訳で最後につくるものはもちろん日本語の文です。 誰が訳しても、機械翻訳に任せても大して結果が変わらない文もあれば、前後の文脈や意味を考慮して構造を工夫したり、類義語や文語/口語の表現を取り入れるといった創造性が試される文もあります。 辞書も DeepL も、そうした創造性を発揮するための方法や知識を直接的には授けてくれません。 訳者の一人は日本語の作文と英日翻訳の本を読んだようですが 私は読みませんでした。 次に訳書を出す機会があれば学んでおこうと思います。

ET&IoT2021 講演 - 米国修士課程ベストセラーに学ぶ体系的ソフトウェアエンジニアリングの必要性

この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の3日目です。 2日目は読書感想文 でした。 今回は ET&IoT2021 という場で本書について講演してきた話を書きます。

ET&IoT とは

ET&IoT とは、主に製造業を中心とした業界関係者向けの展示会です。代表的なコンテンツは、電気や機構の部品、通信や画像処理などの要素技術、技術書、教育サービスといったものです。 そうしたコンテンツを提供する各社が広い会場にブースを設け、来場者が巡る形式です。 展示会と一緒に、技術のカンファレンスも併設されており、そちらで講演しました。 ET とは Embedded Technology, つまり組込み技術を指します。 この展示会と講演では組込みソフトウェアに関するコンテンツが多くあり、本講演もその1つです。

ET&IoTは、晩秋に横浜で、夏に大阪で開催されることが恒例となっています。 COVID-19 のため、2020年は全面オンラインの開催でしたが、2021年は物理的な開催に戻りました。

講演内容

www.slideshare.net

資料には多くのリンクが含まれています。以前の SlideShare ではリンクが有効だったのですが、現在は無効になっていますので、Google Slides でも公開しています。

講演の趣旨は、組込みソフトウェアに携わる人々(業界全体)に対し、ソフトウェアエンジニアリングを体系的に学ぶ必要性を伝えるというものです。 以下の4部分に分かれた構成としています。

  • I. 日本の組込みソフトウェア教育ではソフトウェアエンジニアリング体系が参照されていない疑惑
  • II. 実務/学術、モダン/温故知新のバランスに優れた体系 (本書の紹介)
  • III. 体系は更新される財産
  • IV. 体系の外側 ~いつかきた道ではない新たな道~

この講演は本書の出版を契機にしたものですが、内容紹介以外の方が多くを占めています。 というのも、本書を組込みソフトウェアに携わる方々向けに紹介するにあたり、その動機と価値を伝える方が大事だとみなしたからです。 なので、組込み業界ならではの背景を I で語り、本書の内容紹介を概ね II にまとめ、そもそも体系を参照する価値を III で伝え、 最後に、体系を学ぶだけでなく新しい体系を作り上げてほしいという前向きな話を IV として終わる、という構成にしました。

この資料では、経済産業省, IPA, JEITA, JASA といった公的機関発行の文献、2000年代からの組込み技術書、論文など、100件近い文献を参照しています。 特に I を書く際に多くの文献を参照しました。日本における組込みソフトウェア教育のサーベイ資料としても使えるのではないかと思います。

主に業界歴10年~の方向け、特に技術組織を牽引する層に刺さる内容になったのではないかと思います。 逆に言えば、ジュニアクラスの技術者には別の伝え方の方が良かったかもしれません。

本講演は、本書の監訳者である水野と共訳者である池田の2名で行う予定であり、そこへ私も加わることになりました。 結果的に一番多くを担当することになり、苦労しましたが勉強にもなり、とても満足しています。

核心を突く質問

講演の最中に SliDo で質問を募集しました。その中に本講演の趣旨に対する核心を突く質問がありました。 それは、一般的なソフトウェアエンジニアリングと組込み向けのソフトウェアエンジニアリングに共通要素があるか(少ないのではないか)? というものです。 なぜこれが核心を突いているかというと、講演者3名は、その共通要素が多いからこそ体系を学んでほしいと考えて講演したからです。 共通要素が少ないと想定すると、その前提が崩れます。

講演資料では、一般的なソフトウェアエンジニアリングの知識領域を SE、組込み向けのソフトウェアエンジニアリングの知識領域を EmbSE としたベン図を描き、組込みに応用できる領域と組込みならではの領域を示しました。講演者はこの重なる領域の大きさを広く見ており、質問者は狭く見ているということです。

f:id:masskaneko:20211202222640p:plain
講演資料より

この感覚的な見積もりによって、知識体系から自身の境遇に応用できるものがどれだけあるか、応用できるとして多少の応用で済むのか大幅な応用が必要なのかが判断されます。 仮に同じ課題に対して同じ応用方法に辿り着いた人々がいたとしても、基礎として採用できることを重視する人は「基礎は一緒」と言い、応用が必要なことを重視する人は「うちの製品、うちの業界ならではのことが重要」と言い、意見が分かれる可能性があります。これは組込みに限った話ではありません。

私は、応用可能と構えている方が応用の機会を逃しにくい と考えています。 組込みに関して言えば、業界規格準拠を謳うツールベンダーに高値を掴まされずに済むとも考えています。

もちろん、抽象化された知識を自身の境遇に応用することは重要です。組込みならば以下の要素を考慮する必要があるでしょう。

  • 製品ライフサイクル(1年?20年?)
  • 製品ラインナップ(A社向け、B社向け、ハイエンド、ローエンド…)
  • 製品と部品の価格
  • ユーザーの特徴(一般消費者、医者、建設業者…)
  • 求められる品質特性(セーフティ、ハードリアルタイム、プレイアビリティ…)
  • アップデートの市場需要(日々便利に、1年は変えないで…)
  • アップデートの技術的可能性(オンラインアップデート可否)
  • ハードウェア開発プロセスと組織
  • 試作機の配備容易性(1人1台、30人1台…)
  • 製品の計算機資源
  • GUIの有無
  • 業界標準・慣習(Automotive SPICE, FDA査察…)

それを多少の応用とみなすか、大幅な応用とみなすかは主観が分かれるのでしょう。 私は、7割くらいは多少の応用で済む領域だと構えています。

繰り返しますが、これは組込みに限った話題ではありません。 「うちの製品は、うちの業界は特殊だ」と思わずに、使えるものは使う姿勢が幸を呼ぶでしょう。

続く活動

とまぁ、資料作成に苦労し、核心的な質問もあり、勉強になった講演でした。

12月中に、別の業界向けに似た趣旨のお話をする機会があります。 ただ、伝え方は本講演とは全く別の方法になります。

本講演では、2005年から本格化した国策としての組込みソフトウェア教育を扱い、IPA, JEITA, JASA の取り組みを引用し、批判的な主張をしました。 願わくば、本講演資料が、当該取り組みの当事者や関連部門に届き、現在も続いているであろう組込みソフトウェア教育へのフィードバックとなることを望みます。 もし私への連絡がございましたら Twitter または LinkedIn からどうぞ。

ET&IoTには大阪で夏に開催される回があります。続くお話を2022年にできればと考えています。

あと、本講演のためのサーベイで勉強になったのは良いですが、動くものを作る時間が最近めっきり減ってしまったので、意識的に作る時間を確保しようと思います。