柴田 芳樹 (Yoshiki Shibata)

2010年に原著が出た本ですが、翻訳本が出たようです。

ソフトウェア開発は人が行う活動であり、手を動かしてプログラミングするという点では一種の家内手工業です。そのため、従事する人のスキルによって生産性、品質、および、技術的負債というのは大きく左右されます。したがって、本質的には個々のエンジニアのスキルを長期的に向上させることを組織として行っていく必要があります。

しかし、スキル向上は目に見えないし数値として測るのは難しいため、長期的視点に立ったスキル向上のための活動をソフトウェア開発組織としては避けたりする場合があります。代わりに、スキル向上以外の対策を真剣に検討することになります。たとえば、コードの品質を測るために静的解析ツール（カバレッジ測定、複雑度測定、FindBugsなど）だけに頼って品質を向上させようとします。そして、ツールが示す数値が開発プロセス内でのフェーズ移行基準として決められたりします。

本来、それらの指標は、開発者自身が客観的に自分が作成したコードの品質を確認するのを助けるためのツールであり、基準値をクリアーすれば品質が高いことを保証するものではありません。たとえば、コードカバレッジが100%というのはコードの品質を保証するものではありません※。
※ バグがあったり、品質が悪くても、コードカバレッジを100%にすることは可能です。

開発者が自分のコードの品質を確認すると言っても、開発者自身のスキルが高くなければツールが示すコードの状態を正しく解釈できなかったりします。たとえば、FindBugsが警告している内容の本質が分からずに、警告を消すための誤った修正を行ったりすることになります。そして、スキルの低いエンジニアは、コードの品質以前に指標をクリアーすることに注力することになります。

結果として、そのようなツールの導入だけでは、思ったほど品質が上がらなかったりして、結局は「ソフトウェアエンジニアのスキル」問題に戻ってしまいます。毎年、経験の浅い新卒新人の人達がソフトウェア開発組織には入ってくる訳であり、一時的にはツールやプロセスなどでスキル問題を回避しても、また同じ問題に直面することになります。

「プロセス中心ではなく、スキル中心（3）」

2000年に『プログラミング言語Java第3版』の翻訳を始めてから、改訂版も含めて10冊の技術書を翻訳したことになります。

http://www001.upp.so-net.ne.jp/yshibata/#BOOKS

今月末までに英語原著が発売になる予定の技術書を、昨年末から3月まで翻訳していたのですが、売れるかどうか不明ということで出版は見送りとなっています。

それで、現在は別の技術書の翻訳を行っています。こちらは、出版することは確定しているのですが、ページ数が600頁弱とかなりの量です。

平日は、仕事をしながらの翻訳作業は長距離走です。毎日、出社前に2、3ページを訳して、週末は多めに訳すことを何ヶ月も続けることになります。

ソフトウェア開発では、画一的に教育で教えられることだけで済むことはなく、コミュニケーションを取りながら、こまごまとしたことを指導や指摘を行っていく必要があります。

延べ1,000人以上に教育を行っても、日々の開発業務で指導を受けない人達が伸びていく可能性は低いです。現場のエンジニアとコミュニケーションを取ることなく、一人で教えて指導するには限界があると当初からあきらめてしまうと、組織としては実は全くエンジニアのスキル向上が行われないのかもしれません。たとえば、一人で教えられる範囲は限界があるからと当初からあきらめて、ウェブベースの教育コースを用意しても、コースを用意した側の自己満足に終わってしまうのではないかと思います。

1999年頃から様々な教育を行ってきましたが、確かに人によってはそれらの教育（特に「プログラミング言語Java教育」）をきっかけとして一人で成長していった人もいたかとは思います。しかし、教育を受けた中でも、成長していった人達の大多数は、日々の開発業務で直接私と一緒に仕事をした（若い）人達です。

日々の開発業務で一緒に仕事をするというのは、教育では教えきれないことも話しますし、コードや設計のレビューもしますし、一緒にデバッグしたりディスカッションしたり、さらに、一緒に飲む機会も多くなります。つまり、必然的に日々多くのコミュニケーションを取ることになり、様々なコミュニケーションの場を通して、私自身の考えや経験を伝えていくことになります。

(「教育と場」、「教育と場 （2）」）

このブログでも以前紹介しましたが、2011年Jolt Excellence Awardを受賞した『Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation』の翻訳本が出版されています。


本のキャッチコピーの「いつまで手動でデプロイしているんですか？」がいいですね。お勧めの書籍です。

『プログラミング言語Java』の第3版から著者として名前を連ねていて、第4版では改訂部分の多くを執筆したDavid Holmes氏がJavaOne Tokyo 2012のスピーカーとして来日します。


今回は、Jigsawに関するセッションとLambdaに関するセッションの2つで話をする予定だそうです。David Holmes氏と会うのは2008年のサンフランシスコでのJavaOne以来です。

拙著の第7章「朝型力」からの抜粋です。

人は見ていないようで見ている

　20代、特に新卒新人として配属されたときは、誰よりも早く出社する習慣が必要です。ぎりぎりにしか出社しないようであれば、自分で時間管理ができないと見なされてもおかしくありません。そのような人に限って、朝の会議の時間ぎりぎりに会議室に入ってきたりします。
　当人は、「ぎりぎり間に合った！」とほっとしているかもしれませんが、そのようなことを繰り返していると、時間にルーズな新人だと見なされるだけです。
　人は見ていないようで見ているもので、誰々はいつも時間を守って余裕を持っているが、誰々は時間管理がだらしないと、評価はすぐに職場中に広がります。

今、読み返しみると「誰よりも」は余分かと思います。

ちょっとぐらいの早起きでは元にもどる

　朝、余裕を持って出社するには、やはり早起きすることです。その結果、ぎりぎりに会社に駆け込むこともないでしょうし、遅刻することもなくなります。
　しかし、早起きを動機づけるには、早く起きた分の時間を何かの活動に充てることです。
　ほんの10分ぐらい早起きして、ちょっとだけ余裕を持ってコアタイム開始時間より少し前に出社しようとしても、必ず元の状態に戻って、いつもぎりぎりとなります。したがって、思い切って１時間とか２時間早く起きることです。そして、その時間で読書なり、英語の学習といったものを行うことです。

章のまとめとして、次のように述べています。

貴重な朝の時間を有効に使う

　朝型の生活パターンを勧めている書籍は多く出ていますが、夜型を勧めている本はほとんどありません。 　一度しかお会いしたことがありませんが、『朝2時起きで、なんでもできる!』の著者である枝廣淳子さんは、朝の時間に集中して行うことで、さまざまな活動をされています。
　朝の１時間は、夜の２時間に匹敵するといわれます。早起きして、コンピュータやソフトウェアに関する学習をするのもいいでしょうし、情報処理試験などの資格を取得するための学習をするのもいいでしょう。
技術者として早朝に学習しようと夜に学習しようとどちらでも良いではないか、という意見の人もいるでしょう。自分の効率が良い時間帯で学習をすれば良いのは確かです。ただし、それには、社会人として時間にルーズにならないという条件付きです。
　会社に遅刻する、半日休暇を取る、朝の自主参加の勉強会に遅刻したり欠席したりする、などの理由として「夜遅くまで勉強していて朝起きられませんでした」は理由にはなりません。つまり、勉強しているから、時間にルーズでも良いでしょうというのは成り立たないのです。そして、技術的には優れていても、この時間にルーズという一点だけで全体評価は下がってしまいます。
　朝型として継続した学習を勧める理由の一つは、朝寝坊をして朝の時間に関してルーズになることを防いでくれることです。当然、早朝に学習をするためには、実際に家を出る２、３時間前に起きて学習することになります。その結果として、上記のような時間を守れないような行動を減らすことができる訳です。
　重要なことは、継続した学習よりも「時間を守る」方の優先度が高いことです。これは、技術者としてではなく社会人としてです。
　とにかく、若いうちは、この朝の貴重な時間を有効に活用する習慣を身につけることをお勧めします。そして、時間にルーズにならないことです。

面白いことに、毎朝遅刻すれすれに出社する人は、フレックス勤務制度であるか否かには関係ありませんし、住んでいる場所と職場の距離とも関係ないように思えます。

私自身が会社で開催する勉強会は、朝の勤務時間前にしか開催しません。そのため、もともと朝の時間にルーズな人が参加を申し込んでも、ほとんどの人が数回で出席しなくなります。本を読み終える最終回まで参加を継続する人は、その後の勉強会にも引き続き参加する人が多いです。

多くの組織で週報会が行われていると思います。私は経験的に、開発組織メンバー全員を集めての週報会を好みます。仮に、20人規模の組織であっても、一人3分ほどで一週間の活動を報告してもらうことで、各人がどのような業務を行っているかをメンバー全員で共有して知ることができます。

各人に週報を書いて提出してもらえれば、全員を集める必要もないという意見もあるかと思いますが、組織のメンバー全員が他のメンバーの週報を読むことを期待するのは無理です。

全員を集めての報告では、淡々と報告を聞くのではなく、他のメンバーにも分かるように説明しているか、分かりにくい説明となっていないか、何か問題が起きていないかに注意を払いながら、場合によっては必要な質問を行い確認する必要があります。

そのような週報会は、決まった曜日の決まった時間に毎週行う必要があります。つまり、その時間には必ず週報会が開催されるという習慣化も重要となってきます。たとえば、その週報会で組織の長、たとえば部門長が欠席でも、その下のグループリーダが主催して行うということです。

階層化された組織、たとえば、チーム、グループ、開発部と階層化された組織で、現場の担当者はチーム週報会にしか出席せず、グループ週報会にはチームリーダとグループリーダだけ、開発部週報会にはグループリーダーと部長だけという週報会を行うと、伝言ゲームとなり現場の状況が全く伝わらずに、いわゆる「News Improvement」※が発生する可能性が高くなります。その結果、隣のチームあるいはグループのメンバーがどのような作業をしているかを知らないという状況が発生したりします。さらに、グループリーダと部門長だけが出席する開発部週報会以外は、一切開催されなかったりします。あるいはそれも全く開催されない組織があったりもします。

※　悪いニュースが階層の上に伝わるにつれて良いニュースに変わっていくことです。たとえば、現場では絶対間に合わないというニュースが部長までいくと、スケジュール通りで問題なしという具合にです。書籍『アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン』で使用されている表現です。

今までのこのブログとは別に、新たにブログを開設しました。

『Effective Java』を読む
http://effectivejava.blog.so-net.ne.jp/

2月に電子書籍で2冊を読みました。



どちらもソフトウェア開発で生きていきたい人向けです。しかし、扱っている範囲が意外と広くて、私自身興味がある部分とそうでない部分がかなり混ざっていました。

今朝、新たに購入した新刊は次の書籍と『tmux: Productive Mouse-Free Development』の2冊です。


電子版で購入すると、すぐにKindleに届きますし、場所も取らないので便利です。