書籍『From Mathematics to Generic Programming』

From Mathematics to Generic Programming

• 作者: Alexander A. Stepanov
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2014/11/17
• メディア: ペーパーバック

今朝気付いたのですが、Alexander A. Stepanov氏が新たな本を執筆していました。彼は、私が翻訳した『プログラミング原論』の著者ですし、C++ STLの設計者でもあります。

プログラミング原論

• 作者: アレクサンダー ステパノフ
• 出版社/メーカー: ピアソン桐原
• 発売日: 2010/12/24
• メディア: 単行本（ソフトカバー）

コードレビューの目的

ソフトウェア開発で行うコードレビューは、1つの目的ではなく、様々な目的を持ちます。きちんと機能が実装されているかを確認することは、目的の1つです。しかし、それだけではないわけです。

他の目的の1つとして、作成したソフトウェアエンジニアのスキルレベルを知って、どこが弱いのかを把握し、指導する場でもあるわけです。弱い部分には色々な側面があります。その1つとして、第3者にとって分かりやすく書かれているかも含まれます。

ソフトウェア開発では、ソースコードを作成するだけでなく、様々な成果物があり、それらもレビューされます。たとえば、様々な文書もそうです。書かれた文書が、書いた本人にしか理解できないし、誤解を招くような日本語で書かれているといったことは、レビューを通して指摘し、修正させることを繰り返すことが必要です。その結果、本人のレベルが向上して、誰が読んでも誤解することなく分かりやすく書けるようになるわけです。

もし、担当者が書いたものを何もレビューしなければ、担当者のスキルレベルが低い場合には、役に立たないがらくたの文書が作成されるだけであり、担当者は何年たっても質の低い文書を書き続けるかもしれません。

「コードレビュー」と言っても、行っていないソフトウェア開発組織もあるでしょうし、きちんとしたレビューを受けたり、指導をしたこともなく、ソフトウェア開発をしなくなった管理職もいると思います。その結果、「コードレビュー」をすることに関しては、文書をレビューすることと比べて、時間がかかり過ぎるとか無駄だと思う人がいてもおかしくはありません。

コードレビューには、様々な目的が含まれていますが、ソフトウェア開発組織にとって重要なのは、色々な意味で技術的負債とならないコードにすることと、ソフトウェアエンジニアのスキルレベルを長期的に上げるためということです。

ドコモのdマガジンを契約してみました

ドコモのdマガジンを契約してみました（ドコモと回線契約がなくても契約できるようです）。

https://magazine.dmkt-sp.jp/
https://www.nttdocomo.co.jp/service/entertainment/dmarket/magazine/

月額が400円（税抜き）で様々な雑誌が読めるということで、契約してみたのですが、確かに多くの雑誌が読めます。コンピュータ関連としては、以下の雑誌が読めます。

• 週刊アスキー
• Mac Fan
• 日経PC21

Mac Fanは、Kindle版でも630円なので、古い号を読む必要がなければ、dマガジンがお得です。ただし、いくつかの制約があります。

• 雑誌のすべてのページが読めるとは限らない。雑誌ごとに異なります。
• iOSあるいはAndroid上の専用アプリからしか読めない。PCからは読めません。
• 保存はできない。読む時は、インターネットに接続されていなければなりません。

書店の雑誌コーナーに行ったような感じで、様々な雑誌から読みたいものを選んで読むことができます。平日は、ほとんど書店に寄ることはないのですが、dマガジンであれば、帰宅してから、その日に配信された雑誌を読むことができます。12月だけでも雑誌の配信日が合計25日です。

いったい、どんなビジネスモデルなのでしょうか？

書籍『私はこうして英語を学んだ 増補改訂版』

私はこうして英語を学んだ 増補改訂版

• 作者: 松本道弘
• 出版社/メーカー: 中村堂
• 発売日: 2014/12/24
• メディア: 単行本

1979年に出版された本の改訂版です。初版は、大学生の時に読みました。初版は、ずっと持っていましたが、書斎が手狭になったので、数年前に他の書籍と一緒に処分してしまいました。

大学時代に、私の英語学習にもっとも影響を与えたのがこの本の初版でした。記憶が定かではありませんが、確か小倉の商店街にある書店で購入したような記憶があります。

残念ながら、今では何が書かれていたのかほとんど記憶にないです。その意味で、初版の原文がそのまま掲載されている改訂版を読むのを楽しみにしています。

Podcastで英語のニュース（2）

Podcastで聞く米国や英国のニュースの英語は、速いです。同じニュース番組でも、日本語の放送ではそんなに速くは話さないです。

私の場合、高校まで英語を聞くということは一切ありませんでした。大学生になってから、英語を聞くようになったのですが、大学生の頃のリスニング力は、次のような段階を経ました。

1. 何も聞き取れずに、ただの音の流れになっている。単語の区切りさえ分からない。
2. 徐々に単語の区切りが分かるように、耳が英語になれてくる。
3. 単語は、かなり切れて聞こえるが、何を言っているのか分からない。

この最後の段階になると、語彙と頭から聞いて理解できる文法力が必要になってきます。言い換えると、「読んで分からない英語は、聞いても分からない」という状態に直面しました。

それまでも、英語を読むことはしていましたが、やはり、多読して、多くの英語は読む必要があることを認識したわけです。多読することは、以下の2つのことを達成するために必要だと思います。

• 頭から読みながら構文を理解して、内容を理解する。
• 知らない単語に、何度も出会う

昔は、電子辞書もありませんし、Kindleもありませんから、知らない単語に出会うたびに辞書を引いていたら時間がかかってしまいます。そこで、意味をはっきりとは知らないが、前後の文章から意味を推測して読みます。もちろん、推測は間違っているかもしれません。しかし、重要なのは、多読することで、その推測した単語に様々な文脈で出会うことです。そうすれば、その単語を記憶することができますし、何回か出会った後に辞書を引いて意味を確認します。

TOEICの対策本をたくさんこなすよりは、普通のペーパバックなどで自分が好きなジャンルの本を多読する方がよいと思います。私自身も、Sidney SheldonやJohn Grishamなどの小説は多く読んでいました。

最近は、会社でTOEICの点数が昇格基準になっていたりするため、TOEICの点数だけを問題にしている若い人たちが多いです。そのため、TOEICの対策本しか勉強しなかったりしますし、目標とする点数を達成したら、何もしなくなったりします。TOEICの対策本では、有益な情報・経験・感動を英語で得るのは難しいと思います。

Podcastで英語のニュース

「英語とTOEIC（3）」で普段Podcastで聞いている英語ニュースについて簡単に紹介しました。改めて紹介すると、以下のニュースを購読して見たり聞いたりしています。

• Anderson Cooper 360° Daily (Video)
• NBC Nightly News (video)
• NBC TODAY Show (video)
• CNN Student News (video)
• GlobalNews

最初の4つは、映像があるニュースです。最後は音声だけのBBCのニュースです。「NBC TODAY Show」は、朝のニュース番組のダイジェストとなっています。米国に住んでいた頃、朝は、2時間のニュース番組を見ていることが多かったです。

CBSの「This Morning」やABCの「Good Morning America」などはよく見たものであり、当時のアンカーやアナウンサーが他の番組で登場すると懐かしく感じます。

Podcastで見たり聞いたりと言っても、ほとんど、ながらです。つまり、他の作業をしながらです。ニュースの英語のスピードはかなり速いですが、TOEICの対策本でリスニングを鍛えるのではではなく、日々のニュースを聞くことで、英語のスピードにに耳を慣らすのが良いと思います。それと同時に多読も必要です。なぜなら、「読んでも分からないものを耳で聞いても分からない」からです。

キャリア・アンカー

ウィキペディアでは、「キャリア・アンカー」は、次のように説明されています。

キャリア・アンカーとは、アメリカ合衆国の組織心理学者エドガー・シャインによって提唱された概念。

ある人物が自らのキャリアを選択する際に、最も大切な（どうしても犠牲にしたくない）価値観や欲求のこと、また、周囲が変化しても自己の内面で不動なもののことをいう。

ウィキペディアより

さらに、アンカーの分類として、以下の8分類が説明されています。

シャインは主なキャリア・アンカーを「管理能力」「技術的・機能的能力」「安全性」「創造性」「自律と独立」「奉仕・社会献身」「純粋な挑戦」「ワーク・ライフバランス」の8つに分類した。

• 管理能力 - 組織の中で責任ある役割を担うこと（を望むこと）。
• 技術的・機能的能力 - 自分の専門性や技術が高まること（を望むこと）。
• 安全性 - 安定的に1つの組織に属すること（を望むこと）。
• 創造性 - クリエイティブに新しいことを生み出すこと（を望むこと）。
• 自律と独立 - 自分で独立すること（を望むこと）。
• 奉仕・社会献身 - 社会を良くしたり他人に奉仕したりすること（を望むこと）。
• 純粋な挑戦 - 解決困難な問題に挑戦すること（を望むこと）。
• ワーク・ライフバランス - 個人的な欲求と、家族と、仕事とのバランス調整をすること（を望むこと）。

ウィキペディアより

数年前、52歳を対象とした研修で、自分のキャリア・アンカーを調べるというのがあったのですが、確か「技術的・機能的能力」が非常に高かったです。一方で、いわゆる管理職的な仕事は、過去も行ってきてはいます。日本オラクル社時代は、当時のOracle ApplicationsのHRシステムの開発マネージャでしたし、前職のFXISでも開発部の部長でした。しかし、今でもそうですが、「管理能力」はキャリア・アンカーとしては、かなり低いです。つまり、管理職を指向していないということです。

今、振り返ってみると、日本オラクルを退職したのも、FXISを退職したのも、私自身のキャリア・アンカーとは一致していなかったためかもしれません。最近は、私の回りの知り合いの若手のソフトウェアエンジニアで、転職する人達が多い※のですが、彼らも「技術的・機能的能力」を指向しているためなのかもしれません。
※　今年だけで、6名です。私の直接の部下ではありませんが、4名はJava研修の修了生です。

いつも受け入れられるとは限らない改善提案

社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。

問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべての警告を修正することができなかったりまします。そうすると、どの警告を修正するかしないかの分類をしようということになるのです。

一方で、同じ状況で、プロジェクトが開始された時点で、継続的インテグレーション環境や静的解析ツールを導入して、最初からすべての警告を潰していきましょうという提案は、そのような環境を準備するために工数を費やす利点を理解できなくて、却下されたりすることがあります。あるいは、説得するために多くの資料を作成させられることになります。

この場合、問題が発生してからの改善提案は、上位のマネージャに対して「提案活動をした」ということで評価されるでしょう。しかし、予測される問題に対する改善提案は評価されないかもしれません。そうなると、事前に予測される問題を潰すという改善提案を現場はしなくなるわけです。

どのような問題が発生するかを予測するには、予測される問題を過去に経験して、それを解決したという経験がないと、できないかもしれません。その意味で、上位のマネージがそのような経験を積んでいる必要がある訳です。しかし、逆に考えると、そのようなマネージャであれば、プロジェクトが開始された時点で開発環境の整備などをトップダウン的に指示するはずであり、現場が改善提案をする必要がないわけです。これは、マネージャでなくても、中堅のソフトウェアエンジニアに対しても当てはまることです。

私も、ある時、中堅のエンジニアに対して、これから、たくさんの機能を開発していなければならないので、古いCVSを用いた手作業のビルド環境から、Subversionを用いた継続的インテグレーション環境を整備して、単体テストも整備すべきと提案したことあるのですが、「これから開発しなければならない、たくさんの機能と開発環境の整備のどちらの優先順位が高いか精査して、開発環境の整備の方が高ければ人を割り当てます」と言われたことがあります。正直自分の耳を疑ったのですが、議論してもしかたないので、その後、自分と若手の協力会社の2名で開発環境整備して、全面的に移行させてしまいました。

あるいは、別の遅れているプロジェクトでは、遅れを取り戻すために私が手伝えることを5項目ほど列挙して、その中にも継続的インテグレーション環境の構築も含まれていたのですが、すべて却下されたことがあります。残念ながら、そのプロジェクトは、私が予測した通りの問題が多数発生していました。

このようにマネージャや部門長などへのソフトウェア開発に関する改善の提案は、その内容によっては、すんなり受け入れられる場合と、本質的な提案であっても「理解されない」場合があります。