ビジネスとプログラム両方の知識と経験が求められるソフトウェアアーキテクト。本書は世界中で活躍するソフトウェアアーキテクトによる97本のエッセイを収録した書籍です。プロジェクトにおいてもっとも重要な事柄とは何か、顧客やチーム、またコーディングやスケジュールなどについて、経験豊かなアーキテクトが自らの体験を踏まえて解説します。ソフトウェアアーキテクトを勇気づけ、新たな気づきをもたらす一冊です。日本語版では、伊藤直也、江島健太郎、小野和俊、榊原彰、鈴木雄介、萩本順三、萩原正義、牧野友紀による11本の書き下ろしを収録。

最近、日本でも「アーキテクト」というものが認知されてきた気がします。
その一方、アーキテクトの制限によってお客さまの要件を満たすことが困難になるという、本末転倒なことも。

このエッセイではアーキテクトの悩み、といったものも感じ取ることができます。アーキテクトでなくとも、アーキテクトと仕事をするすべての職種の方に有益な書籍です。

個人的に面白かったエッセイは以下のもの。

• 最大の問題は、たぶん技術的なことではない
• パフォーマンスの検討に早過ぎるということはない
• 要塞としてのデータベース
• パフォーマンスがまず大事
• ドワーフ、エルフ、ウィザード、キングの４種類の人々
• 現実の世界にようこそ
• デベロッパーに力を
• 理由を書き留めよ
• アプリケーションの保守に力を入れよ
• データがすべて
• 優れたコンテンツは優れたシステムを作る
• コンソメの重要性

ソフトウェアアーキテクトが知るべき97のこと

誰もが思い当たるパターンが満載。ユーモラスな名前で見えてくる失敗プロジェクト、成功する組織の姿。Jolt Awards受賞。

みんな大好きトム・デマルコの新刊です。
苦笑するしかない、IT業界のあるあるなネタが鋭く紹介されている良書。

個人的に面白かったパターンの見出しを以下に抜き出してみました。
たぶん色々考えさせられることもあるのではないでしょうか。オススメ。

• １　アドレナリンジャンキー
  アドレナリン中毒の組織は、猛烈に動き回ることが健全な生産力のあかしだと信じている。
• ３　死んだ魚
  プロジェクトが始まったその日から、目標を達成する見込みはゼロである。プロジェクトに関わる人のほとんどは、それを知っていながら何も言わない。
• ７　マニャーナ
  すぐに動き始め動き続けなければ仕事が片づかない。そう認識できる時間枠を越えて期日が設定されると、切迫感がなくなり、行動しようというモチベーションがうせる。
• １１　魂を貸す
  現場の人間に、長年かけて修得したスキルや技術を捨てる用意がある。
• 閑話
  無害と思える言葉に、不穏な意味が隠されている。
• ２５　沈黙は同意とみなされる
  相手には、あきらめの沈黙と同意の区別がつかない。
• ２８　[時間]に切り札を奪われる
  [時間]はひどいプロジェクトマネジャーである。
• ３０　ちびた鉛筆
  コスト削減の波が続くと、組織にはプロジェクトを完了する能力もなくなってくる。
• ３１　リズム
  チームは、一定の間隔をおくことによって、仕事のリズムをつくる。
• ３２　残業に見る予兆
  マネジャーは、早い時期から残業することを、プロジェクトの輝かしい健全性のあかしだと考えている。
• ３５　テスト前のテスト
  「テストにはテスト以上の意味がある（だからテストの前の始めるべきである）」―ドロシー・グラハム
• ３９　アトラス
  チームのリーダーが、（ほとんど）あらゆることに長けている。
• ４５　ニュースの改良
  悪いニュースが組織の下から上へ正確に伝わらない。
• ６４　レイクウォビゴンの子供たち
  マネジャーは、成績評価で優れた者と劣った者に十分な差をつけない。
• ６６　魂の仲間
  ある種のチームは、開発プロセスの最も基本的なルールさえ無視することが許される。
• ７４　サプライズ
  報奨やインセンティブを提供するマネジャーは、思いも寄らない反応を受ける。
• ７５　冷蔵庫のドア
  チームのメンバーは、作業の成果をいつも全員に見えるように掲示する。
• ７６　明日には日が昇る
  マネジャーは、将来の進捗の平均は過去の進捗の平均を上回ると信じている。
• ８３　身につかない教訓
  チームは間違いを認識しているが、それでも同じことを繰り返す。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

テストの結果を管理するツールです。
Tracなどのバグ管理ツールと連携することができます。

正直知りませんでしたが、それなりに有名なツールみたいですね。

ある程度規模が大きくなり、テスターも多くなるとやはりDBは使い勝手がよいですからね。

とはいえ、今のところあまりUIがよくないので、テスト管理者にはよくてもテスターには微妙な気がしなくもないです。

と、いうわけでメモ。

■ 参考
TestLinkJP – TEF有志によるテスト管理システムTestLink日本語化プロジェクト

きちんと学びたいテストエンジニアのためのTestLink入門：第1回　テスト管理システムとは何か？｜gihyo.jp … 技術評論社

炎上しているプロジェクトの場合、冷静に見てみると

いなければうまくいくのに。

って思う。

納得できない仕事に身を投じなければいけない、ということは、時として長時間働くこと以上に大きな苦痛をもたらすからです。

就職先の会社が理不尽な会社かどうかを判断する一番の近道は、「面接官を面接すること」です。

この辺に共感。

とはいえ、ほとんどが納得できない仕事なんじゃないかなーと。
そこを仕事とわりきれるかどうか。
ところが、実際問題として毎日12時間以上も作業をしているような状況で、わりきるのは難しいですよね。

その辺あきらめているような先輩、リーダーが溢れている状況でキャリアモデルを見つけるのも難しいですし。

身につくのは手を抜くスキルだけ。

そんな中、自分を見失わない人ってすげーって思います。

いや、もちろんステキなところもありますよ！？

ある…よね…？

■ 今読んでます

ソフトウェアアーキテクトが知るべき97のこと

「前のプロジェクトではこんな方法を使ったんだ」

ってね。だからオレは言ってやったんだ。

「ジョージ。君は僕たちを前のプロジェクトのメンバと同じ目にあわせるつもりかい？」

PMもSEもプロジェクトを運営するために必要な役割なわけで、どちらかが上で、片方がその下、という関係ではないはずです。

そう、なんですけどね。

今日、プロジェクトの PM のメールを見ていて、なんでそんな言い方するかなー、と思ったときに見つけたエントリだったのでメモ。

なんというか、言葉は丁寧なんだけど見下してる感が滲み出ていました。
それって本心で「PM である自分が上」と思っているからでは？とか思ってしまう こしあん が斜めなのかも。

まあ、腹を割って話すこともなく、会議とかメールの発言でしか PM を知らないわけで、お互いに理解とか尊重とかできるはずもないのだけど。
ドライな関係が悪いとは思わないです。が、それはお互いにあまりあるスキルがあれば、の話。
また、PM と SE の上下関係の意識って日本ぽいとも思います。

オマエが歩みよれって？
そだね。

Tracで見えてくるもの。：System Engineer Wars：So-net blog

シンヤはここ数日頭を抱えることばかりだ。Tracで要件管理をしているが、うまく進まない。

同意します。
今のプロジェクトが Trac で要件確認しているのですが、少なくとも疑問は感じます。

とはいえ、その理由についてはまったくこの方と違っていました。
この記事の方は、

決めなければならないことはたくさんあるし、検討していかないといけないことが無数に存在する。

と言っています。
管理することで今まで見えていなかったものが見えるようになった、ということでしょうか。

なんと前向きな。

ここで、「Trac で要件管理するのは無理だよ、やめようよ。」と考えてしまう。

現実問題として、要件を100%ガチガチに固めるのは無理で、曖昧さをうまく取り込んで（※）プロジェクトを進行する方がベターだと思います。

100%に近づけるのは誰もにとってストレスですしね。

とりあえずメモです。

※ お客さまとの同意が必須です！

==============================================================

Webアプリケーション開発のお仕事を探しています！
首都圏近郊であれば、常駐も可能です。

Webアプリケーションの新規開発・保守・カスタマイズの他、
Excel VBA や Eclipseプラグインなどのツール類の作成も請負います。

個人なのでスピーディかつフレキシブル（柔軟な）対応が可能です。
まずはお気軽にお問い合わせください。

【スキル】
Java/PHP/Perl, MySQL/PostgreSQL/Oracle, Struts/SAStruts など
その他のスキルについてはコチラをご覧下さい

【報酬】
応相談

【連絡先】
laguzlumi@gmail.com

==============================================================

よろしくお願いします<(＿ ＿)>

古い記事なのですが、気になる箇所を見つけました。

訂正のお知らせ（2009年3月31日）
読者から上記のサンプルコード、「while (objBr.ready())」について貴重なご指摘をいただき、コードを差し替え、また編集部注を追記させて頂きました。
内容について正確を期せずに混乱を招いた点、読者の皆様におわび申し上げます。

なぜか最近修正されています。
BufferedReader#ready() による判定から BufferedReader#readLine() の判定に変更されたということなのでしょうけど、変更内容について言及されていないのため、なにが問題だったのかわからないのです。

調べてみたところ、ready() に気になる記述がありました。

次の read() が入力をブロックしないのが確実な場合は true、そうでない場合は false。false が返されても、次の読み込みが確実にブロックするというわけでない
BufferedReader (Java 2 Platform SE 5.0)

ものすごくわかりにくいのですが、”falseでも読み込み対象がなくなったとは限らないよ”ということなんだと思います。疑わしきは false。
つまり、ファイル終端まで読み込むための判定とは目的が違うということです。

まあ記事の修正と関係あるのかはわかりませんが、ファイルなどを全部読み込む目的で ready() は使わないほうがよさそうです。

■ 参考
2003年12月のアレ

Javaファイル関連メモ(Hishidama’s Java File Memo)