書籍『笑説これが北海道弁だべさ』 [本]
- 作者: 西本 伸顕
- 出版社/メーカー: 北海道新聞社
- 発売日: 2010/08
- メディア: 単行本
偶然、ネットで知って購入してみました。私が21歳の時に初めて聞いて「え？」と思った言葉に、「うるかす」「ゴミを投げる」「おばんです」というのがあります。一人で留守番している時に電話がかかってきて、「お米をうるかすのを忘れていたので、うるかしておいて」と言われ、頭の中で「？？？？」だったことを今でも覚えています。
妻は函館出身なのですが、新たな発見が多かったです。普段、妻からは聞いたことがない言葉で、私には全く分からないような言葉でも妻は分かるという言葉が多かったり、今更ながら、「それって方言だったの？」と妻から言われる言葉があったりしました。
内容が一部以下のページに紹介されています。
http://www.furano.ne.jp/saladhouse/html/dictio.html
Jolt Awards: The Best Books [プログラマー現役続行]
今年のJolt Awardsの書籍に関するFinalistが決まったようです。
http://drdobbs.com/joltawards/231500080
以下の6冊です。
翻訳が出ているのは、次の1冊です。
一年間で全部読むとなると、2ヶ月に1冊のペースで読み続けないといけないことになります。
http://drdobbs.com/joltawards/231500080
以下の6冊です。
Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))
- 作者: Martin Fowler
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/10/03
- メディア: ハードカバー
The Art of Computer Programming, Volume 4A: Combinatorial Algorithms, Part 1
- 作者: Donald E. Knuth
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2011/01/22
- メディア: ハードカバー
- 作者: Michael Fogus
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2011/03/28
- メディア: ペーパーバック
- 作者: Bruce A. Tate
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2010/11/10
- メディア: ペーパーバック
- 作者: Matthew A. Russell
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2011/02
- メディア: ペーパーバック
- 作者: Jez Humble
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/08/06
- メディア: ハードカバー
翻訳が出ているのは、次の1冊です。
- 作者: Bruce A. Tate
- 出版社/メーカー: オーム社
- 発売日: 2011/07/23
- メディア: 単行本（ソフトカバー）
一年間で全部読むとなると、2ヶ月に1冊のペースで読み続けないといけないことになります。
手作業から自動化（２） [プログラマー現役続行]
先週の金曜日、土曜、そして月曜と3日間、シェルプログラミング（csh、bash）を行っていました。あるチームが手作業で行っていたクロスコンパイルのビルド手順を自動化してJenkins （http://jenkins-ci.org/）で運用するためです。
手順の中で一部のファイルの内容を変更するという「作業」が記述されている箇所も多く、それらのファイルを自動で変更するようにスクリプト化していきます。一部用意されているスクリプトの内容も確認しながら、無駄な処理を変更したり、簡素化したりということも行いました。
本来ならもっと早い時期に担当する開発チームが行うべき自動化なのですが、開発の終盤まで手作業で行われていました。私自身が3日間弱（途中でミーティング等がありましたので）の工数で行った作業を、開発の初期から行ってもらっていれば、おそらく、目には見えない多くの手戻り工数を削減できていたのではないかと思います。
ビルドの自動化は、プロジェクトが始まった当初に整備しておく必要があります。そして、1990年代までの夜間ビルド方式ではなく、今日では継続的インテグレーション（Continuous Integration）の時代です。自動化することで、人が犯す誤りを早期に発見し、それを修正し、無駄な手戻りを無くす必要があります。
「手作業から自動化」
手順書に従って、記述されている「作業」をスクリプト化してテストしていくのですが、手順書の内容が分かりにくかったり、内容が不足していたりということが多々ありました。作業はコンピュータに、人はクリエイティブな活動を
手順の中で一部のファイルの内容を変更するという「作業」が記述されている箇所も多く、それらのファイルを自動で変更するようにスクリプト化していきます。一部用意されているスクリプトの内容も確認しながら、無駄な処理を変更したり、簡素化したりということも行いました。
本来ならもっと早い時期に担当する開発チームが行うべき自動化なのですが、開発の終盤まで手作業で行われていました。私自身が3日間弱（途中でミーティング等がありましたので）の工数で行った作業を、開発の初期から行ってもらっていれば、おそらく、目には見えない多くの手戻り工数を削減できていたのではないかと思います。
ビルドの自動化は、プロジェクトが始まった当初に整備しておく必要があります。そして、1990年代までの夜間ビルド方式ではなく、今日では継続的インテグレーション（Continuous Integration）の時代です。自動化することで、人が犯す誤りを早期に発見し、それを修正し、無駄な手戻りを無くす必要があります。
手作業や手順書の大きな問題点は、作業をきちんと行ったことを監査できないことです。作業手順が文書化されていても、実際の人間が間違いを繰り返せば、対策として、手順書をきちんと守ったかを確認するためのチェックリストを作成してチェックしようとなります。それでも、人はチェックリストをきちんとチェックするとは限りません。その状況で問題が発生したら、チェックリストをチェックしたかを確認するチェックリストを作って守らせるという無限チェックリスト地獄に陥ってしまいます。関連書籍を紹介しておきます。
スクリプト等で自動化されていてコンピュータが実行するのであれば、問題が発生したときに、スクリプトの誤りを修正して恒久対策を打つことができます。
「コンピュータは作業を、人はクリエイティブな活動を」（2011年2月8日）
継続的インテグレーション入門 開発プロセスを自動化する47の作法
- 作者: ポール・M・デュバル
- 出版社/メーカー: 日経BP社
- 発売日: 2009/08/06
- メディア: 単行本（ソフトカバー）
- 作者: Jez Humble
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/08/06
- メディア: ハードカバー
「手作業から自動化」
書籍『人事部は見ている』 [本]
- 作者: 楠木 新
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2011/06/16
- メディア: 新書
タイトルとは違って、内容としては人事部という組織がどのようなものであるのか、人事部と会社内の他の組織との関連を、筆者の経験と多くのインタビューに基づいて書かれているものです。
人事部門の役割は会社の規模によって変わり、中小企業と大企業とでは、現場の社員が人事部門をどのように見なしているかや人事部門の仕事をどの程度理解しているかが大きく異なることが述べられています。人事部門を対象とする調査の結果として人事部門に関して次のように述べられています。
仕事ぶりを評価する声は希である。特に従業員数1000名以上の大企業の社員ほど突き放したような厳しい意見が多い。それに対して300名以下の企業になると、人事の仕事をある程度理解しているためか、提言を含むような意見があるのが特徴である。私自身の経験からも、大企業になるほど人事部門は遠い存在であり、どのような仕事をしているのかは分かりにくいです。逆に、中小企業ほど人事部門と話をする機会が多く、その仕事の全部ではなくてもある程度理解することができます。
『人事部は見ている』（p.55）
前職では600人程度の企業でしたので、採用、研修、評価と色々な場面で人事部門とは話をすることが多く、人事部門の仕事は結構大変なだと思っていました。一方、現在のような大企業になると、何から何まで通達だけで済ませてしまうということばかりであり、人事部門の仕事ぶりを理解するのは非常に難しいです。
ちょっと面白いなと思ったのは、「社内での相性の問題を解決する奇策」（p.60）で、自分の希望する異動に関して、次のようなことが述べられている点です。
自己申告書には、次に行きたい部門や取り組みたい仕事の欄はあっても、「誰と一緒に仕事がしたい」とか、「誰とは一緒に働きたくない」などと書き込む欄はない。この後に、実際に思いついた奇策の詳細が書かれています。確かに、相性の問題は悩ましく、仕事の内容、ソフトウェア開発で言えばプロジェクトの内容よりも、誰と一緒にプロジェクトを遂行するかの方が働くモチベーションには大きな影響を与えると思います。
『人事部は見ている』（p.61）
悪いAPIは伝染していく [プログラマー現役続行]
企業内のソフトウェア開発では、常に新規の開発とは限りません。既存のソフトウェアに新たな機能を追加したり、既存の機能を修正したりすることの方が多かったりします。
既存のソフトウェアに対して新規の公開APIを追加する場合に、既存の公開APIを参考に作ることがあります。その際、既存の公開APIの出来の悪さを、そのまま引きずった新規の公開APIを作成するエンジニアが多くいます。
特に、経験の浅いエンジニアに担当させた場合には、何が良くて何が悪いかも判断できず、「どうして、このようなAPI設計になっているのか？」とか「どうして、このようなJavadocの文章になっているのか？」と聞くと「参考にしたコードがそうなっていました」という返事がほとんどです。つまり、放置しておくと、悪いAPIは駆逐されるどころか、伝染していくことになってしまいます。
上級職人※以上のエンジニアがいない組織では、誰も良いAPIというものを理解していないために、最初に悪いAPIを作成するとそのまま何年も（あるいは10年以上も）伝染していくことになってしまう可能性は高くなるかと思います。
※ 技術者のレベルとソフトウェア開発の難易度（２）
既存のソフトウェアに対して新規の公開APIを追加する場合に、既存の公開APIを参考に作ることがあります。その際、既存の公開APIの出来の悪さを、そのまま引きずった新規の公開APIを作成するエンジニアが多くいます。
特に、経験の浅いエンジニアに担当させた場合には、何が良くて何が悪いかも判断できず、「どうして、このようなAPI設計になっているのか？」とか「どうして、このようなJavadocの文章になっているのか？」と聞くと「参考にしたコードがそうなっていました」という返事がほとんどです。つまり、放置しておくと、悪いAPIは駆逐されるどころか、伝染していくことになってしまいます。
上級職人※以上のエンジニアがいない組織では、誰も良いAPIというものを理解していないために、最初に悪いAPIを作成するとそのまま何年も（あるいは10年以上も）伝染していくことになってしまう可能性は高くなるかと思います。
※ 技術者のレベルとソフトウェア開発の難易度（２）
API設計の基礎（仮題）（５） [API設計の基礎]
延び延びになっていましたが、執筆を再開しました。まだ、第2章には着手していませんが、第1章の「1.5 公開ヘッダーファイルの配置」に加筆したのと、「1.7 補足：警告について」を追加しました。
（「API設計の基礎（仮題）（４）」）
（「API設計の基礎（仮題）（４）」）
書籍『人生で大切なことは、すべて「書店」で買える』 [本]
- 作者: 千田 琢哉
- 出版社/メーカー: 日本実業出版社
- 発売日: 2011/07/28
- メディア: 単行本（ソフトカバー）
本書のプロローグでは、本に関して次のように述べられています。
あなたの人生で、これから先に起こる未知の難題に対するすべてのヒントは、すでにどこかの誰かが本に書いてくれているということです。本の副題は、「20代で身につけたい本の読み方80」となっており、読書に関して80項目の内容から構成されています。その中からいくつか紹介します。
01 本を読むから時間に余裕ができる人生やお金について書かれていますが、ソフトウェア開発でも同じことが言えるかと思います。たとえば、若い頃に経験不足からくるひどいコードを書き続け、結果として高残業になり、多くの残業手当をもらっていても、継続的な学習をしなければ、30代や40代になった時には、全くスキルが向上しておらず、ただ歳を取っただけになったりします。
様々な会社を見てきて驚くべき事実を公開したいと思います。
みんなが忙しくしていて、やたらに労働時間が長い会社は倒産一直線に向かっているということです。
ピークを過ぎたら後は坂道を転がり落ちるだけなのです。
だから忙しい会社は要注意です。
これは人もまったく同じです。
最初の立ち上がりの際には誰もが不慣れなこともあって忙しいように見えますが、それが続いていくようではまるで成長していない証拠です。
いつまでも忙しい人に長期的なお金持ちは一人もいません。
今忙しくて儲かっているように見える人はいずれ必ず貧乏になります。
忙しいのはそれだけ他人に振り回されているだけなのです。
ゆったりと好きなだけ読書できるような時間のある人にいい知恵が授かり、ドッとお金も流れ込んでくるように人生はできています。
読書に限りません。
「忙しくて〇〇できない」というのが口癖の人には近づかないように注意しましょう。
お金の貧乏同様に時間貧乏も感染するからです。
〇〇があなたの本当に好きなことがあれば、すべてに最優先してやってしまうことです。
最優先で〇〇をやれば時間はいくれでも生み出せます。
忙しいから読書できない人は、読書がそれほど好きではないのです。
たとえ、投入されたプロジェクトが火の車であっても、若い頃からソフトウェア開発に関する様々な技術書や読み物を読みながらソフトウェア開発を行い、スキルを向上させている人は大きな差となって現れます。
以前、開発者不足分を補充するために、30代、40代の技術者を面談した際に、経歴としては様々なプロジェクトに従事しているにもかかわらず、技術書はほとんど読んでいないという人が多くいました。理由を聞くと、忙しくて読む時間が取れませんでしたという返事が多いのです。しかし、そのような人は、残念ながらソフトウェア開発に従事した期間に見合うスキルや見識を持っていない場合がほとんどです。
私自身は、Fuji Xerox 6060 Workstation(1986年発売）やFuji Xerox DocuStation IM200（1996年発売）の開発を行った20代、30代は高残業を行っていましたが、その中でも技術書の学習は継続していました。今日、「業務優先」という理由でほとんど読書（勉強）しない技術者が多いと感じています。そのような人達が製品としてのソフトウェア開発で「ビジネス資産」ではなく、「技術的負債」を作り続けていることになるのです。
本書は、技術者向けではなく一般的なビジネス書であり、読書に関する多くのことが述べられています。興味深い項目名を紹介しておきます。
02 いつも読んでいる人に面白い本が当たる
03 残業より読書したほうが給与が増える
04 読書をしてから実践すると成功率が桁外れに高まる
10 オススメ本は自分にしか見つけられない
11 できる人は文庫化までの時間を買っている
17 できる人の本棚には「初版」が多い
21 本を借りて読む人は、自分も一生使われて終わる
36 本から学べなければ何からも学べない
53 本にかけたお金とその人の年収は比例する
54 本の買い過ぎで貧乏になった人はいない
55 お金持ちが書斎を持つのではなく書斎を持つからお金持ちになる
76 どんな一冊にも10万円の価値があると心得る
組織としての長期的学習への投資 [プログラマー現役続行]
神様のサービス 感動を生み出すプラス・アルファの作り方 (幻冬舎新書)
- 作者: 小宮 一慶
- 出版社/メーカー: 幻冬舎
- 発売日: 2011/07/28
- メディア: 新書
この書籍では、サービスとして優れている色々な会社が紹介されているのですが、その中で「ホンダカーズ中央神奈川」に関して、詳しく説明がされています。ホンダカーズ中央神奈川は様々な活動を行っているのですが、その活動の1つとして次のことが紹介されています。
⑥月に1回、読書感想文を提出するソフトウェア開発でも、「会社」を「ソフトウェア開発組織」、「従業員」を「ソフトウェアエンジニア」、「本」を「技術書」と読み替えてみると全く同じことが言えます。読書をすることに関して、Steve Maguireは、『Debugging the Development Process』の中で次のように述べています。
同社では、一ヶ月に一度の割合で、従業員が読書感想文を書き提出するという試みを20年も継続して行っています。会社のお金で内容の良いビジネス書などを購入し、営業マンはもちろんのこと、サービススタッフや事務職員など、すべての従業員が同じ本を読み感想文を提出しています。それを会長が添削し、全員が提出した読書感想文をファイルに綴じて、いつでも誰でも読めるように保管します。本代だけで年間1000万円はかかるそうです。
社員は、最低でも年間12冊の良い本を読むことになりますから、10年続ければ120冊になります。良書を読むことは、人間の価値観を見つめ直す契機になりますし、人生の原理原則を学ぶこともできます。そういう本を何十冊、何百冊と読んできた従業員のいる会社と、まったく読まない従業員のいる会社では、長い年月の間には大きな差が出てくるのは歴然としています。
読書をすることが、今すぐ業務に役立つわけではありません。即、売り上げに直結するわけでもありません。でも、読書によって少しずつ人間力を高めていくことは、長い目で見れば、真の「お客さま志向」を実践できる社員の育成につながっていくのです。だから同社は年に1000万円かけてでも、従業員に本を読ませているのです。
『神様のサービス』（p.174）
Read Any Good Books Lately?
新しい知識と見識を得るために、私は常に本を読んでいます。一冊の良い本を選べば、他の人が何十年 もかかって修得してきた見識を、数日で得ることができます。それなのに、なぜ、何年もかかって試行 錯誤により学ぶのですか。非常に大きな差ですよ。もし、チームのメンバーが一年間に6冊の見識深い 本を読んだとしたら、そのことがメンバーの仕事にどのような影響を与えるか想像してみてください。
--Steve Maguire, Debugging The Development Process
- 作者: Steve Maguire
- 出版社/メーカー: Microsoft Pr
- 発売日: 1994/08
- メディア: ペーパーバック
継続的な学習への投資というのは、その効果を数値で求めたら、答えるのは困難です。そのため多くの企業では経費削減という名目で書籍の購入を控えたりします。確かに、現場が必要だからと言う書籍を単純に購入しても、本当に読まれるかどうかは怪しかったたりします。むしろ、勉強会を行うのであれば、勉強会が終了して最後まで読み終えた人達に対して、本代を補助してくれる方が良かったりするかもしれません。
私自身は、会社補助での勉強会を主催したことはほとんどないですが、ソフトウェア開発組織として学習への投資を考えるなら、たとえば、業務時間外での勉強会への本代の補助や会議室などの施設利用の許可など安い投資でありながら、長期的には効果が高いものだと思います。
しかし、組織として長期的な学習へ投資する提案に対して、「効果を数値で示せ」とトップが言うと誰も提案できなくなります。その結果、組織としては「人材の育成が重要」だという「効果が測るのが困難な目標」を掲げているにも関わらず、数値で測れる活動しか求めず、地道で長期的な学習への投資は行っていなかったりします。
書籍『Android SDK 開発クックブック』のサンプルコード（２） [プログラマー現役続行]
- 作者: ジェームズ・スティール
- 出版社/メーカー: ピアソン桐原
- 発売日: 2011/07/26
- メディア: 単行本（ソフトカバー）
サンプルコードを更新しました。基本的には英語版のサンプルコードに含まれているのコードに対応しています。なお、すべて動作確認できている訳ではありませんが、GDDフォン（Android 1.5）で確認できる範囲は確認しています。
英語版のサンプルコード：
http://www.informit.com/store/product.aspx?isbn=0321741234
日本語版のサンプルコード：
http://www012.upp.so-net.ne.jp/eshibata/android/ADCCode.zip
日本語版の正誤表：
http://www001.upp.so-net.ne.jp/yshibata/
（書籍『Android SDK 開発クックブック』のサンプルコード）
徒弟制度的な教育 [プログラマー現役続行]
若手のエンジニアがソフトウェアエンジニアとして成長する過程では、多くのことを学んでもらう必要があります。そのためには、継続した学習を習慣としてもらう必要があります。しかし、本人が技術書を読んだり、プログラミングしたりして技術書の内容を確認したりということで、勝手に伸びていく人は非常に少ないと思います。
今日の日本企業における若手技術者の成長には、徒弟制度的にコミュニケーションを通しての指導が必要となります。つまり、経験がある人が、経験の浅い人の学習を促すと同時に、本人の理解度を確認したり、補足の説明をしたり、誤りを指摘したり、コードの悪い点を指摘したりというコミュニケーションを必要とします。私自身の過去の経験から行ってきたことをその観点から振り返ってみると次のようになります。
日本企業では、ソフトウェア開発を行う業務であっても、大学でコンピュータに関する基礎知識を学んでいなく、ほとんどプログラミング経験がない人を採用する傾向が強いです。そして、入社後の集合教育で「必要なことは教えている」はずという淡い希望で、集合教育後に開発現場が新人を受け入れます。そして、開発現場は、地道な教育活動を「時間が無い」という理由で放棄しているのに、集合教育できちんと教育してくれという都合の良い要求だけをしたりする場合があります。それに加えて、開発現場は、今使っている技術と関係ないことは不要なことだと考える傾向が強いため、それだけを教えて配属してほしいと要求したりすることがあります。
ソフトウェア開発は、簡単な活動ではなく、非常に複雑な活動です。そのため、きちんとしたソフトウェアエンジニアとなってもらうためには、多くのコミュニケーションを伴う徒弟制度的な教育が必要となります。そのような活動を、人数が多いからとか時間がないからとかの理由で放棄してしまったり、自学習を行ってもらって理解度をテストで確認することで行うとしても、おそらくきちんとした技術者は育たないと思います。
今日の日本企業における若手技術者の成長には、徒弟制度的にコミュニケーションを通しての指導が必要となります。つまり、経験がある人が、経験の浅い人の学習を促すと同時に、本人の理解度を確認したり、補足の説明をしたり、誤りを指摘したり、コードの悪い点を指摘したりというコミュニケーションを必要とします。私自身の過去の経験から行ってきたことをその観点から振り返ってみると次のようになります。
- プログラミング言語Java教育 この教育は、ブログ内で何度も紹介しており、基本的に予習で不明であった質問に回答するという形式です。質問に答えると言っても、質問の意図を聞くことで、何を理解していないのか、何を説明してあげる必要があるのか、あるいは、何か基礎的な知識が不足していて、そこから説明してあげる必要があるのかを考えて回答を行います。そして、場合によっては、Javaとは関係のないコンピュータの基礎的な事柄を説明することが多々あります。
- アルゴリズムとデータ構造（書籍『プログラミング作法』）教育 「プログラミング作法」教育で述べていますが、勉強会ノートをベースとして、書籍『プログラミング作法』の第2章「アルゴリズムとデータ構造」を学習してもらいます。勉強会ノートには、第2章に関して104個の説明ポイントがあり、それに答えてもらうと同時に練習問題を行ってもらいます。そして、それらの説明ポイントの解答や練習問題のプログラミング結果を本人に説明してもらいます。その説明で不足している点や、本人が正しく理解していないと思われる部分に関しては、ホワイトボードに視覚的に書いて説明してもらったりします。つまり、本人の理解レベルを把握し、理解が不十分な点をどうしたら本人に理解してもらえるかを考える訳です。
- 技術書の勉強会 非業務の勉強会は10年以上行っていますが、その勉強会でも同じように参加者が理解できていないくて、私が経験していたり知っていたりすることは説明します。勉強会には、私自身も学ぶことを目的としたものや、これだけの内容は若手に知っておいてもらいたいという内容の勉強会がありますが、どの場合でも、内容の理解に関して質問したり、説明したりを行うことになります。
- 日々の開発業務を通してのレビュー 業務なので当たり前かもしれませんが、設計レビューやコードレビューを通して、作成者が何を考えているかとか、どこまで見通して考えているのか、コードの読みやすさに対する本人の認識度を把握するために、質問したり説明を求めたりして、指導することになります。
日本企業では、ソフトウェア開発を行う業務であっても、大学でコンピュータに関する基礎知識を学んでいなく、ほとんどプログラミング経験がない人を採用する傾向が強いです。そして、入社後の集合教育で「必要なことは教えている」はずという淡い希望で、集合教育後に開発現場が新人を受け入れます。そして、開発現場は、地道な教育活動を「時間が無い」という理由で放棄しているのに、集合教育できちんと教育してくれという都合の良い要求だけをしたりする場合があります。それに加えて、開発現場は、今使っている技術と関係ないことは不要なことだと考える傾向が強いため、それだけを教えて配属してほしいと要求したりすることがあります。
ソフトウェア開発は、簡単な活動ではなく、非常に複雑な活動です。そのため、きちんとしたソフトウェアエンジニアとなってもらうためには、多くのコミュニケーションを伴う徒弟制度的な教育が必要となります。そのような活動を、人数が多いからとか時間がないからとかの理由で放棄してしまったり、自学習を行ってもらって理解度をテストで確認することで行うとしても、おそらくきちんとした技術者は育たないと思います。
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
