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

Source Code Controlへ最低でも毎日コミットする

今更言うまでもないですが、SubversionなどのSource Code Controlを使用するのは当たり前です。しかし、意外と普段の開発で使用していない人やチームがあったりします。

たとえば、プロトタイプ開発で開発者のPCにしかソースコードが存在しなかったりします。開発者に、プロトタイプのソースコードはどこにあるのかとか、きちんとソースコード管理に入れているのかと聞くと、開発者のPCにしかなかったりするのです。そして、チームリーダがソースコード管理に関心を持っていないため、ソースコードがそのような状態で開発が続けられていることがあります。あるいは、時々一つのファイルにまとめてバックアップしていますとか。

日々の開発では、最低でも一日に一回はコミットして帰るのが原則です（本来、コミット頻度はもっと多いはずですが）。しかし、開発者のPCにしかソースコードが存在しないような状況であれば、本来チームリーダは、Subversionなどに入れなさいとか毎日コミットしなさいと言い続ける必要があります。そうでなければ、明日の朝、開発者のPCが立ち上がらなくなって、コミットしていないソースコードを失ったり、開発者が何かの事情で長期休みになった時に、開発が進んでいたはずなのに、実際にはソースコードが無いという状況が発生することになります。

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

コードをレビューする

最近では、コードをレビューすることの重要性は多くの書籍で述べられています。しかし、組織によっては「レビューを行った」という事実が重要視されて、「質の高いレビューが行われた」ということにほとんど関心が払われていない場合があります。そうなると、実際にシステム全体を結合テストすると、非常に初歩的なコーディングミスで障害が発生することになります。

1999年の頃だったと思いますが、2週間以上調査された不具合の報告会に出た時に原因が「変数の初期化忘れ」というものでした。それで再発防止策として何があるのかと聞かれて、コードをレビューすれば良いのではと回答したら、「じゃ、ガイドを書け」と上司から指示されて、「Code Review Guide」を書きました。

当然、ガイドを書いただけではレビューは定着しませんので、ガイドの教育を多くのエンジニアに行い、実際のレビューを私自身が行いました。当時、C++言語での組込開発が始まることもあって「C++ Coding Standard」を書いて、さらに「Memory Management Library for C++」「Thread Library for C++」と関連するライブラリの設計も行いました。そのようなガイドやライブラリを実際に使用する開発チームに対しては、2000年の後半から2002年初め頃まで、ほぼ専任のレビューアとして現場でレビューを行っていました。多い時には、週に4日ぐらい一日中レビューということありました。

今日では、フォーマルなレビューからペア・プログラミングを通してのレビューなど様々なレビュー形式があると思います。しかし、重要なことは、コードの読みやすさ、エラー処理、防御的プログラミングなど様々な観点からコードがきちんと書かれているかをレビューすることです。

特に初心者のコードは徹底してレビューする必要があります。そうでなければ、先輩達が経験してきたであろう間違いをもう一度実体験することで、結果的にプロジェクトの開発期間を延ばしたり、デスマーチを引き起こしたりする場合があります。

たとえば、C言語でローカル変数のアドレスを関数から返したり、他のスレッドやタスクに渡した場合にはどのような挙動になるのかは不定です。それが原因で発生する障害の調査には時間がかかったり、仮に障害が修正されても、QA部門によりバグ管理されて、そのためのバグDBの更新、ソフトウェアの再リリース、QAでの再確認という追加工数が発生して、結果としてプロジェクトの工数を増大させてしまいます。一方、開発内でのレビューでこの程度の初歩的な誤りは指摘して修正していれば、将来プロジェクト全体に余分な追加工数を発生させることを未然に防ぐことができる訳です。

ソフトウェアの品質を上げると同時にプロジェクト全体の工数を減らすには、きちんとしたレビューに工数をかける必要があります。しかし、現実は「品質の作り込みよりスケジュール優先」ということで途中の中間マイルストーンは守れても、結合テストに入ると多くのバグを出してプロジェクト全体のスケジュールを延ばしてしまうソフトウェア開発が多いのではないでしょうか。

ソフトウェア開発のスケジュールでは、いい加減な開発でも結合テストまではスケジュールが守れたという「奇跡」※を恣意的に起こすことはできますが、品質の悪いソフトウェアでは結合テストの終わりのスケジュールを守るという奇跡を起こすことはできません。

※ Robert Martin著の『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』の付録には「奇跡」の面白い話が掲載されています。

読書会『言語設計者たちが考えること』終了しました

言語設計者たちが考えること

• 作者:
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/09/27
• メディア: 大型本

昨年の11月から始業前に読書会ということで週に1回1時間読んでいたのですが、やっと読み終えました（【社内連絡】『言語設計者たちが考えること』読書会参加者募集）。今年の7月、8月、9月はサマータイムのために読書会は開催しなかったので、約10ヶ月かかりました。

様々な、言語作成者に対するインタビューが掲載されており、設計された言語の背景だけでなく、ソフトウェア開発全般に対する様々な面に対する考えが掲載されています。面白かったのは、UML 2.0に対する評価がイヴァー・ヤコブソン、ジェームズ・ランボー、グラディ・ブーチの3人で違うことです。また、Xerox PARC（Palo Alto Research Center）の話が出てくるインタビューもいくつかあり、PARCで働いていた30代初めの頃が懐かしく思い出されました。

内容の量が多いですが、興味がある部分だけでも拾い読みしてみると良いかと思います。

書籍『New Programmer's Survival Manual』

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

• 作者: Joshua Carter
• 出版社/メーカー: Pragmatic Bookshelf
• 発売日: 2012/01/06
• メディア: ペーパーバック

まだ読み始めたばかりです。Tipということで33のTipが掲載されています。それぞれのTipには白帯や黒帯が先頭に描かれていて、対象とするレベルが分かるようになっています。

冒頭の『Introduction』では、黒帯の話題に関しては5年以上の人達を対象と書いてあるのですが、次のようなことも書かれています。

In real life, true mastery begins more around year ten.

「ソフトウェア開発組織が持つべきカルチャー 005」でRichard Gabrielの言葉を紹介していますが、やはり10年以上はかかるということでしょう。

Tip 3では、100%カバレッジに関して、次のように述べられています。

Don't be lulled into complacency by 100 percent coverage: it means nothing about the quality of your code or your tests. Writing good tests, just like writing good application code, requires thought, diligence, and good judgement.

マネジメントは何らかの品質指標が欲しくてその1つにカバレッジ率を挙げている組織も多いと思います。カバレッジ100%は単にコードがすべて実行されただけであり、メモリリークやメモリ破壊をしているコードでもカバレッジ100%だったりする訳です。したがって、カバレッジ100%というのは、品質に関して何も意味を持たないということです。

書籍『Jenkins実践入門』

Jenkins実践入門　～ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

• 作者: 佐藤 聖規 監修・著
• 出版社/メーカー: 技術評論社
• 発売日: 2011/11/11
• メディア: 単行本（ソフトカバー）

CIツールであるJenkinsの解説書です。目的に応じて、様々な設定について説明されています。継続的インテグレーションやJenkinsに興味がある人にとっては、導入する際に手元に置いておいて参考にすることができます。すでに、Jenkinsを使用している人であれば、自分が知らない新たな発見があると思います。

継続的インテグレーションは、どのような開発プロセスを使用していても必須だと言っても過言ではありません。ウォータフォール開発しているとかアジャイル開発ではないから関係ないというものではありません。

この本のカバーには次のように書かれています。

「手作業でミスが多発」
「別の環境だとビルドできない」
「結合テストで修正地獄に]
「リリース直前なのに動作しない」
↓
自動化でストレスはゼロに
品質は最高に

どのようなソフトウェア開発でも起きる問題なのです。

私自身が初めてビルド作業を完全自動化して夜間ビルドを導入したのは,
Fuji Xerox DocuStation IM 200の開発の時でした。1993年から開発に着手して1996年初めに商品化されました。私自身も7、8万行程度の製品コードを書く一方で、夜間ビルドやNFSを活用した分散コンパイルなど様々改善を行いました。自動化するきっかけは、二週間に1回の定期リリース日にビルドがほぼ100%失敗することでした。それで頭にきて、毎晩自動でビルドするようにしたのです。それからはリリース日にビルドが失敗していることはなかったのですが、まだ手作業でテストする時代でしたので、リリース用テストで障害がたくさん見つかるということを繰り返していました。

1990年代は夜間ビルドの時代であり、2000年代からは継続的インテグレションの時代で、さらに発展して継続的デリバリーの時代に突入しようとしています。残念ながら、多くのソフトウェア開発現場では、今も手作業でビルドが行われ、この本のカバーに書かれているような問題が多発しているのではないでしょうか。

初期のCIツールであるCruiseControlを2007年頃に使用した時と比べると、Jenkinsは非常に進歩しています。開発者自身が、手作業というの労働集約型開発から解放されて、知識集約的活動に集中するためには、CIツールは必須です。その意味で、このような書籍が執筆されたことは、今後、日本のソフトウェア業界の生産性向上に貢献してくれることを期待しています。

私自身も、昨年10月にそれまで手作業で行われたいた自部門のビルド環境を、Hudson/Jenkinsを使用して完全に自動化に着手して、若手のエンジニアと二人で3ヶ月で、ほとんどの手作業を自動化しました。それまでは、上手く行っても3時間かかる手順を、ビルド担当者が手作業で行っていたのですが、今は、同じことが15分程度で自動で行われます。自動化作業に着手した時に、本書があれば、もっとスムーズに作業が進んでいたかもしれません。

手作業の問題点は、手順書にすべてが書かれておらず、ビルド担当者しか知らない前提条件や手順が多くあったりすることです。そのため、手作業を自動化するというのは、その部分を明らかにして各種スクリプトへ落とし込んでいく必要があります。

本書では述べられていませんが、自動ビルド環境を整えても終わりではありません。エンジニアに躾をしなければならないのです。プライベートビルドをしてからコミットするとか、ビルド結果をきちんと確認して、素早く対応させるとかです。その意味で、合わせて『継続的インテグレーション入門』も読まれると良いと思います。

継続的インテグレーション入門 開発プロセスを自動化する47の作法

• 作者: ポール・M・デュバル
• 出版社/メーカー: 日経BP社
• 発売日: 2009/08/06
• メディア: 単行本（ソフトカバー）

高価なソフトウェアを購入しなくても、Jenkinsのようなツールがオープンソースで利用できる時代です。まだ、手作業でビルドを行っているのであれば、『Jenkins実践入門』を参考にJenkinsの導入を試してみてください。そして、「作業はコンピュータに、人間は創造的活動を」目指してください。

ルンバ780

先月、思い立ってヨドバシ町田店に行って「ルンバ780」を購入しました。いわゆる、掃除ロボットです。

http://www.irobot-jp.com/special/700series/

掃除ロボットを買うのは、なんとなく無駄な気がずっとしていたのですが、買ってみて分かったのは「必需品」だということです。どういう意味で必需品かと言うと、洗濯機の登場により洗濯機が家庭にとっては必需品と同じぐらいです。つまり、それまで人手で行っていたことを機械が自動で行ってくれて、（主婦の）自由が時間が増加するということです。

従来の掃除機だと、どうしても人が掃除機を使って掃除をする必要があります。ルンバだと勝手に行ってくれます。その意味で、洗濯機と同じなのです。ルンバによる掃除が一時間かかっても、機械が自動的に行ってくれますの非常に楽です。

唯一掃除が上手くできない場所は、私の書斎です。床に本が積んであったりして、部屋のものを一度外へ出さないと本の山がルンバで崩壊してしまいます。何とか書斎を綺麗にしないとといつも思っているのですが・・・・

カンファレンスは、若い人ばかり？

11月1日にGoogle Developer Day 2011に参加したのですが、私のような年齢の人はあまり見かけませんでした。やはり、若い人達がほとんどです。

どう考えても、同年代の人達が全員管理職となって組織の長になっているはずはないのですが、ほとんど見かけないのは、みなさん、技術に興味を失ったということでしょうか？

見方を変えると、今回参加した若い人達が、50代になった頃にこのようなカンファレンスに参加する人はどのくらいいるのでしょうか？