SSブログ

転職(4) [転職]

今日でちょうど一年となります。期待していた仕事を、過去一年間でできたのかで評価すると、残念ながら評価点はかなり低くなります。

個々のソフトウェアエンジニアが継続的に学習を続けて、組織全体が成長するという観点では、一年前と比べると良くなってきてはいます。しかし、その変化は、非常にゆっくりとしたものです。また、本を読めば書いてあることさえ、教育コースを作って教えなければならないという状況に、あまり変化はみられません。(「教育と場」)

自分自身の成長という観点からは、会社の業務を通しての技術的スキルの向上はほとんどないです。その主たる原因は、「Be the Worst」にはほど遠い環境だからかもしれません。一方で、ソフトウェア開発の最終成果物であるコードを軽視するというソフトウェア開発組織の文化を経験できたことは、「読みやすいコードを書くことの重要性」やそのための「継続した学習」を強調している私にとっては、逆説的に言えば、(未経験なことを経験しているという意味で)良い経験になっているかもしれません。

この一年間を振り返ってみると、今後何年も留まる理由を、残念ながら今は見いだしていません。

ちなみに、今日でちょうど丸一年ですので、今まで5社に勤務した中で、3番目に長い会社となりました。4番目はジャストシステムですが、364日在籍したので、1日少ないです。

JavaOne 2010 (3) [JavaOne 2010]

会社での仕事と休み」で書いたように今年のJavaOneには参加しません。

残念ながら、今年のJavaOneにはGoogleからの技術者によるセッションは無いようです。

An update on JavaOne

今年は、「Java Puzzlers」を含めて2つのセッションをJoshua Blochは予定していると以前聞いていたので、ちょっと寂しいJavaOneになるかもしれません。

Amazonで予約可能『プログラマー”まだまだ”現役続行』 [プログラマー現役続行]

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2010/09/04
  • メディア: 単行本(ソフトカバー)

来週発売ということで、予約可能になっています。

「『プログラマー現役続行』の改訂版(2)」)

玉ちゃんバス [その他]

小田急線玉学園前駅から、玉川学園コミュニティバス「玉ちゃんバス」が走っています。1998年5月に徳島から引っ越して玉川学園に住んだ頃には走っていませんでした。

玉ちゃんバスには、漫画家みつはしちかこ先生の絵(「ハーイあっこです」)が描かれていて、なぜなのかと不思議には思っていたのですが、調べたことがありませんでした。時刻表と運行ルートを調べたところ、先生は玉川学園在住と解説されていました。


書いたコードは説明できるようになる [プログラマー現役続行]

プログラミング経験のないAPIを使用してプログラミングしなければならない場合に、どこかのサンプルコードをコピー&ペーストして完成させたとしても、個々のAPIが何を意味しているかをきちんと理解し説明できることが重要です。

自分が担当して仕事として書いたコードであるにもかかわらず、説明を求めても分かりませんと言うのであれば、単なる「作業者」になってしまいます。そして、問題が起きても、本質を分かっていないため、自分では解決できなかったりするかもしれません。そうなると、ソフトウェア・エンジニアではなく、本当に「作業者」です。つまり、言われて指示されたことしかできませんということになります。

初めてのAPIを使用することは、自分の知識・経験を増やす良い機会であるにもかかわらず、積極的に深掘りして学ぶという姿勢ではなく、動けば良いという態度では、何年ソフトウェア開発に従事しても、初心者の域を出ないことになります。

技術者のレベルとソフトウェア開発の難易度(7) [プログラマー現役続行]

技術者のレベルとソフトウェア開発の難易度(6)」で技術者のスキルレベルと開発ソフトウェアの難易度の表を掲載しています。

経験の浅い人(スキルレベルが1から3ぐらいの人)を時間を要してもよいので、指導が必要な開発を担当させるのは「成長期待割り当て」とります。その場合、かなり根気よく待ったり、指導したりしなければなりません。当然、スケジュール通り進むとは限りません。

一方、短期間に開発を終わらせるには、そのレベルの人の場合には、「余裕割り当て」でなければならないかと思います。

したがって、「余裕割り当て」だと期待している場合に、実際には「成長期待割り当て」や「無理な割り当て」になっていると、スケジュールは完全に絵に描いた餅になってしまいます。

Jolt Awards [プログラマー現役続行]

例年ですとすでにJolt Awardsが発表されているのですが、今年はどうなったのかなと思っていましたら、再開(?)されたようです。

http://www.drdobbs.com/joltawards/

ちょっと探してみましたが、書籍に関して、どの本が候補になったのかのリストが見当たりません。しかし、書籍に関しては、「Excellence in Books」に次の書籍が選ばれています。

Masterminds of Programming (Theory in Practice (O'Reilly))

Masterminds of Programming (Theory in Practice (O'Reilly))

  • 作者:
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2009/04/18
  • メディア: ペーパーバック

出版された時に、購入しているのですが、途中まで読んで本棚に埋もれていました。日本語版『言語設計者たちが考えること』は、9月末にオライリー・ジャパンから発売されるようです。

「Productivity Award」として、次の書籍も紹介されています。

Sdlc 3.0: Beyond a Tacit Understanding of Agile

Sdlc 3.0: Beyond a Tacit Understanding of Agile

  • 作者: Mark Kennaley
  • 出版社/メーカー: Fourth Medium Press
  • 発売日: 2010/01
  • メディア: ペーパーバック

こちらは、読んでいないので、早速注文しました。

技術の伝承(3) [プログラマー現役続行]

長年、「プログラミング言語Java」コースを開催してきていて、「I/Oパッケージ」の内容は難しい内容だとは思っていませんでした。ファイル操作に関する常識的な内容だと思っていたからです。

しかし、最近は事業が変わってきているようです。社内での「プログラミング言語Java」コースで分かったことは、ファイル操作やネットワークのプログラミング経験がない人が多いことです。つまり、そのようなプログラミングを必要とする開発業務に従事したことがないし、教育で演習をしたこともないということです。そのために、常識的な内容だと私が思うことでさえ、内容が理解できないという事態が起きているのには、ちょっと驚きました。

第11期、第12期「プログラミング言語Java」コース [プログラミング言語Java教育]

今年の1月と2月から始めた社内の教育コースですが、過去の受講生と比べて、全体に予習準備不足が非常に目立ってきました。特に目立つのは以下の点です。
  • 練習問題を解いてこない(テキストの内容も練習問題の内容も理解できていない)
  • リフレクション(Interpret)の練習問題を完成させない
  • 課題のGUIプログラミングで最低限のことしか行ってこない
受講態度が悪い場合には、講師判断で落とすことは最初の説明会で説明してあります。現在の受講生28名の内、半分は講師判断で落とすことにします。

練習問題17.3、17.4、17.5は8月27日(金)の正午までに、全員再提出です。未提出あるいはできていなければ、コースの継続受講資格を失います(もちろん、誰かの解答をコピーしていると判断された場合には、コピーさせた方も含めてコースの継続受講資格を失います)。

次回の講義で、最初にリフレクション(Interpret)の問題の確認を行います。そこで、合格しなければ、継続受講不可として、その場で即刻帰ってもらいます(つまり、オフィスに戻って業務を行う)。それ以降のコース受講はできません。

次回以降、(講義でまだ未確認の提出済み練習問題も含めて)準備が不十分と判断された場合には、講義前に受講資格を失う可能性もありますし、講義中に受講資格を失うこともあります。

第1期から第10期までは、その時々によりますが、かなりの人数の人が脱落していますし、私自身の判断で落とされている人も多いです。

技術の伝承(2) [プログラマー現役続行]

大規模な組込ソフトウェア開発においては、一度作られてしまうと、10年以上そのソフトウェアをベースに保守や機能追加が行われる場合があります。たとえば、複写機メーカが提供するコピー・ファックス・スキャン・プリント等の機能を持つデジタル複合機は、巨大な組込ソフトウェアです。

その巨大なソフトウェアは、独自のハードウェアに対してOS(VxWorks、NetBSD、Linuxなど)を通して制御するソフトウェア群が構築されている訳です。その結果、不具合が発生した場合に、原因を究明するためには、ハードウェア、OS、それに自社開発したソフトウェアに関する広範囲な知識が必要となります。

過去、10年ぐらいを見てみると、ハードウェアやOSの基礎知識を持って新卒新人で入社してくる人はほとんどいません。プログラムカウンターやスタックポインターを知らなかったり、デバイス制御におけるポーリング制御と割り込み制御の違いを知らなかったりします。OSに関する知識もないので、1つのCPU上でどのような仕組みで複数のアプリケーションが切り替えられて動作するかは分かっていません。

このようなことを知らないという状況が解消されることを大学教育に期待するのは無理だと思います。その上、採用する企業側もそのようなことをきちんと学んでいるかを採用基準にしていないことが多く、プログラミングの経験がほとんどない人さえも採用してしまいます。

入社後にかなり徹底的に教育しなければ、膨大なソフトウェア資産(あるいは負債)で起きた不具合を解析できる知識を持つようにはなりません。そして、そのような知識獲得を積極的に行わせないと、不具合解析を経験のある40代後半から50代の人達が常に行うことになってしまいます。さらに10年以上その膨大なソフトウェアが使い続けられると、解析できていた人達が定年でいなくなってしまう状況が起きてもおかしくはないです。