ソフトウェアエンジニアとして転機（２）

富士ゼロックスへの就職

就職先として選んだのは、富士ゼロックス株式会社でした。当時は、推薦状をもらって1社受けるだけで、落ちない限り次の会社を選ぶことはなかったのと、修士課程を出て不合格になることはまれだったこともあり、富士ゼロックスに就職することになりました。情報工学科の先輩で就職した人はいなかったのですが、当時としては、福利厚生（特に住宅補助）が非常に良かったという不純な理由で選びました。

入社後の塚原研修所での3か月の新人研修期間は、ほとんどがコピー機に関連する研修ばかりで、就職する会社を間違えたと思いました。

J-Starワークステーション

配属された開発部門は、当時のJ-Starを開発している部署でした。しかし、私は、J-Starではなく、独自のワークステーションを開発する開発グループに配属されました。J-Star関連の開発に従事するようになったのは、2年後の1988年からですが、J-Starおよびその開発環境であるXDE（Xerox Development Environment）は、時代の先端を行っているソフトウェアでした。就職した1984年（Windows 95もMacintoshも登場していない）で、すでに以下の機能を備えていました。

• ビットマップディスプレイとマウス
• マルチウィンドウ（J-Starはタイリングのウィンドウシステムでしたが、XDEは普通にオーバーラップするウィンドウシステムでした）
• Ethernetと各種ネットワークプロトコル
• レーザープリンター
• リモートデバッグ機能（別のワークステーションからデバッグできる）
• 依存モジュールを世界中のゼロックスグループ内のファイルサーバーから自動でフェッチする機能

これらすべては大学時代は全く想像もでできませんでしたし、見たことも触ったこともありませんでした。マウスを初めて操作し、マルチウィンドウシステムでドキュメントを作成しレーザープリンターで綺麗に印刷し、ファイルサーバーにドキュメントを格納したり、電子メールを使うという体験をしたのが1984年でした。そして、Starだけでなく、ゼロックスにはすでにSmalltalk-80やInterLisp-Dの統合開発環境も存在していました。

私は、J-Starの開発グループではなく、独自のワークステーションを開発するグループに配属されたので、上記の機能の多くを独自に開発することになります。

ソフトウェアエンジニアとして転機（1）

60歳を前に、これまでの人生でソフトウェアエンジニアとして転機となった出来事をまとめていきたいと思います。

九州工業大学情報工学科への進学

中学3年生になったときに、父の転勤で佐賀県の嬉野から山口県の下関に引っ越しました。高校は、下関西高等学校の理数科へ進学しました。当時、理数科は普通科と異なりクラスが一つしかなかったので、三年間、クラス替えなく過ごしました。

当時、家に電卓もない時代で、そもそもコンピュータを触ったことも見たこともありませんでした。それでも、コンピュータについて学んでみたいと思い情報工学科に進学することにしました。その頃、九州で情報工学科を持っている大学は、九州大学と九州工業大学の二校だけでした。自分の成績から判断して、九州工業大学の情報工学科へ進学することにして、幸い合格できて進学しました。

当時、九州工業大学は単科大学（学部はなく、さまざまな学科から構成され、現在の工学部がある戸畑キャンパスのみ）だったためか、一般教養の教科に加えて、一年生から専門教科も教えられていました。つまり、一年生のときから、プログラミングやコンピュータの動作原理などの基礎知識の教科がありました。

初めて学んだプログラミング言語は、Fortranでした。大学では、プログラミング言語だけでなく、コンピュータの動作原理、データ構造とアルゴリズム、コンパイラの動作原理とコンパイラの作成演習といったさまざなことを学びました。振り返ってみると、社会人になってから学ぶ機会がないような知識だったと言えます。

大学時代使ったコンピュータシステムで、今日では見かけることがない以下のようなものがありました。

• 80桁×24行の「キャラクタ端末」
• パンチカード、マークカード、紙テープ
• コアメモリのコンピュータ（実験で使いました）
• APL端末（APL言語に特化した端末。ALUを含むCPUの原理をAPL言語で記述した本で学ぶ講座がありました）
• 8インチフロッピーディスク
• 音響カプラー
• ラインプリンタ
• etc

ハードウェアは進歩していきますが、ソフトウェアに関する基礎知識を学んだがの大学でした。

HOLENETの開発

大学4年生になったときに、当時の安在教授の研究室に入り、重松保弘助手の下で、HOLENET（HDLC Oriented Local Area Network）というローカルネットワークの構築に行うことになりました。大学4年と修士の2年の合計3年間は、このHOLENETのハードウェア開発、ソフトウェア開発、そして、HOLENETを使った学生実験の指導を行いました。この3年間は、九州工業大学での6年間の中でも、最も楽しく多くのことを学んだ3年間でした。

HOLENETは、通信コントローラボード作りからでした。最初は、回路図の読み方から始まり、DMAコントローラとCPUとの間でどのようなタイミングシーケンスでDMA転送が行われるのか、割り込みとCPUの動きといったことを座学で学びました。また、HDLC/SDLC用の通信LSIを使うので、ネットワークプロトコルも当時はかなり勉強しました。ネットワークプロトコル関連では、当時の電電公社の横須賀通信研究所のデータ通信網研究室には、2回もインターンとして行きました。

実際の通信コントローラボードは、2枚の基板から構成され、1枚は1層のプリント基板であり、もう1枚はラッピングで作るというものです。その2枚1組の通信コントローラボードの5セットをほぼ一人で組み上げて、プローブが1つしかないオシロスコープだけで5セットをデバッグしました。5セットがある程度安定するまで何か月を要したか覚えていませんが、長い期間ハードウェアをデバッグしていました。ハードウェアが安定してきたら、その上で動作する通信ソフトウェアをZ80アセンブリ言語でひたすら書いてはデバッグしていました。

九州工業大学での最後の3年間は、ハードウェアのデバッグから、Z80アセンブリ言語でのプログラミング、ネットワークプロトコルと広範囲な経験をすることができました。

まとめ

九州工業大学への入学は、ソフトウェアエンジニアとしてのキャリアの始まりであり、その後のキャリアにとっての基礎を学ぶことができました。「コンピュータの基礎はいつ学ぶのか」でも書いていますが、今日では学んだり経験したりすることが難しいことの多くを大学で経験したと思います。

技術研修の予習

長年、いわゆるバイブル本を使った技術教育を行っていますが、昨年から始めた『Effective Java 第3版』研修では、事前予習での質問数がかなり少ないです。本来、さまざまな基礎知識を学んだ後に読まないと理解するのが難しいのが『Effective Java 第3版』なのです。そのため、通常のJava研修では、一年以上の研修の最後に学習してもらいます。

私のJava研修やGo研修の事前予習では、「読んで理解できていない箇所」を質問表に記入して欲しいのですが、そもそも、きちんと「理解できているか」という自問自答をせずに、流し読みしている人が多い印象を受けます。なぜなら、質問がない部分の記述に関して、「○○○○の部分はどのような意味か説明してください」と逆に私から質問すると、答えられない人がほとんどです。

感覚的なものに過ぎませんが、真剣に理解できているかと自問しなが予習する人ほど質問数が多くなります。逆に、質問が全くない人は、「完全に理解している」のではなく、「ほとんど理解していない」ことが多いです。

最近の例として、Go言語研修で多くの質問をされたのは@yosuke_furukawaさんですし、『Effective Java第3版』研修では、@orisanoさんです。

バグの修正の前に再現テストを先に書く

2003年以降、私自身のソフトウェア開発は、テスト駆動開発が基本です。ただ、私自身が開発せずに、指導やレビューを行ったテスト駆動開発もあります。

経験した中で大規模で技術的に複雑だったテスト駆動開発は、以下の二つです。

• 2003年2月から2009年8月：Linux/C++によるデジタル複合機コントローラソフトウェア
• 2013年7月から20015年5月：Linux/Goによるデジタル複合機コントローラソフトウェア

残念ながらどちらのプロジェクトも最終的なデジタル複合機製品とはなりませんでした。

コピー/スキャン/プリントなどの複合機※をテスト駆動開発でスクラッチから開発した経験やノウハウは、部分的にJaSST'18 Tokyoの招待講演とJaSST'19 Tokaiの特別講演で話しました。
※ 今日のオフィスにある富士ゼロックスやリコーなどのデジタル複合機のソフトウェアは、ソースコードの量として1,000万行に達しているようです。残念ながら、ほとんどが自動テストがないレガシーコードです。

テスト駆動開発の経験がない人がテスト駆動開発のプロジェクトに従事したときに、テストコードを書くことに加えて難しいのは「テストファースト開発」と「バグの修正の前に再現テストを先に書く」ことです。

不具合への対処手順

何らかの不具合が発見、あるいは報告されたときの手順は次のようになります。

1. 不具合の原因の調査
2. 不具合の再現テストの作成
3. 不具合の修正

1.で原因の調査を行って、不具合の原因を調べます。原因は、条件判定の漏れや間違いだったり、想定外の事象が発生していたりとさまざまです。

2.では、原因が分かったので、「パスしない再現テストを作成する」ことが重要です。そのようなテストを作成した経験のないエンジニアの場合、作成せずにいきなり不具合修正を行ってしまいます。不具合を修正したと報告を受けたときに、「再現テストは書いた？」と聞くと「書いていません」という返事をもらったことが多々ありました。

最後に不具合を修正して、2.で作成したテストがパスすることを確認します。同時に、既存のすべてのテストがパスすることも確認します。

不具合の原因によっては、再現テストを書くのが非常に難しことがあります。特に不具合の発生がスレッドのスケジューリングに依存する場合です。その場合には、ロギングを工夫して、テストコードからスケジューリングを指定できる機構を入れたこともあります。

まとめ

パスしない再現テストを書く習慣を持つことは重要です。テスト駆動開発を行っているのであれば、テストファースト開発と共に意識して行ってみてください。

テストファースト開発

（私自身のテスト駆動開発については、こちらにまとめてあります）

一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。

開発順序

現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。

1. 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述
2. 既存のAPIの実装の調査（新たなAPIの場合には似たAPIの実装の調査）
3. テストコードの作成
4. 機能の実装
5. リファクタリング

1.ではAPIの仕様を記述していきます（「API仕様を書く」）。既存のAPIの仕様変更に関しては、もともとの仕様がきちんと書かれていない場合もあり、その場合は、ソースコードを調べて仕様記述を追記することもあります。

2.では、既存の実装の作り（構造）とテストコードを調べることになります。新たな機能をどのように作ればよいか、理解できるまで調査します。理解できたと判断したら、3.へ移ります。

3.の開始に際して、修正を行うマイクロサービスの既存のテストのフレームワークでは、私が書きたいテストが書けない場合があります。その場合には、新たなテストフレームワークの構築を行います。実際、メルペイで最初に担当したマイクロサービス用に私が開発したテストフレームワークを導入することが多いです。

3.と4.は実際には繰り返し行っていきます。まず、3.でAPI呼び出しがエラーになることが期待されるテストコードを書きます。そして、期待されるエラーが返ってこない（実際には実装部分には単純にpanic("Not Implemeted Yet")と書いてあるだけ）のを確認して、4.としてその部分の実装を行います。

エラーの実装が終わったら、正常ケースのテストコードを書きます。この時点でも該当する実装部分には、panic("Not Implemeted Yet")と書いてあるだけなので、テストが合格しないのを確認して、実装を行います。

すべてのテストの作成とその実装が完了したら、コードを見直して、リファクタリングです（5.）。そして、最後にPRのレビューをTech Leadへ依頼することになります。

テストファースト開発について

上記の開発順序は、私個人の開発順序です。実際に、最後のPRのレビュー依頼を行った時点では、テストコードと実装の両方が揃っていますので、どのような順序で開発しているかは分かりにくいです。

私自身がテストファーストで開発している主な理由は、短い勤務時間で担当する開発を着実に間違いなく行うためです。私自身は、テストファースト開発を最近始めたのではなく、昔から行っています。しかし、今は強く意識して行っています。

課題

ペアプログラミングがほとんど行われてない職場では、各人がどのような順序で開発しているのかが分かりにくいという問題があります。

テスト駆動開発とテストファースト開発には、ある程度の規律を必要とします。たとえば、不具合を修正する場合には、原因を調査後に、「再現テストを書いてから実装を修正する」ことが求められます（これも一種のテストファーストです）。本来、そのような規律は、ペアプログラミングなどを通して強制して習慣化させる必要があります。しかし、PRを最後にレビューするという開発スタイルの開発組織では、難しいものがあります。

お勧め本

僕たちの厳密さの一つの例が、自動化したユニットテストをテスト対象のコードより先に書くというルールだ。たいていのプログラマーはすぐにコードを書きたがる。書き上がれば出来映えに自己満足して、そのコードのために自動テストを書こうという気にはなかなかならないものだ。こういった習慣をやめてしまうのは簡単だろうが、僕たちがコードに期待する品質には極めて重大なものなのだ。テストコードを対象コードの前に書くという規律により、常に守れるようになるわけだ。

リチャード・シェリダン著『Joy, Inc.』（日本語版、p.212)

ジョイ・インク 役職も部署もない全員主役のマネジメント

• 作者: リチャード・シェリダン
• 出版社/メーカー: 翔泳社
• 発売日: 2016/12/20
• メディア: 単行本（ソフトカバー）

---

スポンサーリンク

複業を20年

振り返ってみると私自身がまだ40歳であった2000年の初めからほぼ20年間複業をしてきました。1984年に社会人になって、1999年までは会社での開発業務という単一の仕事をしていたのですが、2000年からは主に次の三つです。

1. 会社での開発業務（マネジメントや社内コンサルティングも含む）
2. 技術教育や講演
3. 技術書の執筆（雑誌の記事を含む）や技術書の翻訳

1. 会社での開発業務

1984年4月に富士ゼロックスに就職してから、6回の転職を経て現在はメルペイで働いています。自分で実際にソフトウェア開発をしている時期もあれば、開発のマネージャをやっていることもありますが、現在は、毎日Go言語でbackendのサービス開発をしています。

社会人となってから、実際に自分でコードをほとんど書いていないかったのは、日本オラクル、ジャストシステム、富士ゼロックス情報システム（FXIS）での最初の5年、リコーでの8年です。プログラミングしていないといっても、FXISやリコーではさまざな技術レビューは行っていました。

おそらく、会社の仕事だけをずっとしていたとしたら、今も実際にプログラミングしながらソフトウェア開発をしていなかったかもしれません。マネージャとして管理職業務を行いながら、ソフトウェア開発を続けるには、複業を行っていたことが大きな要因かもしれません。

2. 技術教育や講演

2000年から2017年8月までは主にグループ会社向けの技術教育が中心でした。最も長く続けているのはJava研修ですが、それ以外にもさまざな技術教育をグループ会社向けに行っていました。技術教育によっては会社が売り上げを上げるものはありましたが、私自身は、社員として業務の一部として行っていましたので、技術教育で別途私に収入があるわけではありませんでした。

20017年9月からは、週4日勤務で働き、金曜日に個人として技術教育を行っています。ソラミツでは雇用契約そのものを週4日にしてもらって働いていました。メルペイではそのような雇用形態は（現在は）なく、正社員として働いています。しかし、金曜日は原則欠勤しています。もちろん、欠勤すれば不足労働時間に対する勤怠控除が行われ給与が減額されます。

地方での講演の依頼に対しては、多くは手弁当で、妻と旅行を兼ねて行くことが多いです。函館、鹿児島、岡山、高松、長野、徳島、仙台、新潟、名古屋などがそうです。

3. 技術書の翻訳など

2000年から技術書の翻訳を私的な時間に始めたのですが、同時に技術雑誌に記事を書くようにもなりました。雑誌の記事は2007年まで続いており、記事をまとめて単行本にしたのが『プログラマー現役続行』、『ソフトウェア開発の名著を読む』、それに『Java 2 Standard Edition 5.0: Tiger』です。

技術書の翻訳も、継続して続けており、翻訳を通して技術を学習したり、自分の知識を再整理したりしますし、著者と多くのメールのやり取りをすることも多いです。現在は、私にとって18冊目になる技術書の翻訳を行っています。

振り返ってみて

60歳を目前にしてプログラミングしながらソフトウェア開発を続けられているのは、複業をこの20年間を行ってきたからではないかと思います。それぞれの活動が、いろいろな側面で相互に影響してきたと思います。

何歳まで続けられるか分からないですが、まだまだソフトウェア開発を続けていきたいと思っていますし、複業も続けていきたいと思っています。

---

スポンサーリンク

JaSST'19 Tokaiで話しました

10月4日（金）に愛知県刈谷市で開催された「ソフトウェアテストシンポジウム 2019 東海」で「私が経験したソフトウェアテスト 〜 ワークステーション、組み込みシステム、ウェブサービス 〜」と題して話しました。JaSSTでの講演は、JaSST'16 Niigataが初めてでしたので、今回で3回目となります。JaSSTの翌日の土曜日は、トヨタ産業技術館、名古屋城、徳川園、徳川美術館と観光して、日曜に横浜に戻ってきました。

今回のJaSSTでは、昨年のJaSST'18 Tokyoでの講演内容を修正して、メルペイでの経験も追加した内容を話しました。

会場の刈谷市総合文化センター

私の講演は午後2時からでしたので、講演後はkyon_mmさんの「アジャイル井戸端会議」のセッションに参加し、その後は情報交換会ということで、参加者といろいろと話しをすることができました。

3年前の新潟のときもそうですが、多くのソフトウェア開発組織でまだまだテスト駆動開発や継続的インテグレーションが普及していないというのを痛感しました。「継続的インテグレーションは強みでなくなった」という記事を書いたのが7年前ですが、なかなか当たり前にならないようです。

現在、私自身はメルペイでbackendのサービスの開発をしていますが、短い勤務時間※に担当する新たな機能や機能修正を確実に開発するために、テストファースト開発に日々努めています。
※ 単に、私自身の勤務時間が短いだけです。

コンピュータの基礎はいつ学ぶのか？

かなり前になりますが、「ソフトウェア開発組織が持つべきカルチャー」と題した一連の記事で、「コンピュータの基礎を教える」という記事を書いています。

その中で、コンピュータの基礎として以下の3項目を挙げています。

• コンピュータの基本原理　CPUの基本構造、メモリー回路、割り込み動作、etc
• オペレーティング・システム　Linuxなどのオペレーティング・システムの基本的な仕組み
• データ構造とアルゴリズム　リスト、木構造、ハッシュテーブル、探索、O標記、etc

今日、これらの知識がなくても、ソフトウェア開発ができてしまいます。米国の大学のようにきちんとコンピュータサイエンスを学んだ多くの学生がソフトウェア開発に従事するのと異なり、日本では、文系の学生を採用して、社内で数ヶ月教育して、後は現場に任せる企業もまだ多いのではないかと思います。

長年、JavaやGoの技術教育を行っていますが、ソフトウェアを実行する環境における「スタックとは何か」、「スタックには何が積まれるのか」、「スタックのアドレスはどこに保持されているのか」といった「CPUの基礎」をきちんと分かっていない人がほとんどと言っても過言ではありません。

過去のブログの記事にも色々と書いていますが、さまざまな技術書の読書会や強制的な学習を通して、対象は限定されていますしたが、1998年から2017年ぐらいまでは、コンピュータの基礎を若手のエンジニアに学んでもらいました。

2018年6月からはメルペイ社でソフトウェアエンジニアとしソフトウェア開発を行っています。昔と違って、昨今はさまざな技術に関する勉強会、イベント、Meet Upなど盛んに行われており、メルカリ/メルペイでも多くを主催しています※。それらのほとんどは、最新のソフトウェア技術に関する内容が多いです。
※ 平日の19時以降とかに開催されることが多いため、私は一切参加していません。

そのような勉強会やイベントに参加している若手の人達は、最新のツールやフレームワークを学び、ソフトウェアを開発し、さまざまなツールやフレームワークを使いこなしていると思います。しかし、一方で、どれだけきちんとコンピュータの基礎を学んでいるのでしょうか。

今日のウェブ系のサービス開発では、フロント側もサーバー側も、コンピュータの基礎を知らなくても開発できてしまいますし、マルチコアの時代になっても使っているプログラミング言語の「メモリモデル」を知らないまま開発している人も多いと思います。そうなると、いつ「コンピュータの基礎」を学ぶのでしょうか。あるいは、一生学ぶことなく、ソフトウェアエンジニアのキャリアを終えるのでしょうか。

私自身がすべてを知っているとか学んだとかは思っていませんが、60歳を目の前にして、日々自分自身でプログラミングしながらソフトウェア開発をしていると、今の若い人達が60歳になる頃には同じようにソフトウェア開発している人がどの程度残っているのだろうか、ソフトウェアエンジニアとしてのキャリアを終える前に「コンピュータの基礎」を学ぶのだろうかと思うことが多くなっています。

第26期Java研修を開講しました

9月22日（金）に、私にとって通算26期目になるJava研修を開講しました。リコーITソリューションズ主催で、リコーも含めて15名の受講生でスタートです。鳥取事業所と秋田事業所からも参加されるので、インタラクティブ ホワイトボードを使って3拠点を接続しての研修です。

今回、二年ぶりにインタラクティブ ホワイトボードを使ったのですが、技術教育にはやはり便利です。テキストを表示しながら、その上に直接書き込んだり、遠隔地から書き込んでもらうこともできます。

従来のJava研修と同じで、『プログラミング言語Java第4版』から始まって、以下のテキストを使って一年半の長期コースとして、最初の一つの言語としてのJavaをきちんと学んでもらいます。現在翻訳している新たな技術書を使ってJava 13ぐらいまではカバーしたいのですが、一年半ではちょっと無理かと思いっています。

プログラミング言語 Java 第4版

• 作者: ケン アーノルド
• 出版社/メーカー: 東京電機大学出版局
• 発売日: 2014/05/10
• メディア: 単行本

Java 2 Standard Edition 5.0 Tiger―拡張された言語仕様について

• 作者: 柴田 芳樹
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2005/04
• メディア: 単行本

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

• 出版社/メーカー: インプレス
• 発売日: 2014/09/22
• メディア: Kindle版

Effective Java 第3版

• 出版社/メーカー: 丸善出版
• 発売日: 2018/10/30
• メディア: Kindle版

Kindle版：Introduction to Computing Systems: From Bits & Gates to C & Beyond 3rd Edition

Introduction to Computing Systems: From Bits & Gates to C & Beyond (English Edition)

• 出版社/メーカー: McGraw-Hill Higher Education
• 発売日: 2019/09/03
• メディア: Kindle版

紙の本はかなり高額ですが、Kindle版も発売になっており、5000円弱となっています。第2版が2003年ですから、16年振りの改訂となります。

この本の第2版に関しては、何度かブログで紹介していますが、その一つを再度引用しておきます。

この書籍は、前半は、コンピュータの仕組みを学ぶ内容となっています。それも、トランジスタから始まって、基本的なANDやOR回路、フリップフロップ、メモリ回路、ALUなどを順次説明していき、最後は、16ビットのコンピュータの回路まで説明していくというものです。練習問題も多く、勉強会では、基本的にすべての練習問題に取り組んでもらいました。

この勉強会は、私が属する事業部に配属されたその年の新卒新人は全員必須でした。さらに、週に3回も開催していたので、予習が追いつかないという状況だったようです。それで、途中から、週1回に変更しました。

書籍の前半が終わった時点で、後半への参加は、必須ではなくしました。後半は、C言語が解説してあります。しかし、C言語の単なる説明ではなく、コンパイルするとどのような命令が生成されるかや、関数呼び出しでスタックはどのように使用されるのかとかが解説されています。後半も、練習問題をすべて行いながら勉強会を続けました。

結局、この書籍の勉強会は、約3年を要しました。しかし、参加者は、コンピュータの基礎を学んだだけでなく、英語の専門書を一冊読むことを経験してもらったことになります。この本の改訂版が出版されたら、もう一度勉強会をやってもよいかなとは思っています。

ここで述べている勉強会の対象者は2005年度の新卒新人でしたので、読み終えたのが2008年となります。

この本は、米国の大学のComputer Scienceの一年生用に書かれており、実際に教えられています。日本の大学ではここまできちんと教えている大学はとても少ないのではと思います。

上記の引用している記事の最後に書いているように、第3版が出たので社内で勉強会を開催したいと思います。いつから始めるかは未定ですが、以下のスケジュールを考えています。

【開催日時】毎週木曜日 午前8時〜9時30分（90分）

基本的には事前割り当てなどせずに、勉強会の中で英語を日本語に訳しながら読んでいき、練習問題もその場で問いていきたいと思います。おそらく3年は要するとは思いますが、私が定年退職する前には終わると思います。希望者は社内のSlack（@yoshiki.shibata）で私まで直接知らせてください。

追記（2019年10月15日）

• 申込みはないので、一人で読んでいます。
• この本のサポートページは、Appendix Fに書いてあるURLではなく、こちらです。