ソフトウェアエンジニアと英語力

前職では長年、新卒新人は、業務扱いにして、英語の専門書を使用した読書会に強制的に参加させていました。転職後は、自分自身の部下を持つこともしばらくなかったので、希望者だけの勉強会だけを開催してきましたし、今も続けています。

今年は、2014年度の新卒新人が（派遣社員も含め）3名いますので、10月から半年間に限定して、週1回（1時間）の読書会に強制参加させることにしました。専門書を読む読書会ではなく、普段、開発に使用しているGo言語関連の資料を読むというものです（こちらです）。

新卒新人を、英語を読む勉強会に強制的に参加させると、最初は必ず次のような状況になります。

• 英語の基本文型を忘れている（中学校で習う？）
• 中学校・高校レベルの基本単語を覚えていない

技術書を読む場合の難しさは、1つの文が長いことです。特に、技術書は関係代名詞により長くなる傾向にあります。関係代名詞は、省略されることもありますし、代名詞と関係代名詞の両方に使用される「that」があったりします。

英文を頭から読んで理解するには、瞬時に構文を理解する必要があります。英文をかなりたくさん読むことを普段から行っていないと、頭から構文を理解するのは簡単ではありません。ソフトウェア技術者として高いレベルを目指すためには、英語の資料を躊躇なく読むことができるようになる必要があります。そのためには、まずは、頭から英文を理解できるようになる必要があります。

（つづく）

テスト駆動開発プロジェクトの経験

11年前の2003年9月末に、あるハードウェアを制御する最も低レベルのコンポーネントのインタフェース仕様書の最初のバージョンを、私は書き上げています。それは、それから6年間におよぶテスト駆動開発の序章でした。最初は、（親会社と子会社の開発者から構成される）約10名の小さなチームでした。

1990年代までは、テストと言えば手作業というのが当たり前のソフトウェア業界でしたが、2000年に入り、テストは手作業ではなく自動で行うことが当たり前なる時代の幕開けでした。今日では、テスト駆動や継続的インテグレーションは当たり前ですが、2003年は、Jenkinsもなく、CruiseControlも登場していましたが、広くは普及していなかったと思います。

1978年に大学に入学してプログラミングを学び始めてから、すでに25年が過ぎていました。大規模になると予想されるシステム全体のテストをすべて自動化するという仕組みを導入するというのは、私自身にとっても未知の経験でした。しかし、技術的には可能であり、テスト駆動開発にするのが正しいということで、最終的なシステム全体をどうやって自動テストするかまでの青写真を描いたのもこの頃だと思います（ひょっとしたら、翌年かもしれませんが）。

私がインタフェース仕様書を最初に書いたモジュール（コンポーネント）から、完全にテスト駆動の開発が始まりました。C++でマルチスレッドプログラミングを私自身が再び行う開発の始まりでした。

さらに10年さかのぼると、1993年5月には、4年半の米国駐在を終えて帰国しました。駐在時代の開発の継続となるFuji Xerox DocuStation IM200※の開発が本格的に始まろうとしていた年です。それからの3年間におよぶこのプロジェクトでは、私自身は、C++とマルチスレッドプログラミングを学びましたし、当時としては社内でも画期的だった夜間自動ビルドシステムを私自身で構築しています。

※　「商品・サービスの歩み」の1996年の欄に写真が掲載されています。1986年には、私が就職して最初に開発に従事した「Fuji Xerox 6060 Workstation」も掲載されています。

こうやって振り返ってみると、当時、画期的だと思った開発手法（夜間ビルドやシステム全体のテスト駆動開発）が、10年後には当たり前になっていたり、時代遅れになっていることになります。

（つづく）

朝型

過去、朝型について書いた記事を検索してみたら、以下の記事がありました。

• 自分への投資：継続した学習
• 「時間を守る」(2)
• 朝型力
• 通勤電車の書斎化

振り返ってみると昔から朝型ではありませんでした。高校生の時は、朝型ではありませんでした。大学の1年生と2年生の2年間は、通学が往復5時間だったので朝は早くは出ていたと思います。3年生から大学の正門から1分の所に住むようになって、全く朝型ではありませんでした。むしろ、昼夜が逆転してることもありました。

やはり、朝型になったのは就職してからということになります。