So-net無料ブログ作成

開発組織のDNA(2) [プログラマー現役続行]

以前、「開発組織のDNA」を書きました。ソフトウェア開発は、生物ではないのですから、DNAは存在するのではなく、形成されていくものだと思います。しかし、一度形成されると世代間に遺伝していくのかもしれません。

ハーラン・ミルズが述べているように、「企業自体の生産性にも10倍の開きがある」というは、様々なソフトウェア開発組織で働いて経験からして、当たっていると思います。しかし、一つの組織の中で長年属していると、その開発組織のDNAに染まっていき、客観的に自分達の生産性を知ることはできなくなってしまうのではないかと思います。つまり、自分たちが行っているソフトウェア開発のやり方に疑問を持たなくなってしまいます。

そのDNAを変えるには、外の世界を知る必要があります。そのための手段の一つが、書籍を通した学習と学んだことの実践です。実際にやってみて良いと思われることはどんどん取り入れていくということです。

しかし、日本企業では、学習することを止めてしまった多数の中堅エンジニアで占められてしまうことがあります。そうなると、その組織では、「継続した学習」というDNAは形成されることなく、ソフトウェア開発の現場であっても、書籍がほとんど見当たらなかったりするかもしれません。

今まで私が属してきた開発組織の多くでは、量の多い少ないはありますが、ソフトウェアエンジニアの机の上やパーティションには多くの自費で購入された書籍が置いてありました。私自身も、転職で退職する度に、大量の本を持ち帰るのに苦労したものです(そのため、今は最低限の本しか会社には持っていかないことにしています)。

開発の現場にどれだけ自費で購入された書籍があるかは、どれだけ継続して学習する意欲がある人達の集団であるかのバロメータなのかもしれません(「時間の投資」)。

オープンラボ岡山(2) [プログラマー現役続行]

岡山での講演では、多くの人達が、休日にもかかわらず参加してくださいました。当日、資料の電子版をもらえないのでしょうかと一人の参加者から聞かれたのですが、電子版は配布していませんとお断りしました。しかし、その後、話の内容を社内に展開したいという話が何件かありました。

ということで、オープンラボ岡山に参加してくださった方々に、以下の条件で「ソフトウェアエンジニアの心得」の電子版(PDF)を差し上げますので、必要な方はお知らせくだださい。

[1] 社内で電子版では配布しない。必ず、印刷したものを配布してください。
[2] 社外に電子版を配布しない。

会社名を明記してもらって、「オープランラブ岡山の資料希望」という件名で、私宛にメールをください。

岡山では、倉敷、岡山城、後楽園(日本三名園の一つ)を、妻と見て回り、少し歩き疲れましたが、良い旅でした。飯借(ままかり)も初めて食べましたが、美味しかったです。

書籍『アプレンティスシップ・パターン』予約可能 [プログラマー現役続行]

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得

  • 作者: Dave H. Hoover
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/07/08
  • メディア: 単行本(ソフトカバー)

予約可能になりました。

内容
アプレンティスシップとは「徒弟制度」のことで、中世ヨーロッパに広く普及した職人の組合「ギルド」で用いられていた職人養成制度です。アプレンティス(徒弟)のほか、ジャーニーマン、熟練職人と、技術習熟度により段階分けされ、職人は仕事と心がけを学びながら技を習得し、日々腕を磨きました。本書は、徒弟制度をモデルとし、真のソフトウェア熟練職人を目指すためのパターンをまとめたものです。新しい技術の登場と絶え間ない変化に柔軟に対応し、ソフトウェア開発を生涯の仕事とするための心得とパターンを紹介します。意欲ある新人ソフトウェア開発者、またソフトウェアの匠を目指す技術者必携の一冊です。

目次
翻訳の技芸
本書によせて
まえがき
ソフトウェア職人マニフェスト
1章 序論
2章 カップを空にする
  最初の言語(Your First Language)
  白帯(The White Belt)
  情熱を放つ(Unleash Your Enthusiasm)
  具体的スキル(Concrete Skills)
  無知をさらけ出す(Expose Your Ignorance)
  無知に向き合う(Confront Your Ignorance)
  難しいこと(The Deep End)
  得意領域へ撤退(Retreat into Competence)
  まとめ
3章 長い道のりを歩む
  長い道のり(The Long Road)
  芸術より技芸(Craft over Art)
  持続可能なモチベーション(Sustainable Motivations)
  情熱を育む(Nurture Your Passion)
  自分の地図を描く(Draw Your Own Map)
  肩書きを活用する(Use Your Title)
  現場に留まる(Stay in the Trenches)
  別の道(A Different Road)
  まとめ
4章 正確な自己評価
  最低である(Be the Worst)
  良き指導者を見つける(Find Mentors)
  気の合った者同士(Kindred Spirits)
  同席する(Rubbing Elbows)
  床を拭く(Sweep the Floor)
  まとめ
5章 永遠の学習
  処理能力を広げる(Expand Your Bandwidth)
  練習、練習、練習(Practice, Practice, Practice)
  壊してよいオモチャ(Breakable Toys)
  ソースを活用する(Use the Source)
  自分の仕事を省みる(Reflect As You Work)
  学びを記録する(Record What You Learn)
  学びを共有する(Share What You Learn)
  フィードバック・ループを構築する(Create Feedback Loops)
  失敗から学ぶ(Learn How You Fail)
  まとめ
6章 自分のカリキュラムを作る
  読書リスト(Reading List)
  継続した読書(Read Constantly)
  古典を学ぶ(Study the Classics)
  徹底的に調べる(Dig Deeper)
  精通したツール(Familiar Tools)
  まとめ
7章 結論
付録A パターン一覧
付録B 徒弟制度募集
付録C Obtiva社徒弟制度プログラムの初年の振り返り
付録D オンライン情報
参考資料
訳者あとがき
索引

オープンラボ岡山 [プログラマー現役続行]

6月19日(土)午後に、オープンラボ岡山で話をしました。様々な質問があり、私自身色々と考えることができて、良い機会となりました。20日(日)は、天候は曇り(一時雨)でしたが、倉敷を歩いてゆっくりと観光して見て回りました。

ちょっと前とは違って、最近は話を聞きながら、参加者がTwitterでつぶやいているのが特徴的だと思います。今回は、アンケートは用意しておかなかったのですが、Twitterでつぶやかれている内容を読むと、話をどのように受け止めてもらえたかが分かります。

 オープンラボ岡山のタグ

書籍『アプレンティスシップ・パターン』は、7月7日発売予定 [プログラマー現役続行]

Amazon.co.jpでは、まだ予約注文できませんが、7月7日に発売予定です。

ap.jpg

タイトル: アプレンティスシップ・パターン
サブタイトル: 徒弟制度に学ぶ熟練技術者の技と心得
著者: Dave Hoover(デイブ・フーバー)、Adewale Oshineye(アデウェール・オシネエ)
翻訳: 柴田 芳樹
定価: 2,200円(税抜)
ISBN: 978-4-87311-460-6

裏表紙の紹介文より
 アプレンティスシップとは、「徒弟制度」のことで、中世ヨーロッパに広く普及した 職人の組合「ギルド」で用いられていた職人養成制度です。アプレンティス(徒弟) のほか、ジャーニーマン、熟練職人と技術習熟度により段階分けされ、職人は仕事と 心持を学びながら技を習得し、日々腕を磨きました。
 本書は、徒弟制度をモデルとし、真のソフトウェア熟練職人を目指すためのパターンをまとめたものです。新しい技術の登場と絶え間ない変化に柔軟に対応し、ソフトウ ェア開発を生涯の仕事とするための心得とパターンを紹介します。意欲ある新人ソフ トウェア開発者、またソフトウェアの匠を目指す技術者必携の一冊です。

開発環境 [プログラマー現役続行]

大学からコンピュータを使い初めて、開発用端末と言えば、80桁x24行でした。就職して、Fuji Xerox 6060 Workstationの開発に従事したのですが、しばらくは、同じような端末を使用して開発していました。ところが、Star Workstationを開発している部門は、XDE(Xerox Development Environement)と呼ばれる開発環境上で、マルチウィンドウ、ビットマップディスプレイ、Ethernet、レザープリンタという環境で開発していました。

4.3BSDが登場した時に、XNS(Xerox Network Systems)用のプロトコルスタックとXDE(Xerox Development Environement)用のツールがリリースされました。その中にREdit(Remote Edit)というツールがあって、Unix上のソースコードをXDE上で編集するためのツールでした。

どうしても、XDE上から6060 Workstationの開発を行いたくて、REditをリバースエンジニアリングして(ネットワークトラフィックを解析したような記憶があります)、同じ機能のものを6060 Workstation上に作成して、XDE上を使用して開発できるようにしました。XDE上での開発は、80桁x24行の端末とは比較にならないぐらい便利でした。

その後、Sun Workstationを使用した開発をずっと続けていました。2003年ぐらいから、PCでLinuxを使用して開発をするようになったのですが、2009年の夏まではWindows PC一台、Linux PC二台という環境で開発を行っていました。

開発環境を整えたからと言って、すべての人が、効率的に高い生産性で品質の良いコードを作り出すとは限りません。しかし、あまりにも貧弱な開発環境は、ソフトウェア開発の生産性を低下させます。

今時、80桁x24行の端末で開発している人はいないと思います。しかし、実際には、同じことが行われているソフトウェア開発の現場は多いのではないでしょうか。つまり、Windows上からDOS窓でUnixサーバーにログインして使っているとかです。

社会人になって、貧弱な環境でずっと開発をしていると、それが当たり前だと思ったりしてしまいます。あるいは、色々な開発環境を経験したことがないと、貧弱な環境だと認識できなかったりします。日本オラクルで働いていた時(1996年後半)に、開発者がデータベース上にあるPL/SQLのソースコードを見たり編集したりするのに、SQL文を手作業で実行し、その結果を見ているのには驚きました。みんなそうしていたので、そうするのが当たり前だと思われていたのです。それで、若いエンジニアにJDBCを使用して、ビューアを作るように指示して作らせたということがあります。

バグが直りました? [プログラマー現役続行]

不具合が発生して、原因を調査していた担当者から、原因が分かって修正しましたと報告があった場合、報告を受けた側としては、以下の点を確認する必要があります。
  • 不具合の原因の説明をしてもらう
  • 修正内容を説明してもらう
  • 同じような不具合が他の場所にも無いかの確認を行ったかを報告者に聞く
  • 同じような不具合を今後未然に防止する方法はないかを報告者に聞く
報告を受けている側の経験によっては、原因の説明を聞いた時点で、残りの項目に関しては答えが出ている場合があります。しかし、あくまでも担当者に聞く必要があります。聞くことによって、担当者がどのような取り組み方をしているのかが分かるからです。

経験の浅い人でしたら、原因から論理的に不具合を説明できなかったり、修正方法が間違っていたりするかもしれません。経験がある程度あっても、3番目と4番目にまでは考えが及んでいなかったりします。

しかし、上記4項目を全く聞くことなく、不具合が直りましたという報告を聞いて終わりにすると、何の改善も行われることなく、担当エンジニアも成長しませんし、その開発組織そのものが成長しなくなってしまいます。

ソフトウェア開発組織はオーケストラ(3) [プログラマー現役続行]

ソフトウェア開発組織では、個々のソフトウェアエンジニアが高い能力を発揮して、協調してソフトウェアを開発するという意味で、オーケストラであるということを以前書いています。

ソフトウェア開発組織はオーケストラ
ソフトウェア開発組織はオーケストラ(2)

先日、ある研修で話を聞いていて、指揮者の観点からするとソフトウェア開発はオーケストラなのかと疑問に思いました。オーケストラでは、個々の楽員のパフォーマンス(アウトプットの質)は、指揮者には分かります。しかし、ソフトウェア開発では、開発組織の長には、個々のソフトウェアエンジニアのアウトプットの質は、容易には分かりません。

「アウトプットの質」とは、書かれた「コードの質」を私は意味しています。コードの質は、実際にコードを読まないと分かりません。つまり、オーケストラの指揮者と異なり、ソフトウェア開発では、個々のソフトウェアエンジニアが高いパフォーマンスを発揮しているかが、容易には分からないのです。つまり、下手な演奏を行ってコンサートを台無しにしている楽員がいても、そのことに気付かずに演奏を続けているのが、ソフトウェア開発なのかもしれません。

オーケストラの例で言えば、演奏者は、練習を重ねて上手く演奏できるようになるまでは、オーケストラのメンバーにはなれないのです。そして、指揮者は楽員のパフォーマンスを容易に判断できるのです。したがって、現実のソフトウェア開発のモデルとしてのオーケストラは間違いなのかもしれません。

書籍『ゆるい生き方』 [本]

ゆるい生き方 ‾ストレスフリーな人生を手に入れる60の習慣〜

ゆるい生き方 ‾ストレスフリーな人生を手に入れる60の習慣〜

  • 作者: 本田 直之
  • 出版社/メーカー: 大和書房
  • 発売日: 2010/05/22
  • メディア: 単行本(ソフトカバー)

本書を読むと、確かに、日本ではストレスの多い生き方をしているなと再認識されます。米国に住んでいた頃は、ゆったりしていることが多かったものです。次の人のためにドアを開けて待っているというのは、当たり前でした。

1988年11月に米国に駐在してから、2年間帰国しなかったのですが、日本に帰ってみると色々なところで、逆カルチャショックを感じたものです。でも、長年また日本に住んでいると、慣れてしまいますが、本書は、ストレスが多い社会に生きているなということを思い出させてくれました。

防御的プログラミングとカバレッジ [プログラマー現役続行]

防御的プログラミングでは、外部からの呼び出しから防御します。しかし、それ以外に、自分自身の誤りに対して防御するということがあります。

次のコードは、『Effective Java 第2版』(p.147)に掲載されているコードです。
// 値によって切り替えるenum 型- 問題が多い
public enum Operation {
    PLUS, MINUS, TIMES, DIVIDE;

    // 定数で表される算術操作を行う
    double apply(double x, double y) {
        switch(this) {
            case PLUS:   return x + y;
            case MINUS:  return x - y;
            case TIMES:  return x * y;
            case DIVIDE: return x / y;
        }
        throw new AssertionError("Unknown op: " + this);
    }
}
ここで、注目するのは、最後のAssertionErrorをスローしている部分です。定義したenumの定数値はすべてcaseラベルで列挙されていますので、例外がスローされることはありません。

後々の保守や機能追加で定数値が追加され、caseラベルの追加を忘れた場合に、そのことを検出するための防御的プログラミングとなります。つまり、switchで、defaultラベルを書いて普通の処理をするのではなく、すべてcaseラベルで列挙し、defaultラベルではAssertionErrorをスローすることで、「設計上、起きてはいけないことが起きている」ことを検出できるようにしておきます。

このようなプログラミングは、呼び出しパラメータの不正値の検査と同様に、障害を短時間で調査するためには重要です。

一方、このような防御的プログラミングを行っていないソフトウェア開発組織では、テストによるコードカバレッジは、単体テストでは100%でなければならないという目標値を設定してしまいます。当然、上記のコードでは100%は無理です。AssertionErrorをスローしている部分は、どんなに頑張っても実行することはできません。

ソフトウェアの開発効率、特に、障害の短時間での原因調査と対策を行うのに有効なのはコードカバレッジ100%ではありません。有効なのは防御的プログラミングです。上記のコードで、カバレッジを100%にするために、applyメソッドが次のよう書かれたとしてみてください。
    // 定数で表される算術操作を行う
    double apply(double x, double y) {
        switch(this) {
            case PLUS:   return x + y;
            case MINUS:  return x - y;
            case TIMES:  return x * y;
            default:
                       return x / y;
        }
    }
enum定数値を追加し、caseラベルの追加を忘れても、コードカバレッジ100%なのです。そして、caseラベルの追加を忘れで障害が発生しても、すぐには原因が分からないかもしれません。

コードカバレッジ100%を常に達成していますと言う開発組織があったとしたら、このような防御的プログラミングは一切行っていないことを意味すると思います。