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年にできればと考えています。

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

実践ソフトウェアエンジニアリング第9版の感想

この文章は実践ソフトウェアエンジニアリング第9版アドベントカレンダーの2日目です。

私は Software Engineering: A Practitioner's Approach: 9th edition の翻訳活動に参加し、2021年12月1日に 実践ソフトウェアエンジニアリング第9版 としてオーム社より発刊されました。オーム社のサイトでは以下の紹介文が書かれています。

本書は米国においての第1版の発行(1982年)以来、世界累積300万部を超えるベストセラーの最新刊である第9版の邦訳書です。ソフトウェア同様、改良が続けられているソフトウェアエンジニアリングの「最良の手法」を解説している書籍であり、現役のソフトウェアエンジニアならびに学生諸氏におすすめする1冊です。

f:id:masskaneko:20211118165240j:plain
本書

そんな40年の歴史を持つ本の共同翻訳が始まった経緯は、監訳者が書いたアドベントカレンダーの1日目に記されている通りです。共訳者の私も知らなかった経緯が記されており、苦難があったと感じさせられました。私が翻訳に参加したきっかけは監訳者に誘われたからです。そういう経験もしておこうという軽い気持ちで参加しました。私を選んだ理由を聞いたら「日本語が書けるから」と言われた記憶があります。その意味は実際に翻訳をしてみてよくわかったのですが、翻訳に求められる能力についてはアドベントカレンダーの後日に書く予定として、今回は本書を読者として見た感想を、本書を引用しつつ書いてみます。

広く、頭から読みやすく、体系的な理解を促す

本書は、ソフトウェアエンジニアリング(工学)について、その意義と定義から始まり、プロセスモデル、要求エンジニアリング、設計手法、テスト手法、品質保証、変更マネジメント、プロジェクトマネジメント、リリース後のサポート戦略、人間的側面、新興トレンドといった広い領域を扱っています。

本書の第1章では、著者とゲーム開発者のキャッチーで重要な会話から始まり、ソフトウェアの定義、ハードウェアとの違い、ソフトウェアエンジニアリングの意義と定義が語られます。そして、続く章でプロセスモデルアジャイルが扱われ、要求や設計といった作る活動の章、テストやマネジメントといった開発を支える活動の章、という構成になっています。これは私にとっては読みやすい構成でした。プロセスモデルは個々の活動に大きく影響するので、最初に述べておくのが適切だと思います。

また、個々の技術や事例が列挙されているだけではなく、関連づけながら解説されているので、体系的な理解をしやすい文面になっていると思います。前後の章だけでなく離れた章同士の関連も示されています。以下はその例です。

  • 第3章 アジャイルとプロセス → 第7章 要求エンジニアリング(ユーザーストーリー)
  • 第16章 レビューの推奨手法 → 第3章 アジャイルとプロセス(ペアプログラミング
  • 第27章 ソフトウェアサポート戦略 → 第22章 ソフトウェア変更マネジメント

これは、SWEBOK や SQuBOK とは異なり、Roger S. Pressman がほぼ1人の著者である本書であるから成せる文面ではないかと思います。 (第9版は Bruce R. Maxim との共著ですが、全版の著者であるのは Pressman だけです)

温故知新からモダンまで

1982年の初版から改訂され続けている本書では、温故知新的な知識から近数年のモダンな知識まで扱われているように見えます。以下にいくつか抜粋します。まずは古い文献を参照している記述から。

本来のウォーターフォールモデルは「フィードバックループ」を考慮している[Roy70]のだが、このプロセスモデルを適用した組織の大部分は厳密な逐次型プロセスとして扱ってしまった。

知っている人にとっては有名ですね。

ソフトウェアパターンの歴史は、コンピュータ科学者ではなく、建築家のChristopher Alexanderから始まっている。(中略) [Ale77]。

これは知りませんでした。XPの本に書いてあった、かも。

「人間に適合する技術をつくるためには、人間について学ぶ必要がある。しかし、今私たちは技術だけを勉強しがちだ。結果的に、人々は技術に従うことを求められている。この傾向を逆転させるときがきた、人々に従う技術を作るときがきたのである」[Nor88]。

ユーザビリティに着目し初めた時代の文献が1988年発行だそうです。

対して、まぁまぁ最近のものだと思える記述も紹介します。

Googleは、UX設計を行うための5日間のスプリントを定義した[Kna16][Goo18][DXL18]。

上記と同じユーザビリティを扱う章で2016年と2018年の文献が参照されています。

将来は、超絶的な複雑さを克服するためにAIが広く使われるだろう[Har12b][Xie18]。機械学習はテストとバグ修正を助ける技術の1つである[Mei18]。超巨大プロジェクトが生み出す膨大なデータを理解するにはデータサイエンスが役立つだろう[Kim16b]。このような研究畑生まれのリポジトリマイニングは実務で使われつつある[Dye15]。

データサイエンスの応用事例です。

Google PlayAppleApp Storeのようなさまざまなオンラインストアでは、ユーザがアプリ対し星付けやコメントといったフィードバックができる。

これはユーザにとっては当たり前ですが、大学の教科書に載るのは面白いですね。

参照されている参考文献は、書籍、論文、Webページなど全て合わせて驚愕の500超です。本書(訳書)では、和訳された書籍についてはできるだけ参考文献ページに追記しておきました。

f:id:masskaneko:20211118165919j:plain
参考文献ページ

実務者視点の記述が所々に見られる

SWEBOK, SQuBOK のように、多数の文献を参照して体系だてられた書籍では文献に基づく客観的な記述が多く、あまり実務者視点の記述はありません。対して、本書では多数の文献を参照しつつも、実務者視点の記述、あるいは実務者を主観的に見た記述が所々に見られます。それらを以下にいくつか抜粋します。

私たちはいつも、ソフトウェアエンジニアリングは実際よりも急速に変化するのではないかと考えがちである。新しいプロセス、独創的な手法、刺激的なツール等の「持ち上げられた」技術が伝来し、専門家は「全てが変わる」と言う。

そう謳う人、考える人、いるよなぁと思わされます。

たとえ最先端技術を扱う開発であったとしても、規律が適用されていない現場は珍しくない。そのような現場では、現代的な手法を知らないままのエンジニアもいる。

データサイエンスや制御理論が得意な方のコードは構造化されてなくて読みづらく、普段の開発を feature branch で見せずにある日いきなりでかい Pull Request を出してくるみたいな話でしょうか。(架空の実話です)

ソフトウェアを開発する組織内の個々のメンバーの「創造性」に誇りをもつ傾向があり、SPIフレームワークを過度に官僚的で堅苦しいものと見なす傾向がある。

私も昔は「CMMIなんてコンサルの商売道具でしかない」って思ってました。

ソフトウェアエンジニアは知的労働者であり、仕事の進め方とプロセスの変更に対するトップからの指示に対して否定的な反応を示す傾向がある[Con02]

両方の気持ちがわかるんですよねえ。

…といった記述があります。これが原著の副題 A Practitioner's Approach であることの表れでしょうか。

CSとCEのことは載っていない

実際のソフトウェアエンジニアリングでは、コンピュータサイエンス(CS)とコンピュータエンジニアリング(CE)の知識も求められます。本書の名前は実践ソフトウェアエンジニアリングですが、本書だけでソフトウェアエンジニアリングに必要な一般的知識を網羅できるわけではなく、アルゴリズム、OS、ネットワーク、並列/並行処理、データサイエンスといったCSやCEの要素は別に学習する必要があります。また、本書の解説は、CSとCEの入門的知識があるものとして書かれています。

具体的な実現方法は載っていない

本書にはクラス図は載っていますが、ソースコードは載っていません。 ユニットテストとテスド駆動開発は載っていますが、xUnit のツールは載っていません。 継続的インテグレーションと DevOps が載っており、Git, Jenkins, JIRA というツール名も出てきますが、ツールの使い方は載っていません。

本書には、特定のプログラミング言語、アプリケーションフレームワーク、ライブラリ、ツールのことは載っておらず、抽象的な方法や教訓が書かれています。それゆえに本書の帯には「ソフトウェア技術者なら、この財産を活用しない手はない。」と書かれています。ただし、読者が本書を財産であると実感するには、読者が日頃ふれている具体的な環境と本書の内容を対応づけられる必要があります。

ソフトウェアエンジニアリングのはずだけど案外載ってない領域

私から見て「え、これ載ってないんですか?」という領域があります。

継続的インテグレーションは載っていますが自動テストは載っていません。システムテスト自動化標準ガイドの圧縮版みたいな節があると想像していたのですがありません。

テスト設計とプロジェクトマネジメントは載っていますがテストマネジメントは載っていません。テストマネジメントツールや、テストケースのマネジメント方法は載っていません。

機械学習モデルに対するテストは従来のテスト方法で対応できると書かれており、QA4AI機械学習工学研究会の立場と異なります。訳書ではQA4AIへのリンクを訳注として記しておきました。教科書に載るには新しい領域だと思うので、次の版で加筆されるかもしれません。

形式手法は載っていません。以前の版では載っていたそうです。

ソフトウェアプロダクトラインという言葉は出てきますが、その方法は解説されていません。

デバッグの方法は載っていません。どのようなログ設計をしておくのがよいか、一般的にデバッガで何ができるかは、業界やアプリケーション形態を問わない知見があり、載せる価値がある領域だと思います。

マルチプロセス、マルチスレッド、マルチコア、モジュラモノリス、マイクロサービスといった並行/並列/分散システムのための設計とテストの手法は載っていません。組込みとサーバーサイドで欲しいところだと思います。

リリースした後を扱うソフトウェアサポート戦略の章はあり、βテストや運用という言葉も出てきますが、A/Bテスト、カナリアリリース、ローリングアップデート、サイトリライアビリティエンジニアリングといったデプロイや監視の領域は扱われていません。Webシステムに限定されるので扱っていないのかもしれませんし、これから載るのかもしれません。

以上をふまえて、誰が何のために読むのがよいか

本書の対象読者は、原著でも訳書でも、実務者と学生とされています。ではどんな実務者や学生が何のために本書を読むのがよいかと考えると、以下の例が浮かびます。

  • [実務者個人の学習] 実務経験者が、自身の経験した実務と関連する本書の記述を探して読み、一段上の理解を深める。また、自身で経験していないものの見聞きしている領域の概略を知り、自身が担当する際に備える。その中で深く知りたい領域があれば、本書の参考文献を入手したり、類似書籍を探す。
  • [組織的な技術向上] 組織的なソフトウェアエンジニアリング能力を伸ばす責務と権限を持ち、実務経験豊富な実務者が、現状認識と改善方針を立てるために参照する。
  • [ソフトウェアエンジニアリングへの入門] CSとCEの入門的知識とプログラミング技術(大学や高専での学習または独学によるもの)を身に着けた学生あるいは新卒がソフトウェアエンジニアリングへ本格的に入門する際に読む。実務経験と知識を持つ者が教える形をとり、受講者の嗜好やカリキュラムに合わせて本書の内容を抜粋する。

本書は基礎を示す本として素晴らしいもの(財産)ですが、独学のための入門書ではないと判断します。独学で入門するなら、エクストリーム・プログラミングカイゼン・ジャーニー、チーム開発実践入門といった、チームで長く開発を続けることを語った量の少ない本の方が向いていると思います。そして、実務経験を積んでから本書を読むと、経験と入門書の内容を抽象度を上げて理解でき、周辺領域も理解しやすくなり、業界や職種が少々変わっても通用する知識(財産)が手に入るのではないかと思います。