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の入門的知識とプログラミング技術(大学や高専での学習または独学によるもの)を身に着けた学生あるいは新卒がソフトウェアエンジニアリングへ本格的に入門する際に読む。実務経験と知識を持つ者が教える形をとり、受講者の嗜好やカリキュラムに合わせて本書の内容を抜粋する。

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

自由を得るためのフルタイム職からの離脱

これは退職エントリと称される随筆です。 転職エントリではありません。

その離れた職とは

2021年6月30日をもって日立製作所を退職しました。2017年4月よりソフトウェア工学の研究者として*1 約4年働きました。その前職は全社的な技術向上を目標とするソフトウェアエンジニアでしたので、当職は技術向上の意味において前職と通じるところはありながらも、より未来を見据えたポジションであったと捉えています。study の進歩を意識し、論文を書き、特許を書き*2、海外の大学で特別講義をすることもあったのは、平均的なエンジニアと比較して(能力ではなく職務として)研究者らしかったと思います。エンジニアとマネージャーに近い仕事もあり、開発組織と密接に仕事をしていた日々も多くありました。

主に関わった製品は、医療機器、自動車部品、企業向け機械学習搭載システムでした。この中で一番関わりが深かったのは医療機器であり、そのぶん実際のエンジニアリングプロセスと開発組織へ与えたインパクトも大きく、思い入れもありました。その一端は論文になっています*3 *4。品質・協働・環境という自分がソフトウェアエンジニアリングにおいて大事にしている理念*5 に沿うことのできた仕事として、自負できる実績とやり残したと思える結果の両方を含め、この先も忘れることはないでしょう。

それらの製品(事業)以外にも社内の公式技術コミュニティ*6を通じて関わったものは多く、コングロマリットと称される事業ポートフォリオを体感しながら互いの異なる常識をぶつけ合いつつ技術的な進歩を模索する機会はとても楽しいものでした。

本職では人に恵まれたと思います。賢い人、面白い人、頑張る人ばかりでした。上司ガチャ(上司は運と相性次第という意味のスラング)という言葉がありますが、4回引いて全部当たりでした。さらに、私の入社時期は4月だったので新卒入社の方々と知り合うことができたのも大きかったですね。そうして関わったきた人々の中にはプライベートでの連絡先がわかる方々がいますし、COVID-19 がおさまったらシンポジウムに顔を出すつもりですので再開する機会があることでしょう。

研究との向き合い

企業での研究職に就いたことを機に、以下のことを在職中に考えることがありました。

研究とは、開発とは、研究開発とは、工学とは、科学とは、研究者とは、開発者とは、基礎研究とは、応用研究とは、学術機関の研究とは、企業の研究とは、研究者は研究だけするのか、開発者は研究しないのか、研究課題と事業課題は異なるのか、学術界の会議と産業界の会議の違いとは、論文と専門書の違いとは、研究提案を通すスキルとは、提案/遂行/発表の適切な労力配分とは、研究のインプット元とアウトプット先として学術と産業には何割関わるのが望ましいのか…

関連しそうな本を読みつつ*7考えは進みはしたものの、増す疑問の方が多く、自身の言葉として説明できるには至っていません。

少なくともソフトウェア工学において自身の志向としてわかってきたのは、

  • 学術界から出る先端的な要素技術よりも、産業界の優れた企業から出る先端的な技術ではないものの製品全体・組織全体に影響を与えた事例の方が好み
  • 特定のエンジニアリングプロセスよりもバリューチェーン全体に関わりたい
  • 工学と製品のどちらかの進歩しか選べない状況があるとすると、迷わず製品の進歩を選ぶ(ただし、愛着の持てる製品であれば)
  • 実務者がもっと研究をするようになって(目の前の開発だけで精一杯というサバイバルモード*8を脱して)、実務者と研究者を行き来できるキャリアが一般的になれば事業も人も学問も進歩しそうだからそうなって欲しい

ということです。 最近知ったのですが engineering には大きく分けて work と study の意味があります*9。これを踏まえて先の志向を言い換えれば、study が進むことの価値と楽しさは認めつつも work をより重視する、ということです。キャリアについては、一定以上 work したら study できることがあるはず、一定以上 study したら work に戻らないとそれ以上の study は進まない、ということです。それが事業やキャリアの上で適切なのかといった議論、あるいはただの志向のぶつけ合いをしてみたいものですね。

去る理由 - それは事業の変化

そろそろ退職理由に入りましょう。退職理由には去る理由と進む理由があります。まず去る理由から。それは事業の変化です。

私にとって日立の事業といえば*10

  • 第一に、家電、自動車、医療、建設、エレベーター、工作機械
  • 第二に、鉄道、電力、ストレージ
  • 第三に、金融、公共、産業・流通

でした。正直、第三に挙げた事業を日立が営んでいることを入社するまで知りませんでした。新卒なら企業調査不足として一次面接で落選しそうな知識なのに、よく合格したものです。そして、ここ何年かで進んでいる事業再編*11 からして、トップマネジメントと私で大事にしている事業の異なりが大きくなっていると感じています。例えば、先述した医療機器事業は思い入れが出始めていた事業だったのですが売却されました。

友人のソフトウェアエンジニアと仕事を選ぶ条件を話していると(これまで20人ほどでしょうか)、製品と技術のどちらを優先するかは分かれているように思えます。好きな製品があるから技術的貢献に尽力できるという人と、まず携わる技術が大事で製品はこだわらないという人に分かれるという意味です。私は技術よりも製品(事業)で仕事を選びますので、事業再編の中で同じ技術分野に携われるとしても、その職能を発揮したい場が失われれば発揮する意志も失われます。

これは去る意味での退職理由ですが、次に何をしたいかを示すものではありません。思い入れのあった事業に携われたとしても退職が1年延びただけでしょう。

進む理由 - それは自由を求める打算なき狂気

進む理由を端的に述べるなら、自分と経済社会との関わりを根本から見直し、より自由を得るためです。何を作るか、何の問題を解くか、何を学ぶか、いつやるか、どのくらい頑張るか、さぼるか、もっと自分で選びたくなりました。少なくとも週5日というフルタイムでの働き方を一旦やめ、個人での開発、執筆、野菜の自給、狩猟、自然を中心とした動画制作ができるだけの時間と場所を得て、雇われ仕事をするにしてもフルリモートかつ週2-3日にしたいと望みました。

そうした自由を探求した生き方を表す既存の語句の中では、ホームステッディング*12半農半X*13、Living Anywhere*14 が近いでしょう。さらに言えば、アダム・スミスフリードリヒ・ハイエクの系列が説く自由主義と、個人が扱える技術の高度化(例:プロトタイピングボード、オフグリッド、廃材による建築)の先に、分業から解放され経済への依存を激減させ自由を得た人々が増える未来を見ていることが意思決定の背景にあります。

自由で茨の道には何年も前から憧れがあり、「いつまで会社で働いているのか?」という頭の中の声が年々大きくなり、COVID-19 によるリモートワークをきっかけに実家の庭で野菜を育て始めたら気持ちが決まりました(キマりましたとも言える)。そして、そのビジョンを実現する目処が曖昧なまま退職しました。一時的に収入は激減しますが、何年後かには退職せずに働いていた場合よりも高時給になることをめざします(高収入ではなく高時給なのが重要)。そのためには看板商材が重要で、しばらくはそれを育むことになります。打算と継続努力に優れた人であれば在職中に看板商材の を育てるところでしょうが、怠ける私には無理でした。

まだ狂気が足りませんが、多少狂った判断だと思います。もちろん冷静に金銭と機会の損失を算出する時間はとりましたが、脳内会議の結論は「死なないし、いけるっしょ!」で終了しました。およそロジカルシンキングが要求される職に就いている人とは思えない判断ですが、変人*15だからだと思うことにしました。在職中は現状から1ステップずつ重ねてゆく思考が支配的になっていたのを感じており、同時にそれに反発したい欲求も重なっていたのかもしれません。総じて、自由を求める打算なき狂気によって進んだと捉えています。

年内の活動

さて、目先は何をするのかというと…

共同で技術書を翻訳しています。その終わりが見えたら(8月?)一人でやってみたい翻訳と執筆に着手します。

30平米の畑を借り、夏の今では2日に1回何かが収穫できるようになっています。30平米は家庭菜園としてそこそこ本格的な広さですが自給には全く足りませんのでより広い畑を探しています。なお、自給の目的は少しでも経済から離れることなので農業の予定はありません。

畑の映像・温度・土壌酸性度の監視、タイムラプス撮影による振り返り、雨水の蓄積と水やり、といった機能を持つシステムを作ります。

職場近くの賃貸住宅を引き払って地方にある実家に引っ越しました。ただ、これは一時的なものです。隣に家のない100坪の土地が見つかったら、その1/4を家に充て、1/2を畑に、残りを鶏小屋とBBQ場にするつもりです。

8月に狩猟免許(罠)をとる予定です。鶏小屋を襲いに来たハクビシンでも捕らえたいところですが、鶏が先か獲物が先か…(鶏が先だよ)。

それらが進んだら YouTube でもやってみるかと考えています。

パートタイム、リモート、自分がユーザーとなるプロダクト、英語の日常的使用、Software Quality Engineer という条件を多く満たしていれば就労はありと考えており、探すことがあります。挙げた中では優先度は低いのですが、細く長くウォッチします。

おまけ

Amazon のウィッシュリストに種と苗を載せました。 プレゼントしてくだされば喜んで育てます。

*1:研究開発グループ, https://www.hitachi.co.jp/rd/research/systems/index.html

*2:特開2019-148859:フローダイアグラムを用いたモデル開発環境におけるデザインパターンの発見を支援する装置および方法

*3:医療機器ソフトウェアを対象とした包括的アセスメントのケーススタディ, ソフトウェアエンジニアリングシンポジウム2020

*4:大規模複雑化機能向け単体テストケース設計手法の提案, ソフトウェアエンジニアリングシンポジウム2020

*5:大抵の事業においてソフトウェアの品質に大きく寄与するには協働が欠かせず、特定職種・特定状況のプロセスで必要となる要素技術よりも、定常的な協働のための道具・通信・人員・制度・文化で表される環境の方が重要であるという理念

*6:日立・ソフトウェア革新部会, XP祭り2019, https://www.slideshare.net/masskaneko/xp2019-187703916

*7:新 企業の研究者をめざす皆さんへ, https://www.amazon.co.jp/dp/B0845QVWH5/

*8:エラスティックリーダーシップ, https://www.oreilly.co.jp/books/9784873118024/

*9:the work of an engineer, or the study of this work, https://dictionary.cambridge.org/dictionary/english/engineering

*10:実際には, https://www.hitachi.co.jp/products/index.html

*11:例えばこのニュース https://newswitch.jp/p/24439

*12:https://en.wikipedia.org/wiki/Homesteading

*13:半農半Xという生き方, https://www.chikumashobo.co.jp/product/9784480432063/

*14:https://livinganywherecommons.com/

*15:日立には「高度の発明を為すものは変人以外は期待し難い」に由来する博士号取得奨励の文化がある。ただし私は博士号を取得していないので、その意味で変人とは言い難い。https://www.hitachi.co.jp/rd/henjin/outline/whats_henjin/index.html

2020振り返り

「お前はいつまで会社で働いているのか?」
「この先もソフトウェア・エンジニアリングの仕事を続けるのか?」
「前よりマシになるのではなく、大きな目標はないのか?」
もうひとりの自分からの問いかけは何年も前から度々聞こえてきました。

2017年に転職したとき、それらの質問に答えられませんでした。 熟慮はしましたが、前よりマシになる思考しかできませんでしたし、この分野を生涯続けるという意志も持てませんでした。

突然現れ世を席巻している COVID-19 によって、私は通勤と出張から開放され、人生の優先順位について考える時間を得ました。 結果、経済に参加しない自由を持つという大きな目標を立てました。 もともと、会社で働くということは 他人のやりたいことに加担すること であり決して自分のやりたいことではないと考えていたこと、 アウトドアの YouTuber を何年もたくさん見ていて自給自足への憧れがあったこと、 在宅勤務を始めたのと同時にあつ森を始めたこと、 7月から実家の庭を借りて家庭菜園を始めたこと、それらが重なって目標を持つに至りました。

それは 2020/07/29 のツイート群に表れています。

  • 分業というと「この光ってるのは何の機械かわかる?マジな話おれはわからない。でもそれってクールなことなのさ。知る必要が無いのだから。」というバンドマンが言っていると思しき画像が第一に浮かぶ。そう、より自身の関心に集中するために、何かを任せてきたことはクールだと共感できる。
  • ある人の層が限りある時間を何かの分野に集中し、ときには別の何かに集中した層と議論し、知見を体系だてて発展してきたことによる恩恵は、日常生活に溢れている。
  • それができる基盤となったのは「あるプロセスを担当します」という主体が織りなす経済だ。そして、ラーメンも、Tシャツも、スマホも、個人で使うものは簡単に手に入れられるが個人だけの力では手に入らない世の中になった。
  • あるプロセスを担当する組織に貢献をすることは程度を問わなければ大抵の人にはできて、その対価としてラーメンやTシャツやスマホに変換できる貨幣を得られるようになった。
  • それをクールとは言えない価値観が私には芽生えてきている。ただし、分業による恩恵を否定するのではない。個人の生に対して部分的、関節的なプロセスに関わるか関わらないか、選べる自由を獲得することが次の Society, Industry のメジャーバージョンアップだと考える。

いきなりその姿になることはできないと考え、次のように目標を分解しました。

  • 自給する食料を増やすこと
  • 首都圏から海のある郊外に引っ越すこと
  • フルタイムからパートタイムになること
  • わがままを通すだけのスキルを身につけ、知ってもらうこと
  • 作る活動を増やすこと

これらについて、2020年のうちにどこまでできたのかを振り返ることにします。 目標を持った7/29より前のことについても、目標に寄与したことについて記します。

自給する食料を増やすこと

実家の庭を借りて経験ゼロから野菜を育て、土地さえあれば野菜の自給は不可能ではないと結論づけました。200m2 以上あれば、ですが。 2020年に着手した野菜は次の通りです。まずは育てられるかを確かめることを目的としたので多くの種類に手をつけました。

野菜 収穫成否 状態 雑感
ミニトマト 手をかければ多く収穫しやすくなる
きゅうり 瀕死 育ちは非常に良いが農薬必須な気がする
パプリカ 育ちが悪い
とうがらし 勝手に育つ
明日葉 x 育ちが悪い
パクチー 本場数枚までは案外繊細、あとは簡単
バジル 瀕死 案外繊細
ミニチンゲンサイ 簡単
葉ねぎ 簡単
レタス 簡単
小松菜 葉物の中でも一番簡単
ほうれん草 × 難しい、収穫ならず
ブロッコリー 苗から収穫まで3ヶ月、害虫駆除必要
えんどう豆 × 瀕死 豆苗から再生中、全然育たない
かぼちゃ × 買ったものの種から育成中
にんじん × 買ったもののヘタから再生中
キャベツ × 苗から育成中

葉物が一番育てやすいですね。特に小松菜は強い。スーパーで買ったものの切れっ端を植えると1ヶ月でまともな大きさになります。 同じ葉物でもほうれん草だけは育てられませんでした。

夏野菜と言われるものも1月現在そのままにしています。ミニトマトもきゅうりも11月、12月でも収穫できました。ただし育ちが悪くなりました。

害虫対策も学びました。以前はかわいい遊び相手だったバッタ君もただの害虫としか思えなくなり、見つけ次第殺すだけの存在になりました。 葉の裏に隠れているナメクジと青虫も潰すことも覚えました。 アブラムシだけは手で駆除することはできず、オルトランを使いました。 無農薬志向では全くないので躊躇はありません。

雑草を使ったマルチングも覚えました。草マルチと呼ばれているようです。覆わなかった箇所と比べると効果はあるようです。

肥料は安物の化成肥料とハイポネックスを月に1回使いました。違いがわかるような実験をしなかったので効果はわからずじまいでした。

コップひとつからはじめる 自給自足の野菜づくり百科 という本が参考になりました。個々の野菜の育て方だけではなく、どれだけの広さの土地のどこに何を植えるかという設計が書かれています。

動画では Self Sufficient Me をよく見ました。オーストラリアでの広い庭があることが特徴で、育てやすい品目、再生栽培、土作り、3週間の野菜自給自足生活が役立ちました。

塚原農園 というプロの農園チャンネルもよく見ました。大量に作ること以外はすべて参考になりました。それ以外にも近所の畑を写すことがあり、どれもレベルが高く見えるので参考にしました。

手間をかけた時間は週に2回30分ずつです。水やりはその時と雨任せでした。 7月は全く晴れず根腐れしてしまう懸念がありましたが生き抜いてくれました。 毎日面倒をみる必要はないと思います。しいて言えば害虫が多い時期は毎日10分でもチェックするのが良さそうというくらいです。

首都圏から海のある郊外に引っ越すこと

リモートワークをしながら郊外にある実家の野菜を毎週見にいくとなると、実家に引っ越した方が合理的です。 また、実家の庭は借りているもので、本格的に育てるときには自分で土地を買うつもりです。 自給ができるほどの量を育てるには200m2は欲しいので、自分の資産を考えると郊外でないと手に入らなそうです。

畑に適した土地と広さがあり、住める古家または住居建築OKという物件は多くありません。 さらに、海の近くに、車で30分で行ける場所に住みたいとなると、条件は狭くなります。 いくつかの不動産サービスを見張ったり、そこに載っていない土地を含めて足で探したりしました。

農地を借りる手も考えましたが、個人向けには手に余る広さばかりでした。 ではシェア畑ではどうかというと高くつくことがわかりました。 値段と広さについて丁度よいところがないかと探すと、市営の家庭菜園がありました。 それを借りるにしても郊外でないと良いところがありません。

結局、5ヶ月ほど探して候補は見つかったのですが、そのような物件の数が少ないだけに相場がわからず、それ故に資産の多くを払う決断ができていません。

フルタイムからパートタイムになること

週に何日働くかは経済に関わらない自由に関する主要なメトリクスと捉え、週5日というフルタイムから減らすことを目標としました。 また、自給ができるとしても何年も先の話でしょうから、当面は収入を下げるとしても一定まで、かつ総量は下がっても時給を下げないことを絶対条件にしました。

現職でそれができるかわかっていません。できないかもしれません。 できないなら転職するしかないので、条件に合う仕事があるのか探しています。 まだ納得できる候補は見つかっていません。

わがままを通すだけのスキルを身につけ、知ってもらうこと

  • リモートワーク
  • パートタイム
  • フルタイムの収入から下げない

という条件を通すには、雇用側から見て相応のスキルが必要でしょう。 身につけるだけでなく、こうやってブログに書いたり、LinkedIn のレジュメを更新したりすることによって雇用側に知ってもらうことも必要でしょう。 現職での交渉や転職活動よりもこちらが優先と考えています。 なので、この節についてはおそらく一般のブログを持つソフトウェア・エンジニアが書いているであろう学んだ技術や実績といった内容になります。

  • 情報処理学会 ソフトウェア・エンジニアリング・シンポジウム2020 にて論文発表:医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ
    • 大きな開発組織におけるプロセスの現状認識を工夫した事例を記したものです
    • これを書くためにアセスメントの本を10冊くらいつまみ食いしました (CMM, CMMI, SPICE, SaPID)。知識は増えましたが、肝心の知りたかった包括的なアセスメントにおいて適切に現状認識する方法が書いてある本には出会えませんでした。DevOps 実現の文脈でバリューストリームを描く本があれば、そっちの方が合致しているのかも。
  • Azure DevOps
    • 論文にある改善活動に関連して Azure DevOps を採用、現在でも欠かせない仕事道具になっています
    • 全員で使うツールを採用して実際に全員で活用できる状態に持っていくという経験は貴重でした
    • もともと使っていたツールからの乗り換え、セキュリティとメンテナンスに関する業務も経験できました
  • Azure の学習
    • Azure DevOps の使用を機に、7月に AZ-900 に合格、12月に AZ-400 に合格
    • Azure DevOps のコミュニティ TFSUG に参加
    • ほか、Connpass で Azure 関連の勉強会に参加、Cloud Skills Challenge (取り組み中)
  • アジャイルとプロジェクトマネジメントの学習
  • プログラミング
    • チケット~リポジトリ~チャットまわりを Python
    • コードを書く専門のポジションではないので機会が多いわけではないが必要
    • 機会を増やしたいところ。機会を増やすには「あ、それできますよ」って言ってサッと作ってスッと出せることが必要。
    • Python 力というよりはライブラリ力かも
  • 英語
    • 海外の大学で2時間の講義とワークショップを担当した。正直能力不足だと思うけど面白そうだったので飛びついた。相手もネイティブじゃないのでどうにかなる感じ。楽しかった。
    • もっと日常でも英語で話す仕事が欲しいところだけどない。お金払って機会を作るしかないのか、そこまでするか?と二の足を踏んでいる。筋トレのためにジム行きたくないのと同じ感覚。
    • 読む機会は論文かニュースか…といっても量が全然足りてない気がする
    • 聞く機会はYouTube…家庭菜園の参考にした Self Sufficient Me もその1つ。ただ映像と字幕で意味をつかんでいるから英語に勉強にはなっていないような気がする。
  • GitHub

果たしてこれらが私のわがままを通すだけのスキルを身に着け、知ってもらうことについて十分かというと疑わしい。 自分ならではのテクノロジーメソドロジーを打ち出せれば文句なしと考えます。 ツールを作って本を書くのが一番いいでしょうか。

作る活動を増やすこと

食料以外も自給できれば多少は経済から距離を置けるか?と思いついて木工に手を出しました。 ホームセンターで木材を買って部屋で使えるものを作る程度ならできるようになりました。 流木を使って材料を自給したいところですが、まっすぐ切ることが難しい壁がクリアできていません。

何かに影響を受けたかというと例えばこういった YouTube チャンネルです。

自給という言葉に焦点を当てるなら別のチャンネルもありますが、段階的に移行するのが無理だし最終目標もこうではありません。 * Primitive Technology * Primitive Skills

あとはこんなオモチャも買ったんで、海中を撮ってみたいな。 2020は家庭菜園を優先したので全然行けてませんが。

2021年は?

  • 野菜を1/4くらい自給できている
  • 海のある郊外に引っ越して畑を持つ

これは踏ん切りさえつけばできるだろうか。

  • フルタイムからパートタイムになること

目処がありません。引き続き模索します。

  • わがままを通すだけのスキルを身につけ、知ってもらうこと

着手しやすいのはこっち。現職+個人活動でがんばります。 とりあえず見えてる個人活動は AZ-204 をとって AZ-400 と合わせて DevOps Engineer Expert の認定を受けること、DASA の資格、とある洋書の翻訳。 現職は何か出せるかなあ。国際会議に通したいな。

  • 木工DIYででかいものを作る

野菜の次は卵かなと思っていて鶏小屋を流木で作ったろかと妄想してます。 が、野菜の次なのでまだまだ。

既に海中映像のチャンネルっていっぱいありますけど、演出なり釣り人目線なり潜水ポイントなり、まだまだやりようはあるはず。

やるなら YouTube オーディオライブラリの聴き飽きた曲じゃなくて自分で作りたいな。

鬼が笑い出したのでこの辺で。