API設計の基礎（仮題）（６）

夏に再開すると書いたのですが、その後、あまり進んでいません。相変わらず、第1章だけですが修正版をアップしました。

API設計の基礎（仮題）

ソフトウェア開発組織が持つべきカルチャー 007

カンファレンスへ積極的に参加させる

ソフトウェアエンジニアとしてのスキルアップに関しては、本来、会社に頼ることなく、自分の時間と自分のお金を使用することが重要です。そのため、講演（「ソフトウェアエンジニアの心得」）や教育などで次の言葉を紹介しています。

ソフトウェア業界で取り残されないようにするには、次の３つの事柄をあなた自身が認識することが重要です。

1. 重要な本、出版物を読み、主な専門的カンファレンスに参加すること。
2. あなたが今日読んだ情報は３年から５年で古くなるため、常に終わることのないプロセスであると言うこと。
3. あなたの会社は、良くても限られたサポートしか提供してくれないでしょうし、最悪何もサポートしてくれないと言うこと。

大多数のプログラマーやシステムアナリストは、自分の専門性が時代遅れにならないように維持することを会社に頼ることはできません。ソフトウェア業界で取り残されないためには、自分から進んで自分の時間（休暇さえも）や自分のお金を投資しなければなりません。

-- Edward Yourdon, Decline & Fall of the American Programmer

裏を返せば、組織内のエンジニアが井の中の蛙にならないためにも、開発組織としては積極的にカンファレンスなどに参加させることが必要だと言うことです。当然、業務として参加させるため、参加費用、交通費などが経費が発生しますが、その代わりにきちんと参加報告を書いてもらい、組織内で報告してもらえば良いのです。特に、若手の場合には、報告させることもトレーニングとなります。

そして、できるだけ多くのカンファレンスに、多くのエンジニアを参加させることも重要です。参加費用や交通費が必要なために、「一人だけ参加させて、その人が情報を展開すれば良い」という意見を聞くことがありますが、それではカンファレンスへ参加することに積極的なエンジニアを増やすことはできません。

もちろん、業務の関係や部門の経費予算の制約で人数やカンファレンスを制限する必要がある場合もあります※。それでも、本当に参加したいエンジニアは、自費で有休を取って参加します。しかし、組織として参加させることに積極的でない場合には、その組織内のエンジニアはカンファレンスなどに興味を持たなくなってしまいます。

※ 前職時代には、参加費用が有料の場合には参加人数を制限していましたが、無料のカンファレンスに関して、業務に支障がない限り、全員参加するように指示したりしたこともあります。

ソフトウェア開発組織が持つべきカルチャー 006

スキル向上に真剣に長期的に取り組む

Richard Gabrielの言葉を借りれば、ソフトウェアエンジニアとして一人前になるには10年以上要することになります。言い換えると、新卒新人で入社した若者を10年間きちんとスキル向上させなければ、10年後に会社を支える中堅エンジニアにはなりません。その点を認識して、ソフトウェア開発組織は、エンジニアのスキル向上に真剣に長期的に取り組む必要があります。

スキルの無い人々を、まともな教育をすることもなく、日々の開発できちんと技術指導もすることなく、開発に従事させれば、多くの障害が発生するのは明らかです。しかし、ソフトウェア開発を労働集約型と思っている組織では、個々のエンジニアのスキル以外の観点（プロセスやツール）で対策を打つことを検討します。知識集約型という認識であれば、スキルを重要視しますが、労働集約型だと思っている（あるいは、労働集約型にしたいと思っている）のでスキルの問題に抜本的に対策を検討したり、打ったりすることはしない訳です。

その大きな理由は、スキルの問題は、かなり長期的に地道な活動だからです。徒弟制度的に育成を行っている組織では当たり前に行われていることが、労働集約的な開発しか行っていない組織では、その地道な活動でさえ放棄してしまいます。つまり、「スキルの問題と言ってしまったら解決できない」と考える開発組織に限って、真剣に長期的な活動をほとんど行っていなかったりします。

「40代最後の年」で書いていますが、日本オラクルの初代社長である佐野力氏の次の言葉（正確には覚えていませんが）が今でも記憶に残っています。

5年後、10年後に日本オラクルを背負うのは、中途入社の皆さんではなく、新卒新人です。したがって、新卒新人は育てていきますが、みなさんは、即戦力として頑張ってください。

佐野力

教育、場、権限（２）

「教育、場、権限」では、私自身のソフトウェア開発の経験をもとに会社の中で若手のエンジニアの成長を後押しするには、次の3つの条件が揃っている必要があると述べました。

• 教育 － 基本的に知っておいてもらいたい事柄を技術教育や勉強会という形式を通して教えてく。
• 場 － 教育で教えたことを、設計レビューやコードレビューなどの日々のソフトウェア開発活動全般を通して指導していく。それにより、教育では伝えきれない部分を伝えていく。
• 権限 － 日々のソフトウェア開発での指導ができる組織上の権限。

そして、最後の「権限」に関しては、次のように述べています。

日々指導するには、ソフトウェアの開発組織ライン上の権限が必要となってきます。たとえば、チームを構成するメンバーでもなくそのチームリーダでもなければ、チームリーダが指導しないことをそのチームのメンバーに指導することは簡単なことではありません。

最近分かってきたことですが、これは、あるテーマでソフトウェア開発している開発組織のリーダとして組織ライン上の権限が本当は必要だということです。

たとえば、小さなテーマであれば少数のメンバーから構成されるチームのリーダーであり、大きなテーマであれば複数のグループから構成される開発組織の組織長かもしれません。どのちらの場合であっても、単なる肩書きではなく、開発している技術、成果物のレビュー、現場の開発者との日々のコミュニケーションを含む報告を受けたり指導したりと開発全般に対する活動と権限が必要なのではないかと思います。

組織ライン上の長であっても、現場のエンジニアとはほとんど会話することなく、直属の部下からの報告だけしか聞かないようであれば、実際の開発現場での問題点やソフトウェアの品質を自分で把握することは難しくなります。

組織外からアドバイスをしても、その組織自身が真剣に問題点を改善しようとしていない限り、アドバイスの内容を理解できなかったり、実行されなかったりということが起きます。たとえば、80年代のような手法で開発を行っている組織に対して、継続的インテグレーションをアドバイスしても受け入れられることはまれだと思います。

日本では徒弟制度的にソフトウェアエンジニアを育成して、組織を作っていくことが行われることはまれであり、開発メンバー全員が良い習慣を持つ組織を作っていくことは容易ではないのかもしれません。

技術書の翻訳（3）

2000年に『Javaリアルタイム仕様』を出してから、今年出した『Android SDK開発クックブック』でちょうど10冊目となります。翻訳作業は、会社の業務ではなく、私的な活動として主に自宅で出社前に行っていて、時には外で喫茶店などで行うこともあります。

翻訳作業といっても、翻訳するだけでなく、組版までを私自身が行っています。最初に出した『Javaリアルタイム仕様』『プログラミング言語Java第3版』の2冊とオライリーからの『アプレンティスシップ・パターン』は、出版社が組版を行っています。私自身で組版を行うようになったのは『Effective Java プログラミング言語ガイド』からです。そのため、索引作りまで自分自身で行っています。

組版まで行うことで、私自身が費やす時間が長くなってしまいますが、校正作業はすべて手元で行うことができます。組版を行うようになった最大の理由は校正作業です。出版社に組版をお願いする場合、校正作業に時間を要するため、全部自分で行うようになりました。

また、翻訳作業全体は、私一人ではなく、翻訳原稿をレビューしてくださっている知人達と妻に支えられて行っています。

『アプレンティスシップ・パターン』『プログラミング原論』『Android SDK開発クックブック』と3冊連続して途中休むこともなく翻訳を続けた後、ここ数ヶ月は休憩状態が続いていました。そして、これからの2年間は、今日時点ではまだ出版されていない3冊の技術書の翻訳を行う予定です。

You've got to find what you love

私が初めて見たApple製品は、会社で購入したLisaでした。当時、ワークステーションを開発するのに参考に購入されたのだと思います。LisaはMacintoshの前身機です。1984年のことだったと思います。

私自身が初めてMacintoshを購入したのは、シリコンバレーに住んでいた1991年頃だと思います。製品名は忘れましたが、その後、それを友人に売って、Quadra 800を当時の金額で5,000ドル出して購入しました。Quadra 800は、1996年にWindows PCを購入するまで使用していました。そのQuadra 800は、箱に入れられたまま書斎の奥のクローゼットの中にあります。日本に帰国してからPerformaを妻用に購入しました。

その後は、2007年にMacBookを購入するまでしばらくはWindows PCでした。最近は、iMacかMacBook Airかと迷うところですが、MacBookに20インチのディスプレイとキーボードを接続して使用しています。さすがに、外に持ち出すには重いので、外出用にはVAIO Xを使用しています。iPhoneやiPadはまだ持っていませんが、iPod nanoは愛用しています。

そして、スティーブ・ジョブスが亡くなり、改めてスタンフォード大学の卒業式での彼のスピーチを見ると、今の自分がこれで良いのかと色々と考えさせられます。

http://news.stanford.edu/news/2005/june15/jobs-061505.html

違和感

今日、多くの製品でハードウェア開発だけでなく、ソフトウェア開発が製品開発に占める比重が高くなっています。ソフトウェア開発もマイコンを使用し始めて、最初はアセンブリ言語から始まり、C言語やC++言語へ移ってきた歴史を持つメーカーも多いかと思います。つまり、日本ではアナログなハードウェアからデジタルなハードウェアへ発展する過程でソフトウェア開発の比重が高まっている企業も珍しくはありません。

ソフトウェア業界をリーディングしている米国のソフトウェア企業（マイクロソフト、Google、Oracle、Facebook等々）は、そのほとんどがベンチャー企業としての歴史を持ち、そこではソフトウェア開発が重要であり、そのためソフトウェアエンジニアは企業の中でも重要な役割を持ちます。当然のことながら、優秀なエンジニアを採用する必要があるため、採用面接にしても、日本とは全く異なる面接方式が取られている訳です。

一方、日本ではソフトウェア開発は、労働集約型の開発であると思われている、あるいは、思っているため、きちんとしたソフトウェアエンジニアを育成することが行われなかったりします。たとえば、新卒新人で採用した集団に対して、決められた教育スケジュールで決められた内容の教育を行ったりします。

普通に考えても、大学を出てきた時点で、大学時代に何を学んだかで大きく差があるのは当然です。そのため、情報工学と全く関係の無い学科の卒業生と、情報工学を専攻した学生とで同じ教育を行うことは、労働集約型開発の現れかもしれません。基礎知識やプログラミング経験が十分ではない新卒新人に対する教育と大学で学んできた新卒新人とでは異なった教育を行う必要があります。

このような集合教育が行われる背景には、一人前のソフトウェアエンジニアを育成するには年月を要するという認識の欠如と、そのためにはどのように指導・育成していくべきかという開発現場の思いが存在しないことが挙げられます。言い換えると、徒弟制度的にソフトウェアエンジニアを育てていく必要が日本企業こそ必要なのですが、その視点が全く欠けていて、頭数を揃えればソフトウェアが開発できるという発想で、単価が安いということでオフショア開発を推進したり、ソフトウェア開発は給与が安い若い人が行うものだという思っている人達が組織のトップにいたりします。

その結果、ソフトウェアエンジニアのキャリアパスを真剣に考えている日本企業は非常に少ないのが現状ではないかと思います。20年以上、自分自身でソフトウェア開発を続けながら、同時に、若手を育成していくということを同時に行ってきた人達が開発組織の中にほとんどいないのが日本企業の現状だと思います。その結果、実際のソフトウェア開発経験と言ってもほとんど無いか、若い頃に５，６年程度あったという人達が人事制度を設計するのですから、ソフトウェアエンジニアとしてのキャリアパスを考えるには無理がある訳です。

そのような人事制度の中で私がどう評価されるかということはあまり気にしていません。しかし、長期的な技術者の育成活動そのものが理解されなかったり、育成活動に対する分かりやすい成果指標を求められることには違和感を感じてしまいます。どんな違和感かというと、人事制度の役割には項目としてもともと書かれていても行っている人がいないため実質的な評価軸が存在しないということです。そのため、評価軸を求められることに違和感を感じる訳です。逆に言えば、組織としてもともと重要視されていない活動、あるいは、重要だとは分かっていても今まで行えていない活動だということかもしれません。

書籍『40代からのスターティングノート』

40代からのスターティングノート―あなたはもう、自分の人生シナリオを描きましたか？

• 作者: 関 眞次
• 出版社/メーカー: 日本経済新聞出版社
• 発売日: 2011/08/26
• メディア: 単行本（ソフトカバー）

少しSF風の小説として描かれており、人生の残り20年の計画を主人公が７つのFをキーワードに考えていく内容です。タイトルとしては40代ですが、40代後半から私のような50代が対象だと思います。7つのキーワードは、以下の通りです。

① Finale ― 人生の目標、仮のゴール
② Family ― 配偶者、子供、両親、親族
③ Field ― 活動の場。何をしたいのか？
④ Faculty ― 能力、技術。何ができるか？
⑤ Finance ― 財産、お金。生活必要資金
⑥ Friends ― 友人、知人。誰が本当の友だちか？
⑦ Fight ― 元気。やる気。心と体の健康

主人公である50歳の安部玲二の前に、14年後の未来の本人が現れ、iNoteというデバイスを与えて、それを通して7つのキーワードに関して主人公に考えさせるというストーリーです。パラレルワールドというSFの要素が入っており、途中で予想もしなかったような展開になります。

高度経済成長期であれば、60歳の定年退職を迎えてから、その後の自分自身の人生設計を考えれば良かったのかもしれません。なぜなら、組織を離れるのが定年になってからだったからです。しかし、今日では、組織を離脱するのは、定年に限られる訳で無く、独立、転職、あるいは早期退職など、早い段階で起こり得ることです。そのため、本書は、40代から自分自身の人生設計を考えてもらうためのきっかけとしての物語になっています。

私自身は、11月で52歳になります。ソフトウェア開発にどれだけ直接従事していたかということを振り返ってみると次のようになります。

1978年4月～1984年3月　大学で情報工学を学んだ期間です。
1984年8月～1996年8月　製品開発に従事し、米国駐在も経験した期間です。
1996年9月～1998年4月　直接自分でプログラミングをするという開発は行っていない期間です。
1998年5月～2003年1月　自分では直接プログラミングしなくても、技術教育やライブラリー設計をしたり、設計・コードレビューを多く行った期間です。途中、短いですが、再び米国駐在しています。
2003年2月～2008年12月　部門長でしたが、製品開発に直接従事し、設計からプログラミング・デバッグまで多くを行った期間です。
2009年1月～現在　残念ながら直接製品開発に従事していない期間です。

一方、2000年からは私的な活動として、雑誌の記事や書籍の執筆、技術書の翻訳を行っていますし、2009年からは一般の講演も行うようになっています。

この本のサブタイトルではありませんが、自分の人生のシナリオを描き直す時期かもしれません。