SSブログ

初めての海外生活から30年 [その他]

生まれて初めて日本を出て、米国のEl Segundo, CAに赴任したのが、いまから30年前の1988年11月でした。29年間ずっと日本にしか住んだことがなく、海外旅行もしたことがなかったのですから、不安だらけの赴任でした。

3年のLビザでしたので3年以内で日本に帰国する予定でしたが、実際にはビザを一回更新して、4年半を米国で過ごしました。赴任したのが28歳でしたが、誕生日の直前だったので、ほぼ29歳からの4年半でした。今から振り返ると、24歳で就職して29歳で海外駐在できたのは幸運だったと思います。

当時Salientと呼ばれるプロジェクトのために、私と同年代の20名以上のソフトウェアエンジニアが富士ゼロックス社から米国西海岸の米国ゼロックスのソフトウェア開発組織に送り込まれました。北はSunnyvale, CAで、南はEl Segundo, CAでした。

米国ゼロックス社は、Altoワークステーションを開発したことで有名ですが、商業ベースのStarワークテーションを開発してきた組織へ多くのソフトウェアエンジアが送り出されました。私が配属されたグループは、VP Document Editorと呼ばれるワードプロセッサソフトウェアを開発しているグループでした。

Salientプロジェクトは、StarワークステーションのMesa言語で書かれたソフトウェアをSunワークステーションへ移植するプロジェクトでした。そのため、プロジェクトの終盤は、あまり楽しくないプロジェクトになっていました。赴任当時いた多くの優秀なソフトウェアエンジニアは、辞めていくだろうという思っていたのですが、実際に辞めていきました。

初めての海外が29歳、今は59歳です。時の流れを速く感じます。

コメント(0) 

API仕様を書く(まとめ) [API仕様を書く]

「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。
ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。

A Philosophy of Software Design

A Philosophy of Software Design

  • 作者: John Ousterhout
  • 出版社/メーカー: Yaknyam Press
  • 発売日: 2018/04/06
  • メディア: ペーパーバック

関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私が述べているAPI仕様に関する部分も含まれています。

翻訳はされないようなのですが、分かり易い英語で書かれていますので、ぜひ読まれることをお勧めします。

コメント(0) 

『Effective Java 第3版』研修 [プログラミング言語Java教育]

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)

第1章「はじめに」には次のように書かれています。
この本は初心者向けではありません。つまり、みなさんがJava をすでに使いこなしていることを想定しています。もし、そうでなければ、Peter Sestoft の『Java Precisely』[Sestoft16] などの多くの優れた入門書籍を検討してください。『Effective Java』はJava 言語の実用的知識を持つ人なら誰でも理解できるように意図していますが、上級プログラマに対しても考えるべき材料を提供しているはずです。
また、私自身も「『Effective Java 第2版』は、やはり初心者向けではない」と題する記事を書いています。

従来、富士ゼロックスグループおよびリコーグループで行っていたJava研修では、『プログラミング言語Java第4版』を学んだ後に『Effective Java 第2版』を学んでもらっていました。『Effective Java 第3版』に関しては、第25期Java研修の修了生を対象として翻訳原稿を使って「補講」を行いました。

『Effective Java 第3版』をきちんと理解しようと思うと多くの基礎知識を必要とします。少なくとも以下の3冊は読んでおく必要があります。

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

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

  • 作者: ケン アーノルド
  • 出版社/メーカー: 東京電機大学出版局
  • 発売日: 2014/05/10
  • メディア: 単行本
Java 5までの言語仕様、メモリモデル、シリアライズなどの基礎的な事柄が書かれています。

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

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

  • 作者: 柴田 芳樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/04
  • メディア: 単行本
Java 5で導入された言語拡張がどのように実現されているかも含めて解説されています(PDF版を公開しています)。

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

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

  • 出版社/メーカー: インプレス
  • 発売日: 2014/09/22
  • メディア: Kindle版
Java 8で導入された機能(ラムダ式やストリーム)およびJava 7で導入された機能が解説されています。

第25期Java研修生はこれらの3冊の学習まで終えていたので、補講として『Effective Java 第3版』を学習してもらいました。しかし、従来のJava研修では期間が長すぎる(一年半)ので、『Effective Java 第3版』だけを学習する研修を企業向けに半年間(月に1日で6か月)コースとして開催します。Javaに関する受講生の知識に応じて技術的な補足・解説を行いながら読んでいきます。

『Effective Java 第3版』研修の第1期は、12月から開講です。開催時期を調整中ですが、第2期も予定しています。

コメント(0) 

副業 [プログラマー現役続行]

最近は、企業が副業を解禁するしないという話題が目立つようになりました。今働いているメルペイ社では副業は禁止されていません。私自身は、技術雑誌の記事の執筆、技術書籍の翻訳、技術書の執筆などを2000年から副業としてやってきました。現在は、技術書籍の翻訳と企業向けの技術教育が中心です。

最初に副業を始めたのは富士ゼロックス情報システム社に勤務している頃で、就業規定に明確に兼業禁止規定がありました。しかし、技術系の活動に関しては、毎回社内で申請処理をする必要がありましたが、認められていました。

2008年9月にリコーへ転職したのですが、就業規則を何度読み返しても「兼業禁止規定」は書かれていませんでした。それでも、技術書の翻訳で社内申請をしようとしたのですが、当時の室長に「入社前からやっている活動であり、そのことは承知して採用しているし、申請するとそれを審査するために無駄に社内の工数が取られるので申請しなくてよい」と言われました。それ以来、リコー内では何も申請することなく、技術書の翻訳本を出したり、自分の本を出したりしていました。

リコーに勤務していた間には、頻度は年に1回程度でしたが新卒新人向けの技術教育を2社ほど他社向けにやっていました。1社は土曜日で、もう1社は有給休暇を取得してやっていました。これらは、最初だけ社内の申請を行いました。

2017年8月末で8年間勤めたリコーを早期退職しました。年齢的にも58歳に近くなっていたので、週4日勤務という条件でソラミツで働き始めました。それは、金曜日は個人で技術教育やコンサルティングなどの副業をする日に当てたかったためです。企業向け技術教育となるとどうしても平日ということになります。

今の若い人達は、ソフトウェア開発で副業をしている人も多いようです。私が20代から30代の頃は、そのような副業は不可能な時代でした。ソフトウェアを開発するには、会社に行かないとできなかった時代ですので、平日の夜とか休日にプログラミングの副業は無理でした。

今日のベンチャー企業やスタートアップ企業では、ソースコードコントロールやCIツールなどの多くがクラウドベースになっているため、自宅でもソフトウェアを開発できる時代になっています。

私の30代に同じ環境があってもソフトウェア開発での副業は無理だったかもしれません。当時は、朝7時に出社して12時間近く会社でソフトウェア開発をして、そして飲み会という日々だったからです。そして、休日出勤しない限り、土日にプログラミングすることはなかったので、休みには体を休めることができました。副業でお金をもらってソフトウェア開発をするには、若くても体調管理をしっかりとする必要があるかと思います。

コメント(0) 

デバッグを支える知識(3) [プログラマー現役続行]

以前、「デバッグを支える知識」として次の記事を書いています。
また、デバッグの科学的手法を「デバッグの科学的手法」で述べていますが、再度『ビューティフルコード』の第28章から引用すると以下の通りです。
1. プログラムの失敗を観察する
2. 観察と矛盾しない失敗の原因についての仮説を立てる
3. 仮説を使って予想する
4. 予想を実験でテストして、さらに観察する
 a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
 b. 満たさないなら、別の仮説を立てる
5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。
この「仮説」を立てるために必要なのが「知識」です。バグに直面したときには、仮説を立てるために必要な知識が不足していても、今日ではある程度ネットで調べて補えます。しかし、本質的な知識の欠如は、デバッグを阻みます。

メルペイ社で働き始めて、私にとってはGCP(Google Cloud Platorm)やKubernetesは初めての経験です。そもそもAWSもほとんどやったことがないです。結果として数時間ではなく、数日の単位で行き詰まったデバッグが今までに3件ありました。3件とも解決はしましたが、最近経験した3件目は、ほぼ完全に行き詰まった状態で、それまでの状況を再度整理して社内のSlackで流したら、「○○をやってみたら」という返事があり、それで解決しました。
※ 1996年9月に日本オラクルに入ってからデータベースを勉強した経験に似ています。

解決してしまえば、現象を説明できる原因、それにもらった助言の意味を理解できたのですが、私自身は、現象から原因への仮説を立てるのがほぼ行き詰まっている状態でした。このような経験により仮説を立てるための知識が少し増えたことになりますが、やはり、1時間で解決したかった種類の不具合でした。

コメント(0) 

オフィスと技術書 [オフィス]

今日、技術書は電子版と紙版のどちらかを購入できるものが多くなっています。電子版の場合、オフィスに書籍のための空間は必要ありません。一方、紙の本では物理的に置く場所が必要となります。私自身は色々な職場でソフトウェア開発をしてきたのですが、オフィスと技術書というテーマで過去を(忘れにうちに)振り返ってみたいと思います。

1984年に富士ゼロックスに入社して、Fuji Xerox 6060 Workstationの開発グループに配属されてワークステーションの開発に従事しました。机は普通の事務机でした。ワークステーションを開発しているといっても、机の上には何も無かったと思います。ソフトウェア開発用にVAX (780?)を使っていたのですが、端末は自分の机の上には無かったと思います。そのため技術書を持ってきても、すべて「机の上か袖机の中」のどちらかに入れていたと思います。この状態は、1988年11月に米国El Segundo, CAへ駐在で赴任するまで続いていました。

米国では個室で、SunワークステーションとStarワークステーションを使ってソフトウェア開発をしていていました。オフィスには3段ぐらいの「書棚」があったので、そこに自分の技術書を置いていました。1991年4月にゼロックス社のPalto Alto研究所へ転勤して、そこも個室でした。ここでも本棚があったと思います。結局、4年半の米国では、個室で、書棚があったので自分の技術書を置いていました。

1993年5月に日本に戻ってきたときは、勤務地が溝口にある神奈川サイエンスパーク(KSP)だったのですが、オフィスはパーティションになっていました。パーティションは上の部分が棚になっていたので本棚として使っていました。棚に入りきれない分は、袖机の中に入れていたと思います。

自分の本を会社へ持って行くときは、たいてい1冊ずつなので問題はないのですが、問題は会社を退職したときです。就職してから米国駐在、そして帰国してKSPへというのは富士ゼロックス内の話です。書籍もすべて会社の引っ越し費用で移動させていました。しかし、「退職」となると話が変わります。

KSPに勤務していた頃は、車も持っていなかったので、毎日少しずつ自宅へ持って帰りました。今から考えると段ポールに詰めて郵便局から送ってしまえばよかったと思います。

1996年9月から日本オラクルで働き始めましたが、書籍は、袖机の中に入れていました。在籍期間も短くて、多くの本を会社へ持って行くことはありませんでした。

1997年5月から徳島のジャストシステムで働いたのですが、パーティションになっていて上の方は棚になっていたので本棚として使っていました。半年後に新社屋に移りました。そこもパーティションでしたが、キャスター付きの3段の書棚が与えられていたので、かなりの数の本を会社へ持って行っていました。ジャストシステムを退職するときは、書棚を駐車場まで押して行き、本を車のトランクに移し替えて自宅まで持って帰りました。

1998年5月からは、富士ゼロックス情報システム(FXIS)で働き始め、海老名にあるプライムタワーというビルが勤務地でした。オフィスはパーティンションで、いつものように棚になっているので、かなりの本を会社に持っていきました。棚だけではたりず、袖机、さらに、別途共用のドロワーの一部を割り当ててもらいました。2009年8月末に退職するときには、かなりの数の技術書を会社に持って行っていたのですが、さすがに半分は会社に寄贈して、残り半分を近くの郵便局から段ボールで自宅に送付しました。

2009年9月からリコーの大森事業所で働き始めました。最初に違和感を持ったのは職場にほとんど技術書がないことです。フロアに書棚が1つある程度で、個人の机の上にはほとんどないことです。袖机の中にでも入れているのかと思いましたが、実際はそうでなく、全体として自分の技術書を会社に持ってくるという人が少なかったようです。

リコーに勤務した8年間は、富士ゼロックスグループ勤務の頃と比較すると職場の技術書の数は圧倒的にに少なかったです。海老名のプライムタワーの頃は、自分の会社(FXIS)や親会社(富士ゼロックス)のフロアで働いていたのですが、多くのエンジニアが自費で購入した書籍を会社に持ってきていたので、自分が持っていない本で調べたいときは、フロアを歩き回って、各人のパーティションの棚を探せば見つかったものです
※ 現在の富士ゼロックスや関連会社の職場では、ここで述べているような環境はなくなっているようです。

退職時の大変さを何回か経験して、リコーでは自分の技術書を会社には極力持って行かないようにしました。しかし、8年間勤務したあとの退職時には、段ボール箱で1箱分の技術書を着払いで会社から自宅へ送りました。

2017年9月からソラミツ社に勤務し、今年の6月からメルペイ社で働いていますが、今の個人的方針は、会社で参照するために置いておきたい「紙の技術書」は自分で購入しないということです。つまり、会社購入で、退職時にはそのまま置いていける状態にすることです。

富士ゼロックスグループでの勤務が長かった(合計で約23年間)ので、私は必要な技術書は自分の机から手が届くところに置いておきた方です。それは、自分の本や会社で購入した本に関係なくです。したがって、「技術書の購入も全額支援します」とサポートしてくれるにしても、各人が自分の机の上に置くための空間がないオフィスはどんなものかなと思います。普段、業務中に参照する技術書は、各人が手元に置いておけるオフィス空間が必要だと思います。

一方で、昔と違ってインターネットで検索したり、電子版の書籍を使ったりするのであれば、紙の本を置く空間がオフィスには必要ないのかもしれません。
コメント(0)