SSブログ
時の流れ ブログトップ

9/11から20年 [時の流れ]

2001年9月11日は、台風の影響だったと思うのですが朝から雨でした。こんな日は会社に行きたくないなと思いながら朝シャワーを浴びた後、浴室から出る際に体を拭いていたときに腰に痛みが走り、ぎっくり腰になってしまいました。これをきっかけに、一年以上(たぶん二年ぐらい)は腰痛に悩まされることになりました。

9月11日は、会社に行くのは無理になったので、ソファーで横になってテレビを見ていました。そしたら、アメリカ同時多発テロが発生し、実際にワールドトレードセンターにハイジャックされる航空機が突入するのを(たぶん生放送で)テレビで見ていました。

ちょうど『Effective Javaプログラミング言語ガイド』の出版準備が進んでいて、『Effective Java』の第1版となるこの書籍で、Joshua Blochは、「日本語版によせて」を次の言葉で締めています。
On September 11, 2001, a tragedy befell the world. I would like to dedicate this edition to all those who devote their energies to creation.

2001年9月11日に、悲劇が世界に降りかかりました。私は、創造に精根を傾けている人々に、本書を捧げたいと思います。
最初に送られてきた原稿は、もっと強い表現だったのですが、技術書としては強すぎるので、あえて書き直してもらったのが、上記の文章です。第2版からは、この文も削除されています。

その後の世の中の動きは、あまり覚えていません。私自身は、翌年の8月に米国のWebster, NYに赴任して、Xerox社で働き始めました。しかし、当時従事していたプロジェクトが中止となり、2002年1月31日には、Webster, NYを発って日本に帰国しました。

とても短い米国生活でしたが、2002年11月末には休暇を取って、西海岸へ行き、Sun Microsystems社を妻と二人で訪問して、Joshua BlochやNeal Gafterと会いました。その後は、日本でのJavaOneで二人が来日した際や私が米国へ出張した際に二人と何度か会っています。

20年という年月は、実際に経過してしまうと、あっという間でした。そして、昨年からのコロナによるパンデミックのために、まさか毎日在宅で仕事をする日が来ることさえも、20年前には想像さえしたことがありません。昨年は、急性心筋梗塞で救急搬送されて一命を取り留めることができ、親よりも先に亡くなるという親不孝をすることなく、今を過ごしています。
コメント(0) 

55歳 [時の流れ]

早いもので、すでに55歳になってしまいました。大学一年生の18歳の時に、大学のコンピュータセンターでコンピュータに触れてから、37年が過ぎたことになります。当時は、大学に行かなければ、コンピュータが使用できない時代でした。

今日では、電車の中やスターバックスで、MacBook Airを使用しながら、翻訳作業をしたり、メールを読んだり、プログラミングをしたりと様々なことができます。昔、「Star Trek: The Next Generation」を米国で見ていた1990年頃は、登場するタブレットは、どうやってメインのコンピュータと通信しているのだろうかとか、操作パネルがすべてタッチ式というのは本当に来るのだろうかと思っていましたが、今では、普通に自宅でiPadを使用しているわけです。

1988年から1993年までの米国暮らしでは、日本の両親とは国際電話で話し、2002年から2003までの(短かった)米国暮らしでは、父親とは電子メールでやり取りしていました。そして、ここ2年ぐらいは、iPadのFaceTimeを使用して顔を見ながら両親と話すことが多いです。

昔、Star Trekで見た世界は、一部を除いて、今では実現されているものが少なからずあります。しかし、大学に入った頃と今も変わらないのは、プログラミングは、頭の中で考えたことを、人が手を動かしながら行うということです。パンチカード、ラインエディタ、スクリーンエディタという時代から、マルチウィンドにEclipseやNetBeansなどのIDEへと、プログラミングの道具は、目覚ましく発展しました。しかし、創造的部分は、やはり、人の頭の中で行われるわけです。

その創造的な活動を、何歳になっても続けていきたいと思っています。

テスト駆動開発プロジェクトの経験(5) [時の流れ]

前回からのつづき)

ソフトウェア開発におけるテストの自動化やテスト駆動開発などは、それほど古い訳ではなく、2000年以降に徐々に採用されてきています。そして、今も、自動テストを整備することなく、テストを手作業で行っているソフトウェア開発も多いと思います。

その意味で、社会人となって従事するソフトウェアプロジェクトが、テスト駆動開発になっているのか、手作業でテストを行う開発なのかは、ソフトウェアエンジニアのスキルとして大きなギャップを生み出すかもしれません。

テストファーストでの開発では、最初にAPIを考えることが求められます。たとえば、小さな機能であっても、その機能を提供するAPIをどうするかを最初に考えます。そして、それから、テストコードを作成し、テストが失敗することを確認します。そして、実装を始めるわけです。

特に、これにきちんとした防御的プログラミングとしてのパラメータ値の検査を行うことをAPIに明確に記述することで、そのためのテストも作成します。また、すべての機能をテストするためには、どのようなテストを作成すればよいかを悩みながら考えるわけです。

一方、手作業でテストする開発では、意外とありがちなのは、APIを考えるのですが、正常のパラメータしか渡ってことないという前提で実装を始めて、正常ケースだけを実装してしまうことです。そして、実装が終わったと思った後に、部分的なテストだけを書いて、実装が終了したと判断するわけです。

テストファーストによる開発は、本を読んだら身に付けられるかというと、そうではありません。テストファーストによるテスト駆動開発では、ソフトウェアエンジニアに対して多くのことをきちんと行うことが求められます。APIを考えて、テストを苦労して作成して、それから実装するということを意識して繰り返すことで、無意識に行えるようになるまで開発経験を積んで行く必要があります。そのような状態になって初めて、未経験者に対して指導ができるようになるわけです。

技術的な知識を学ぶのは、書籍を読んだり、ウェッブで調べたりすればできるのですが、ソフトウェア開発では、普段の行動パターンとして、求められることも多くあります(「ソフトウェア開発組織が持つべきカルチャー」)。そのような行動は、実際に自分で経験していく必要があります。

その意味で、最初からきちんとしたテスト駆動開発のプロジェクトとに従事すると、新人であっても様々なことをきちんと行うことが求められ、本人が意識しなくても、強制的に身に付くわけです。しかし、そのような開発でない場合は、数年、あるいは、10年以上もソフトウェア開発を経験して、中堅となっても、テスト駆動開発を推進できないし、しないソフトウェアエンジニアになってしまう可能性は高いです。

Jenkinsを導入していても、ビルドを自動化しているだけ、何もテスト書いていなければ、テスト駆動開発ではないわけです。その意味で、テスト駆動開発の経験を問われた時に、Jenkinsを導入したことがあるという回答では不十分であり、期待する答えではないわけです。

テスト駆動開発プロジェクトの経験(4) [時の流れ]

前回からのつづき)

テスト駆動開発は、書籍を通してある程度は頭の中で理解できますが、それだけではかなり限界があります。やはり、日々の開発業務で実践していくことで、様々な経験を積めることになります。単体テスト程度や小さなプログラムでは、直面する問題の範囲も狭いものとなってしまいます。

しかし、そもそも、テスト駆動開発をほとんど経験したことがない人が多いのではないでしょうか。中途採用の面接をしていても、経験がある人はほとんどいません。経験がない上に、関連する書籍もほとんど読んでいない人は、即戦力としての中途採用としては不合格になってしまいます。

自動でテストするためには、モック、スタブ、あるいは、様々なハードウェアのエミュレータ/シュミレータを開発し、さらに、自動テストコードを開発するという追加の開発が必要になってきます。しかし、手作業によるテストには戻れませんから、すべての開発を継続していくことになります。一見、開発する量が増えるために、無駄に思う人も多いようですが、ソフトウェアエンジニアとしては、リファクタリングを行うことも含めて、高いスキルレベルと規律(躾?)が求められます。

したがって、このような開発には、新卒新人で参加できることが理想となります。なぜなら、このような開発がソフトウェア開発としては当たり前であることを経験することになるからです。そのため、2003年から行った大規模なテスト駆動開発では、毎年、必ず数名の新人を自分の開発部門に増員していました。
コメント(0) 

テスト駆動開発プロジェクトの経験(3) [時の流れ]

前回のつづき)

本来、テスト駆動開発では、すべてのテストの実行は短時間に終わらせるようにすることが必要です。しかし、開発が進むにつれて増えていく機能とテストコードにより、徐々に、テスト実行時間が長くなっていきました。

ある修正が他の機能に影響を与えていないかを、すべてのテストを実行することで、検証しようとすると1時間以上要するようになってきたのです。これは、単体テストではなく、システムテスト的に全体を動作させながらのテストの時間です。

開発者は、何らかの機能追加あるいはバグ対応の修正がシステム全体に副作用を与えていないかを確認するために、すべてのテストを実行します。そうなると、テストが完了するまで、待ちになってしまいます。なぜなら、自分の開発用PCですべてのテストを実行するからです。

そのような待ち時間に、次の開発(機能開発や障害調査)をできるように、開発用PCは一人2台(Windows用PCとは別)になるように購入していきました。開発者にとって、開発用PCは重要な道具であり、節約する部分ではないと思っています。古いPCを使用させることで経費を削減しているつもりでも、それによる開発効率の低下が、結果的に残業などの人件費の増大を招きます。その増加した費用は、PC1台の費用をはるかに上回ってしまいます。

その意味で、2009年9月に転職して、与えられたPCの性能の悪さは衝撃的でした(「開発環境(2)」)。たぶん、そのPCを一年以上使用していたと思います。現在は、Core i7(Quad Core)、16GBメモリ、1TB HD、23インチディスプレイのPCを(Windows用PCとは別に)、グループのメンバー全員に開発用に用意して、開発してもらっています。

つづく
コメント(0) 

テスト駆動開発プロジェクトの経験(2) [時の流れ]

前回からのつづき)

私自身の転職により、私自身が開発を行うことがなくなってしまったので、私にとっての6年間におよぶテスト駆動開発は終わりを迎えました。その開発は、すべてC++で開発したのですが、その間に、私自身は多くのことを経験したと思います。

書籍を読んで良いと思ったことは、日々の活動で実践してみて、良いか悪いかの判断したものも多いです。特に、英語版の『Clean Code』 で良いと思ったことは、実際に自分で試してみてということを行いました。

一方で、自分で書いていないコードのリファクタリングも行ったりしました。機能の実装が終わった(つまり、テストをパスするようになりました)と報告があったコードを、ある日見てみたら、あまりにも実装がひどいことに気付いたことがあります。

担当者を呼んで、リファクタリングするように指示しようと思ったら、その日は(体調不良か何かの理由で)休みでした。結局、その日は、テストコードがどれであるかを確認してから、私自身で一日かけてリファクタリングしたのですが、それでも、まだ不十分という状態でした。翌日も、担当者が休みというこで、さらにもう一日リファクタリングして、ほとんど書き直してしまいました。

テスト駆動開発だから良い品質のコードが書かれるということではありません。それは、あくまでも、開発者一人一人のスキルレベルに依存します。テスト駆動開発が良い点は、このように本人もしくは他の人がリファクタリングを行うことで、品質を向上させることができる可能性があることです。しかし、あくまでも、リファクタリングをきちんと実施することが求められます。

つづく
コメント(0) 

テスト駆動開発プロジェクトの経験 [時の流れ]

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年後には当たり前になっていたり、時代遅れになっていることになります。

つづく
コメント(0) 

あれからすでに10年 [時の流れ]

『Software Craftsmanship』を読んだのは、10年前の2002年3月です。

Software Craftsmanship: The New Imperative

Software Craftsmanship: The New Imperative

  • 作者: Pete McBreen
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2001/08/23
  • メディア: ペーパーバック

この本を読んだのをきっかに、もう一度、開発の現場に戻りたいと思い、私にとって2度目となる米国駐在を受け入れました。妻と二人で米国に向かったのが2002年8月20日です。42歳でした。

しかし、二ヶ月もせずにプロジェクトは中止となり、2002年11月の今頃は、特に日本から指示される仕事もなく、毎日会社に行っては、私が仕様を作成したC++用のライブラリのプログラマーズガイドを作成していました。翌年の1月末に帰国するまで、このプログラマーズガイドの執筆以外の作業を行った記憶はないです。

2002年11月には、妻と二人で西海岸を訪れて、その時初めて、Joshua BlochやNeal Gafterに会って話をしました。その時の写真が『プログラマー”まだまだ”現役続行』に掲載されている写真(p.47)です。

開発の現場に戻るということは、帰国後6年間従事したプロジェクトで実現したのですが、最近4年間は満足できるような開発が自分自身ではできていない状況です。

時の流れ [時の流れ]

昨日は、4月というのに寒い一日でした。半年に一回行っている歯の検査とクリーニングに行ってきました。シリコンバレーに住んでいた時に通っていた歯科の先生に、日本に帰国する時に紹介してもらった歯科です。1993年5月に日本に帰国してから、半年に一回のペースで通っていますので、すでに17年になります。

米国駐在中の治療とその後の定期検査・クリーニングのおかげで、今のところ、特に大きな問題はない状態です。その意味で、歯の健康に関して、米国駐在はもう1つの転機でした。米国でお世話になった先生も、高齢で、病院を閉められたと昨日聞き、時間はあっというまに過ぎてしまうことを、また1つ実感しました。
時の流れ ブログトップ