『経営者の条件』 簡易レビュー

ドラッカーの著書『経営者の条件』を読み終わったので、簡単なレビューを書きます。

本書のタイトル『経営者の条件』は、原著では『The Effective Executive』となっています。本書の定義では、エグゼクティブ(Executive)とは経営に関係なく成果を出すよう実行する人のことを言うので、経営者寄りの本ではありますが、読者を経営者に限定した本ではないです。原著のタイトルを、意図にあったように訳すなら「効果的に成果を出す」とかそんな感じでしょう。

本書では、仕事で成果を出すにあたって身につけたほうがいい、いくつかの習慣を論じています。1959年の本なのでだいぶ古いですが、現代でも状況としてはあまり変わっていないように感じました。
エグゼクティブが身につけたほうがいい習慣は、時間の使い方、意思決定に当たって基本となる方針を立てることだったり、「部長」のような役職ではなく「会社・プロジェクトに対してどのような貢献をする人か」で考え・話すようにする、とかそんな感じのことです。

この本をオススメしてくれたのは近藤さんでしたが、「あぁ、近藤さんはたしかにこの本の影響を受けてるな」という感じがしました。
ドラッカーの文章はちょっと読みにくくて、「こういうときはこうしたほうがいい」みたいなものではなく、「エグゼクティブはこう考える」のように、主張ではなく、著者が考える理想像の列挙 + 事例という形式だったので、よく読まないと主張が読み取りにくかったりはします。

本書の読者層としては、以下の2パターンかと思います。

1. 問題意識を持って本書を読み、後天的にエグゼクティブになりたい人
2. 経験則と断片的な知識を元にしてすでにエグゼクティブだけど、成果を出す原則を知りたい人

この読者層にマッチする人にとって、本書は有益なものになると思います。

始めるのが遅くていいこと

学び始めるのが早くていいこともあれば、遅くていいこともある。
遅くていいことというのは、入門の時点から「自分がどうやって理解してきたか／成長してきたか」を自己分析しながら始められる、ということ。

書籍『アプレンティスシップ・パターン』を書いた共著者の一人は、30歳くらいからプログラミングを始めたらしい。その学び始めから自分の成長を分析してきたことで、「開発者がどのように成長していけばいいか」をテーマにした本を書くに至った。

ぼくは、プログラミングを始めたころの自分の感覚をよく覚えていなくて、たとえば「変数とは何か」をどうやって理解したのか覚えていない。そのため、入門時のいくつかについては、何がわからなかったのかわからない、という状態になっている。なので、それらのことについては現状、人に教えられない。

そろそろ、そのあたりを再入門しようかと思う。『プログラマの考え方がおもしろいほど身につく本 問題解決能力を鍛えよう!』という本がよさそうなので、いま読んでる本を読み終わったら買ってみよう。

バイクにリムステッカーを付けた

バイクを買ってから1年10ヶ月ほど経つので、気分転換にちょっとしたカスタムとして、リムステッカーというのを付けてみた。

これは、ホイールのフチに付ける色付けのステッカーです。こんな感じになりました。

バイクのとはちょっと違う色の、青紫にしてみました。

リムステッカーはこれ：



RDFというメーカーの、17インチサイズです。
次は、3月の末くらいにタイヤ交換を予定しています。

技術書を書くペース

技術本を書くペースについて考える。

最初に本を書いた23歳当時に実測したのだけど、B5版の技術書で1日フルで書いて11ページが限界だった。平日はがんばって4ページくらい。
この作業のなかには、調べ物と検証の時間も含まれている。

平日に毎日がんばって書くと、75日で1冊分の300ページに到達する。これは休日に休むことを考慮して3ヶ月。3ヶ月間も全力は維持できないので、これはだいたい破綻する。
(このあと推敲と他者レビューで最低1ヶ月はかかる)
なので、習慣化をせず情熱だけで書くと、だいたい力尽きる。

1年の平日はだいたい260日くらいなので、平日に無理せず1.2ページくらい書けば、レビューも含めて燃え尽きずにだいたい1年で書けるんじゃないかなと。

少しずつでいいから、毎日書きましょう。

後日、脳科学の観点から、習慣化したほうがいい根拠について(気が向いたら)書く(かも)。

アプレンティスシップ・パターン

書籍『アプレンティスシップ・パターン』を読み終わりました。

この本は、書籍『ソフトウェア職人気質』で提唱された「徒弟制度」というプログラマの成長のさせ方を、eXtreme Programming、アジャイル、ペアプログラミングといったものが普及してきた現代に合わせてまとめ直したものになっています。

この本の内容は、一言で表すなら「職業プログラマの心得をパターン・ランゲージで学ぶ」というものになるでしょう。

パターン・ランゲージというと、多くの方はGoFのデザインパターンを思い浮かべるでしょうが、パターンはプログラムの典型に名前を付けるだけでなく、その他多くの状況に適用できるものです(パターン・ランゲージは建築業界から来ました)。本書では、状況別に問題点と解決策をまとめ、パターン名を付ける、という形式になっており、カタログの要領で自分にあった心得や方法論を探して学べます。

徒弟制度というのは、もともと鍛冶屋がとっていた技術伝承の方法です。流れとしては、弟子(アプレンティス)は熟練職人(クラフトマン)になるために、熟練職人の元を転々として数々の技術を学んでいき、やがて独り立ちして自分の工房を持ちます。これをソフトウェア開発に応用するのが、書籍『ソフトウェア職人気質』で提唱され、本書『アプレンティスシップ・パターン』でまとめ直されたものです。
本書は、熟練職人がいかに弟子を育てるか、ではなく、弟子がいかにして熟練職人になるか、という弟子視点の内容になっています。
本書のターゲットとしては、就職して職業プログラマになってから2〜3年目くらいまでの人になるのでしょうが、学生がプロを目指すために学んだり、少し伸び悩んでいるプログラマ、一緒に働いているプログラマにもっと成長してほしいと考えている方も読むといいでしょう。

この本で学べることは多々ありますが、とくに重要なことは「生涯学習を身につける」ということだと感じました。
ソフトウェア業界には、一生安泰の技術なんてありません。常に自身を成長させていく必要があります。ですが、私たちが学生のときには、先生から与えられたカリキュラムに沿って勉強してきたこともあり、学ぶものを自分から探す・探し続ける、ということは、就職したら自分で身につけなければなりません。
本書はその「生涯学習」を、プログラマ向けに動機付けて身に付けてもらうのに最適だと感じました。

とてもオススメです！

コードレビューについての簡単なまとめ

目的はあったほうがいい。ないと粗探しになる。
コードレビュー全体の目標と、定期開催でやるならその度にテーマとしての目標を立てる。
全体の目標は、プロジェクトの目標設定やプロジェクト憲章なんかと同じ。やらされてる感をなくし、目的意識を持たせるために必要。

コードを書いてからレビューまでの時間は、短ければ短いほどいい。時間が長くなるほど、直すのが億劫になる(心理的ハードルが高くなる)。
週に一度のレビュー会よりは、全員で全てのコミットを見張ってコミット直後に指摘したほうがいい。それよりは、ペアプログラミングをしてキーボードを入力するそばから指摘するのがいい。

コードレビューを受ける側は、指摘されるまで座して待っていてはいけない。
フィードバックは進んで受けにいこう。「こういうコードを書いてみたのですけど、この考えで合ってますか？」というようにフィードバックを求め、自分のコードを良くすることに貪欲になろう。

インカムを買った

バイク用のインカムを買いました。買ったのはこれ：



「SENA SMH10-11 DUAL(2台)パック フルフェイス用 バイク用インカム Bluetooth3.0 インターコム　US輸入版」

いつも一緒にツーリングに行ってる相棒と、同じのを買いました。2個セットがかなりお得だったので、2個セットにしました。

取り付けは、こんな感じになりました：

ヘルメットの左側面に、インカムを六角レンチを使って固定します。
スピーカーとマイクは、ヘルメットの中に付属の強力なマジックテープで貼り付けます。
マイクは、内側の口のとこに貼り付けます。フルフェイス用なのでこうなってます。ジェット用の長いマイクも付属しています。

このインカムは、スマートフォンとペアリングして音楽を聴くこともできますし、他のインカムとペアリングして話すこともできます。ペアリング可能なインカム数は、最大4台です。まだ2台しか試していません。

一度ペアリングしたら、ずっと繋ぎっぱなしです。話しかけるたびにボタンを押す必要はありません。
充電は、朝7時から夜9時まで電源を切らず使い続けても切れなかったので、少なくても丸一日ツーリングには耐えられます。

音質はかなり良好でした。ラグもほとんどないですし、高速道路でも少々の風切り音が入るくらいです(ヘルメット自体の品質に依存するかもしれません)。
接続可能距離は、カタログスペックでは900mになっています。高速道路では、目測で500mくらい離れても大丈夫でした。山中で、かなり置いていかれたときには切れちゃいましたが、のんびり一緒に走ってる分には接続を保ったままずっと走れるでしょう。

最近のBluetoothはすごいんだなーと思いました。少々の風切り音(しょうがない)以外は、全く不満なく動作しています。
これで、これからのツーリングがさらに楽しくなりそうです。

八ヶ岳高原ラインに行ってきた

2014/05/31(土)

すけさんと、すけさんの同僚とその友達、計4人で、山梨県の八ヶ岳高原ラインに行ってきました。

向かって左から、

1. DUCATI 1098s
2. HONDA CBR1000RR
3. KAWASAKI ZZR1400
4. KAWASAKI Ninja 400R

です。

行きの高速道路、釈迦堂PAにお仲間がいましたｗ
Ninjaのように見えて、ER-6fという別なバイクです。ぼくのバイクの後ろに停めてあったので、そのライダーさんに挨拶させてもらいました。

小淵沢ICで高速を下りて、そこからすぐのところにある、「道の駅こぶちざわ」で休憩。
フローズンヨーグルトがおいしかった。

ここから、八ヶ岳高原ラインに入りました。一瞬で終わってしまったけど、なかなか楽しい道でした。
八ヶ岳高原ラインを抜けてお昼を食べ、清泉寮というところに行ってソフトクリームを食べました。ここのソフトクリームは、かなり有名らしい。

清泉寮からの風景。いい天気でした。
ここには牧場とかいろいろあるらしいのですが、本目的ではなかったので、アイスだけ食べて早々に切り上げ。

そのあと「バノラマの湯」という温泉に行き、まったりしてました。休憩所が広くて、1時間ほど休んでました。みんな熟睡してた。

今回、インカムを買ってすけさんと話ながら走っていたのですが、だいぶ良かったです。インカムがあるとバイク旅が楽しくなりますね。

東京モーターサイクルショーに行ってきた

東京モーターサイクルショーに行ってきました。

メンバとしては、私、すけさん、きくちくん、祐くん、西山さん、平松さん。

念願のムルティストラーダに乗ってきたぞ。超カッコイイです。

あ、足がぎりぎり付くくらいなので、ちょっと難しそうですね…。

新型のハヤブサ。いい青です。

これもカッコイイ。

他にもいろいろ回って堪能しました。
祐くん、西山さん、平松さんとは途中ではぐれちゃいました。モーターサイクルショーを6人で回るのはムリですねｗ でも、あちらも楽しめたようでよかったです。

きょんさん結婚おめでとう！

2014/03/29(土)

kyon_mm * kaori_t_spica 結婚祝いLT大会 in Tokyo
#kyon_kao_wedding

きょんさんの結婚祝いに行ってきました。

きょんさん、かおりさん、末永くお幸せに！

今回は結婚記念のLT大会ということで、私も発表してきました。

Programmer mind from Akira Takahashi

きょんさんの結婚祝いとして自分にできること、自分の役割は何だろうと考え、自分のプログラマとしての心得を共有し、きょんさんが今後プログラマとして生きていくにあたって、何らかの参考になるようなものにしよう、と決めました。

「プログラマはこうあるべき！」と一般化して言えるほど自分の考えがまとまっているわけではないので、そういうのではなく、自分が大切にしていることを伝えることにしました。

こういうことを大勢の前で発表するのは、非常に怖かったのですが、自分がそれを役割として選んだので、これは乗り越えるべき怖さだと考えることにし、限られた時間でできる限り考えて形にすることにしました。何人かに事前レビューしてもらい、職場の勉強会で練習してアドバイスをもらい、なんとか形になったのが、今回の発表になります。

コンピュータ業界はまだまだ発展途上で、プログラマの成長の仕方みたいなものも、確立はしていません。なので、みんなそれぞれが大切にしていることがあると思います。今回のように、そういうことを共有することによって、より良いプログラマになるための方法論が少しずつできあがっていくといいなと思います。

今回の発表が、とくにきょんさんに何らかのいい影響を与えられたら幸いです。
おめでとうございます！

今回の発表では、@mizchiさんのもおもしろかったです。ああいう生き方も、プログラマとして非常に正しいのではないかと思います。情熱とポリシーを持って活動してる人の話はおもしろいです。
ほか、@cocoatomoさんの型の話、@yusukeさんのライブコーディング、@tomy_kairaさんのキーボードと音声入力の組み合わせも非常におもしろかったです。

参照

• 情熱はときに邪魔になる
• 複数の言語を学ぶということ
• ヒューマンエラーとの戦い
• 推奨の心構え