SSブログ

回り道でも「人を育てる」が勝ち! [本]

「3人で5人分」の仕事を無理なくまわす! ― 「欠員補充ゼロ」の職場術

「3人で5人分」の仕事を無理なくまわす! ― 「欠員補充ゼロ」の職場術

  • 作者: 小室 淑恵
  • 出版社/メーカー: プレジデント社
  • 発売日: 2011/01/21
  • メディア: 単行本

idea 17 回り道でも「人を育てる」が勝ち!では、次の説明で始まっています。
 人を育てつつ成果を上げている人と、自分だけで成果を上げている人がいたとしたら、あなたは、どちらを評価しますか?
 私たちがコンサルティングをしている顧客企業の現場を見ていると、能力の高そうな後輩社員をライバル視して、自分のノウハウのみならず基本的な業務すら教えようとしない先輩や職場が多く、そのことでチーム全体の生産性が落ちていることにいつも心を痛めていました。

 「一人ひとりのメンバーが他のメンバーの育成にかかわるためのしくみはできないものか?」

 いつしかこの課題が、私の頭から離れなくなっていました。
 なぜ、後輩社員を育てないような事態に陥るのかといえば、企業側が人を育てることを評価していないからです。人を育てても、育った人間だけを評価するような体系では、「いつかこの後輩に抜かれてしまうのでは、仕事を教えるのは自分の不利にしかならない」と思ってしまい、後輩を育てようという気持ちを抱かせないからです。
 これでは、あとから入ってくる社員はなかなか一人前になれず、職場の戦力になっていきません。
残念ながら技術者の育成でも同じ状況、つまり、人を育てることを評価していない企業は多いのではないでしょうか。企業によっては、上司が部下と面談をして、年間の研修受講計画を立てたりするかもしれません。でも、それは上司の業務として行っていることが多く、実際にそのようなシステムで成長するかというと、そうでなかったりします。

育成というのは、日々の活動を通して行っていくものであり、研修を受講させたからとスキルが上がっているはずだとするのは間違っている場合が多いです。本来は、最低限の研修を受講させたり、教育をした上で、日々の活動でさらに指導できることが求められます。単に業務の指導だけでなく、継続して学習する習慣を身につけさせるために、指導者自身が勉強したり、勉強会を開催したりというのも含まれます。

残念ながら、「プログラミングを含むソフトウェア開発は若い給与が安い人がやるものだ」と思っているようなソフトウェア開発組織では、技術者としての人の育成も行われることはないですし、指導者も育っていなかったりします。そして、会社の教育制度も単なる「育成ごっこ」だったりします。

PDF版『Java 2 Standard Edition 5.0 Tiger 拡張された言語仕様について』 [Java]

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

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

  • 作者: 柴田 芳樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/04/1
  • メディア: 単行本


PDF版は、以下のリンクからダウンロードできます。
個人の学習用の使用以外は禁止です。

Kindle用日本語PDFの作成 [その他]

Kindleがやってきた(2)」では、AcrobatのDistillerを使用してPostScriptからPDFに変換する際に、日本語フォントがうまく埋め込めないと書きました。

PDFをAcrobatの「Adobe PDF」プリンターへ印刷する際に、日本語フォントを埋め込むことができると教えてもらったので早速試してみました。手順は、以下の通りです(Windowsで、Acrobat Xの場合です)。
  1. 印刷ダイアログでプリンターの名前として「Adobe PDF」を選択
  2. 「プロパティ」で「Adobe PDFドキュメントのプロパティ」ダイアログを開いて、「Adobe PDF設定」タブを選択します。
  3. 「システムのフォントのみ使用、文書のフォントを使用しない」のチェックを外します。そして、印刷。
作成されたPDFをKindleにコピーして、開いてみたら、正しく日本語が表示されました。

Kindleのソフトウェアもバージョン3.1にアップデートしたので、専門書も紙の本のページ番号を表示することができるようになりました(ページを開いた状態で「Menu」ボタンを押すと紙のページ番号が表示されます)。

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

私にとっては通算第15期になる「プログラミング言語Java」教育を社内のある事業部向けに4月から開催することになりました。コース開催に先立って、コース内容の説明を兼ねて「プログラミング言語Java教育を振り返って」という説明会を開催します。社内向け(つまり、社外には非公開)の説明会です。

2月22日(火) 16時30分~18時
新横浜事業所 2F 第2会議室

書籍『Java : The Good Parts』 [献本]

Java: The Good Parts

Java: The Good Parts

  • 作者: Jim Waldo
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2011/02/24
  • メディア: 大型本

出版社より献本していただきました。まだ、全部は読んではいませんが、Javaの発展の中心にいた人が書いた本というのは、新たに学ぶことがあるのではないか、あるいは、重要な事柄を再認識できるのではないかと期待して読み始めています。

まだ読み始めたばかりですが、第2章「型システム」では、インタフェースに関して次のように述べられています。
インタフェースを使う最大の理由を知るには、インタフェースがシステムの全体設計をどのように明確にするのかを知らなければならない。適切に設計すれば、ひとつのインタフェースはひとつの意味的な単位を定義するものになる。すなわちインタフェースとは、相互に意味を与え合うオペレーションのまとまりを定義するものだ。インタフェースはそれ自体、Javaプログラムや、それらプログラムを使ったシステムにおける、意味の基本単位と考えるべきである。このインタフェースと意味との関係は、一般的にはあまり理解されていないところだ。
『Java: The Good Parts』(11頁)
これは、非常に本質的な説明となっていますが、初心者にはおそらく何を言っているのか分からないと思います。1996年にJavaを独学し始めた頃の私もインタフェースを当時は全く理解できていませんでした。

同時に、十分な知識も経験もないエンジニアに重要なAPI設計をさせているソフトウェア開発組織は、最初から技術的負債を作り込んでいるし、きっとこのような書籍を読んだりもしないんだろうなと思ったりもしました。

書籍『Javaルールブック』 [献本]

Javaルールブック ~読みやすく効率的なコードの原則

Javaルールブック ~読みやすく効率的なコードの原則

  • 作者: 大谷 晋平
  • 出版社/メーカー: 技術評論社
  • 発売日: 2011/02/15
  • メディア: 単行本(ソフトカバー)

出版社より献本していただきました。内容としては、基本的なプログラミングのルールが書かれています。同意できない部分もありますが、当たり前のことが書かれています。しかし、この当たり前のことが初心者には意識できないことが多いかと思います。

いわゆる初心者本と同じように大きなフォントでコード例が掲載されています。また、次に読むべき参考文献は、何も掲載されていません。

開発環境(4) [プログラマー現役続行]

1984年に社会人となってから、様々なソフトウェア開発に従事しましたが、振り返ってみると実際にソフトウェア開発をしながら、チームもしくはプロジェクトのビルド環境の担当も何度か経験しています。

最初に経験したのは、1988年暮れから米国El Segundo市(ロサンジェルス国際空港の南)で従事したSalientプロジェクト(Xerox StarワークステーションをSunワークステーションへ移植するプロジェクト)です。私はVP Document Editorグループに属していたのですが、その時は、グループが担当するソフトウェアのビルドも担当していました。(「Mesa言語」)

グループの中でUnixを良く知っていたのが私だけだったためビルドも担当したのだと記憶しています。ビルドを効率良く行うために、分散コンパイルのためのプロトコルを独自に作ったりもしていました(10台近くのワークステーションを投入して分散コンパイルしていました)。

次にビルドを担当したのは、DS20プロジェクト(Fuji Xerox DocuStation IM200)です。Solaris 2.3、C++、マルチスレッドで、白黒でしたがデジタル複合機(コピー、ファックスなど)を開発した時です。この時は、かなりの量のコードを私自身は開発すると同時に、ビルド環境の整備も行い、1994年当時で毎晩ビルドを自動実行していました。

2003年から従事したプロジェクトでは、私自身はビルドは担当していませんが、DS20プロジェクトに従事したエンジニアも多く含まれていましたので、ビルドを夜間に自動で行うのは当たり前という環境が構築されていきました。このプロジェクトでは、部分的ですが、継続的インテグレーションを試行したりもしていました。

以上の3つのプロジェクトでは、私自身もかなりのコード(C++だけで10万行以上)を書いており、同時にビルド環境を改善していって、開発効率を向上させる努力をしてきました。

今の会社で昨年の10月から、若手の外部技術者と二人でビルドを含む開発環境を整備しています。これで4度目ということになります。すべて手作業で行われていた作業の自動化です(「コンピュータは作業を、人はクリエイティブな活動を」)。ただし、以前の3回と比べて違うのは、私自身は何も製品開発していないということです。

実は、この違いは精神的に非常に大きいです。以前なら、自分自身が開発を行いながら、開発グループあるいは部門をリーディングして、現場を巻き込んだ開発環境改善を行っていました。今回は、開発の現場が全く関心を示さない、むしろ、リーダクラスのエンジニアが開発環境整備を否定したり全く関わったりしないということです。

開発環境の整備に加えて、本来なら日々コミットして退社するなどの細かな開発習慣に対しても開発者に指示して身につけさせないと開発効率は本来上がっていきません。しかし、リーダクラスのエンジニアが現場に指示することは当然ありません。

ということで、今回のビルド環境整備では、以前の3回では意識していなかった事柄を認識したことになります。つまり、改善の意識が低い開発組織に対して、その組織の指揮ラインの横から何かを言っても精神的に徒労終わる可能性が高いということです。

開発環境」、「開発環境(2)」、「開発環境(3)

プロセス中心ではなく、スキル中心(2) [プログラマー現役続行]

プロセス中心ではなく、スキル中心」を一年前に書いています。この一年間に延べ1000人近くに技術者に対する教育を行ってきましたが、私の教育を受けたからといって、スキルがすぐに向上するはずはありません。

かなりきつい「プログラミング言語Java」教育を終了しても同じです。それは、最低限の基礎を学んだという事実だけであり、修得したとは異なります。つまり、基礎を学んだという事実をベースに、日々の開発業務という「場」でさらに指導を受けながら実践し、実践を通して修得していくことになります。

地道なスキル向上を行わずに、プロセスをいくら強化しても、開発組織としての開発力は向上しません。

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得

  • 作者: Dave H. Hoover
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/07/08
  • メディア: 単行本(ソフトカバー)

コンピュータは作業を、人はクリエイティブな活動を [プログラマー現役続行]

ソフトウェアエンジニアの中には、(手)作業を一生懸命行って、仕事した気になる人がいます。あるいは、開発組織の中には、手作業の手順を文書化して管理することを重要視していたりします。

単純な作業は、コンピュータが得意とするところです。ところが、それは、作業手順を自動実行可能なスクリプトとして人間が用意することで達成される訳です。

したがって、ソフトウェアエンジニアとしては、誰かから作業を引き継いだり、作業を指示された時に、「これはコンピュータにやらせるべきことか、それとも、やはり人間しかできない内容なのか」を考えることが求められます。そして、作業は積極的にコンピュータによる自動化を行うことを心がけることが重要です。

手作業や手順書の大きな問題点は、作業をきちんと行ったことを監査できないことです。作業手順が文書化されていても、実際の人間が間違いを繰り返せば、対策として、手順書をきちんと守ったかを確認するためのチェックリストを作成してチェックしようとなります。それでも、人はチェックリストをきちんとチェックするとは限りません。その状況で問題が発生したら、チェックリストをチェックしたかを確認するチェックリストを作って守らせるという無限チェックリスト地獄に陥ってしまいます。

スクリプト等で自動化されていてコンピュータが実行するのであれば、問題が発生したときに、スクリプトの誤りを修正して恒久対策を打つことができます。

作業を手作業で行うのか自動化するのかは、ソフトウェアエンジニアの個人の問題のように見えますが、実際には開発組織のカルチャの問題だったりします。何事も手作業で行うのが当たり前だと思っている開発組織では、新卒新人で配属されると、同じような考えに染まってしまい、それに加えて、Unix(Linux)ではなくてWindows環境だけでしか開発したことがないソフトウェアエンジニアの中には、一生懸命作業を行っていたりすることがあります。

コンピュータは作業を、人はクリエイティブな活動を」です。