柴田芳樹 (Yoshiki Shibata)：SSブログ

	ブログをはじめるログイン

2012年02月｜ 2012年03月｜2012年04月ブログトップ
- | 次の10件

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

第15期「プログラミング言語Java」コースが終了しました。最終回は、午後の成果発表会まで午前中から『Effective Java 第2版』の第11章の残っている部分の学習を行い、成果発表会では今までの一年間の振り返りと会心のデジタル時計のデモを実施してもらいました。最後に、修了証書と私からのプレゼントである『Java Puzzlers 罠、落とし穴、コーナーケース』を手渡して、一年間のコースを終了しました。

第15期生と私

今回は、一年の振り返りのプレゼンテーションとデジタル時計に対して、それぞれ誰が一番良かったかを投票してもらいました。その結果は懇親会で発表し、デジタル時計はY.Mさん、プレゼンテーションは同点でS.TさんとS.Wさんとなり、私の方で用意した賞品を贈呈しました。

今回の修了生からは、フォローアップコンサルティングとして、実際の業務での開発成果物（特にコード）をレビューして、「実践の場」での成長をサポートする活動を行っています。「教育の場」で学んだだけでは、身に付いた訳ではありませんので、日々の開発の場で繰り返し意識して行うとこで、一年間苦労して学んだことを無意識に実践できるようになることを目的としています。

2000年から始めたJava教育ですが、今年は、OG/OB会を開催する計画です。

2012-03-10 07:30 nice!(0) コメント(0) トラックバック(0)

組織の生産性　 [ソフトウェア開発組織が持つべきカルチャー]

プログラマー”まだまだ”現役続行 (技評SE選書)

作者: 柴田芳樹
出版社/メーカー: 技術評論社
発売日: 2010/09/04
メディア: 単行本（ソフトカバー）

拙著の「第12章　30代、40代の人たちへ」からの引用です。

組織の生産性

　自分自身が継続して学習を続けるというのは、自分自身の成長だけでなく、若手エンジニアや自分が属する開発組織のメンバーにも大きな影響を与えます。ソフトウェア開発では個人差は確かに大きいです。作り出すコードの可読性も含めた総合的な生産性の差には、個人差があります。したがって、長い時間をかけて個々のエンジニアのスキルを向上させていく必要があるのです。そのためには、開発組織の中に見習うべき習慣を持っている先輩や上司がいなければ、その組織の中で若手が勝手に成長するのを期待するのは無理です。

　開発組織の生産性の差は、個人差以上に大きいです。私自身は、様々な開発組織で働いてきましたし、自分自身の開発組織で若手を育成したこともあります。どんなに優秀な新卒新人であっても、間違った開発組織に属してしまうと、数年で変な癖がついてしまい、学習しないことが当たり前になったりします。その結果、経験年数が全く当てにならなかったりするのです。

　継続した学習の習慣化、読みやすいコードを書くことや防御的プログラミングの教育と徹底、コードレビューの徹底を行ってきた組織と、全く何もしなくて本人の成長に任せるだけできた組織では、当たり前ですが、開発組織としての生産性は大きく違います。

　また、1990年代まで当たり前に行われていた手動によるソフトウェアのテストを今日でも当たり前だと思って行っている開発組織と、テスト駆動開発による自動テストを行っている開発組織では、その生産性は大きな差なのです。そして、どちらの組織に属したかによって、若手エンジニアの成長は大きく異なるのが今日のソフトウェア開発の現状です。

　開発組織の生産性の差を作り出すのは、若手エンジニアではなく、30代、40代のエンジニア、マネジャー、管理職だったりするのです。継続した学習をしてこなかった人たちが、ソフトウェア開発組織の中堅となった場合には、その組織全体が成長しなくなってしまう危険性があります。つまり、ソフトウェア開発に対する誤った古い考え方でソフトウェアを開発することになる可能性が高くなります。

　たとえば、1990年代前半は、「オブジェクト指向といえば継承」ということで、差分プログラミングが盛んでしたが、それは利点よりも問題を多く作り出すということで、1995年に出版された『Design Patterns』（翻訳『デザインパターン』は1999年出版）では、「クラス継承よりもコンポジション」を主張していますし、2001年に出版された『Effective Java プログラミング言語ガイド』でも、「継承よりもコンポジション」と主張しています。「オブジェクト指向といえば継承」で学習が止まった人たちがソフトウェア開発組織内の中堅以上を占めてしまうと、今でも継承だけでソフトウェア開発が行われてもおかしくはありません。

　このように、30代、40代となっても継続した学習をすることは、自分だけでなく、自分が属している開発組織の能力にも大きな影響を及ぼすことになります。

あるファイルに記述された形式を大量に別の形式のファイルへ変換するのは本来なら変換プログラムを作成するのが当たりまえです。しかし、時間をかけて手作業で転記し、さらに転記ミスが原因で障害が発生している言い訳が、「担当者のスキルが低いから」と平気で中堅リーダーから言われると、やはり現場の担当者が組織の生産性を下げているのではなく、マネジャーが組織の生産性を下げていると再認識してしまいます。

2012-03-09 08:27 nice!(0) コメント(1) トラックバック(0)

プログラミング言語Go関連の書籍　 [golang]

Googleが開発しているプログラミング言語Goの最初の正式リリースが近づいてきており、それに合わせて、2冊の書籍が執筆されています。

The Go Programming Language Phrasebook (Developer's Library)

作者: David Chisnall
出版社/メーカー: Addison-Wesley Professional
発売日: 2012/05/19
メディア: ペーパーバック

Programming in Go: Creating Applications for the 21st Century (Developer's Library)

作者: Mark Summerfield
出版社/メーカー: Addison-Wesley Professional
発売日: 2012/05/21
メディア: ペーパーバック

私自身は、2年ぐらい前から月1回の勉強会を通して、本格的ではないですが学んでいます。上記の『The Go Programming Language Phrasebook』に関しては、英語版のドラフト段階でのレビューを通して、私自身が学ぶと同時に様々なフィードバックをすることができました。

2012-03-08 05:06 nice!(0) コメント(0) トラックバック(0)

コードレビューの視点 001　[コードレビューの視点]

Copyrightを書く

1984年に社会人となって開発に従事したFuji Xerox 6060 Workstationでは、ソースコードにきちんとCopyrightを書いていたかどうかは覚えていない※のですが、それ以降のプロジェクトでは、ソースコードにはCopyrightを表記するのが当たり前の文化の中で過ごしてきました。

※ たぶん書いていたと思うのですが・・・

Copyright表記そのものは、XDE（Xerox Development Environment）のエディタでは自動的に挿入・更新を行ってくれたりもしましたが、そうでない環境でも手作業でも必ず記述する習慣となっていました。そのため、私自身が書いたC++言語用コーディング規約にもCopyrightを記述することを規定していました。

企業でソフトウェアを開発する上でCopyrightを記述することは、私にとっては当たり前だとずっと思っていましたが、そうではない組織も数多く存在することに驚いています。そのため以下のことが起きていたりします。

Copyrightの記述がないことをコードレビューで誰も指摘しないし、Copyright表記がないソースコードが組織内に多数存在する。
Copyrightを記述すべきだという認識を開発者が持っていない。
開発者がCopyrightの書き方を知らない。

たった一行のCopyrightさえ書かない、書けない開発者が多数いるソフトウェア開発組織は、日本全体を見ると多数存在するのでしょうか？

ソースコード上のCopyright表記はソフトウェアの実行には全く関係ないのですが、企業の資産としてソースコードにCopyright表記をしない組織文化は、ソースコードを軽視していることの現れかもしれません。

2012-03-07 08:04 nice!(0) コメント(0) トラックバック(0)

週報会　 [プログラマー現役続行]

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

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

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

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

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

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

2012-03-06 08:23 nice!(0) コメント(0) トラックバック(0)

雑誌『大人の科学マガジンＶｏｌ．３３（卓上ロボット掃除機）』　[本]

大人の科学マガジンＶｏｌ．３３（卓上ロボット掃除機） (学研ムック　大人の科学マガジンシリーズ)

作者:
出版社/メーカー: 学研教育出版
発売日: 2012/01/30
メディア: ムック

購入して組み立ててみました。モータ駆動だけが電池だけで、あとはすべて機械式なのですが、机の端に来るとくるりと右に回って方向転換します。障害物にぶつかっても右に方向転換します。掃除させるというよりも、ルンバと同じで動きを見ているのが楽しかったりします。欠点は、動作時の音がうるさいことです。

2012-03-05 04:57 nice!(0) コメント(0) トラックバック(0)

ソフトウェア開発組織が持つべきカルチャー 013　[ソフトウェア開発組織が持つべきカルチャー]

自分で書いたコードを自分で見直す

コードレビューがきちんと定着しているかどうかの目安の一つとして、開発組織の各メンバーが自分が書いたコードを自分で見直しているかということがあります。形式だけのコードレビューしか行っていなければ、書かれたコードはまともになっていることなく、その結果、書いた本人でさえ自分のコードを見直したりしなかったりします。

自分で見直した結果のレベルは、本人が持っている能力に依存します。しかし、きちんとしたコードレビューが行われていれば、レビューを受ける回数が増えるに従って本人が見直して改善できるレベルも向上してきます。

もし、きちんとしたレビューをしない組織に運悪く属したら、自分自身で様々本を読んで、意識して良いコードを書くことを実践していくしかありません。そのためには、良いコードとはどんなコードであるかを書籍を通して学ぶが手っ取り早いです。その意味で推薦しているのが『Clean Code』や『実装パターン』です。