[books]Hackers and Painters : Big Ideas from the computer age


デザインとデベロップメントの関係に言及しているという意味でも非常に有名な本ですが、著者自身ハッカー(もちろん、悪い意味ではなく)でありながら成功している経営者であり、美術学校で絵画すら学んでいます。実存の成功者から語られる「技術者の気構え」はその書き口以上に重く、成功のために立ち止まることを許しません。「ものづくり」を愛し、極めようとする技術者の特性はいまさら私が書くようなものではありませんが、よく物語に出てくるような「田舎で隠遁生活を営む孤高の鍛冶屋」であっても日々の生活の糧のために鍬を作らなければならないし、ユーザーを獲得する必要があります。別のパターンで画家のようにパトロンを見つけるという手もありますが、いずれにしても「一流であること」が先に求められることは間違いなく、技術者が自らを先に一流であると位置づけて(生活を含めた)戦略を立てることにはリスクがあると思われます。色々書きましたが、読んで噛み締められる一冊だと思いました。特に現場で戦っている技術者にお勧めです。

[books]アートオブプロジェクトマネジメント


著者はマイクロソフトでInternet Explorerなどの大規模なプロジェクトをリードしていた人です。書籍の内容については細かい手法が書いてある訳ではなく、心構えや人間系のコミュニケーションの話などが中心になっています。400ページ超の規模ですから読み切るのには一苦労であありますが、「優れたビジョンを記述する」「アイデアの源」といった章については、エクスペリエンスデザインに通じる事も多く、お勧めしたい所です。(この2つの章だけで50ページあります!)当たり前のように書かれているものの実行になかなかいたらないものと感じたのは「3分の1ルール」というものです。すなわち、設計/開発(おそらくTDDレベルのテストを含む)/テストを3分割の重み付けで考えようというものです。現実的に品質を高めようと考えた場合には最初と最後にどれだけ時間を割り当てられるかが大事になりますね。

[Books]MY JOB WENT TO INDIA -オフショア時代のソフトウェア開発者サバイバルガイド–


久しぶりに書籍を紹介します。タイトルからして非常に刺激的ですが、MY JOB WENT TO INDIAです。
既に過去形であるあたりが非常にシビアですね!刺激的なタイトルとは裏腹に内容は大変まじめな内容であり、開発者がこれからの時代に心がけておくべきマインドの話をしています。個人的にはこれから開発者はビジネスを無視することは出来ないという流れが本の中にあることです。テクニカルスキルであってもビジネスであっても、貪欲に、自ら学ぶ姿勢を忘れずに他者との差別化を図っていきましょう、というメッセージでした。特に開発の現場にいる方全員に読んでほしい本ですね。

[books]ユーザビリティエンジニアリング—ユーザ調査とユーザビリティ評価

ユーザビリティエンジニアリング—ユーザ調査とユーザビリティ評価実践テクニック

この分野では定番とも言える一冊ではありますが、同僚に「ペルソナを作る時に良い参考書はありますか」と振られたので本棚をひっくり返してみたところ、やはりこれかなと思いまして紹介したいと思います。問題のペルソナに関する記述はもちろん、参考書籍として引用しているものを見ても著者がソフトウェアエンジニアリングに明るいことが分かります。もう一度真剣に読み返してみると、master/apprenticeアプローチなど素晴らしいメタファーも多く大変参考になりました。ユーザビリティそのものに興味がある方だけでなく、ソフトウェア開発に関わる全ての人にお勧めしたいです。

[books]アジャイルソフトウェアマネジメント

アジャイルソフトウェアマネジメント
TechEdでただでもらった本なのでしっかりと目を通していませんでしたが、ソフトウェア開発と経営管理というある視点では相反する要素を持った両者を総合的に理解しようとしている良書でした。有名な制約条件理論など生産管理上の概念がソフトウェア開発においてどのように統合できるか、視点を提供しています。自分が純粋な意味で開発者でなくなった時点で強く感じていることですが、developer happyのみを追求しても実はdeveloper happyは訪れないと考えています。ビジネスモデルというのはそんなに単純でないのが難しいところです。

FDDでもっとも重要に思えたもの

かつて紹介したこともあるFDDですが、個人的に大変重要と考えている部分があって、開発のマイルストーンにおいて、その達成率を定義しているところです。

意味のある単位に分割されたタスクを”開発”している際に、仮にタスクの達成を5日といった場合に3日目には60%の達成であるかどうか分かりません。逆にそんなに単純に考えると問題になる場合もあるでしょう。

FDDでは次のようなマイルストーンを設定します。


ユーザー機能単位設計

  1. 領域ウォークスルー(1%)
  2. 設計(40%)

  3. 設計インスペクション(4%)

ユーザー機能単位構築

  1. コード(45%)

  2. コードインスペクション(10%)

  3. 環境への統合(1%)

この計算式の中では、例えばコード完了時点で90%のタスク完成度ということになります。ユーザー機能では2週間で完了できるレベルへタスクを細分化するので(大規模システム開発の常識に照らせば)誤差は少ないとしています。2FCではもう少し小さい単位の方が良いでしょう。

設計から開発に至る順序の問題や、アジャイル視点での開発におけるイテレーション単位などの前提コンテクストがありますが、全体を俯瞰すればこの視点は興味深いです。また、インスペクション(レビュー)を大きなマイルストーンとして割り当てていることにも注目したいです。