トラックナンバー

我々の業界のソフトウェア開発にプロジェクトに限らず、そのプロジェクトに関わっている人に依存してしまう場合がほとんだと思います。工場での物理的なもの作りでないので人間系による依存は仕方の無いことであるのでしょう。そこで、ソフトウェア開発の世界では、プロジェクトメンバー構成のリスク管理指標の一つに「トラックナンバー」というのもがあります。その定義は

トラックナンバーとはトラックに轢かれるとプロジェクトの遂行が困難になる最少の人数

となります。典型的なカリスマ構成員一人の力で成り立っているプロジェクトではトラックナンバーが「1」となりプロジェクトが持つリスクは高まります。この数値は、プロジェクトメンバーがトラックに轢かれるという悲劇的なことをことを例としていますが、それに変わる指標としてハネームーンナンバーというものもあります。この定義は

チームのメンバーが順にハネムーンに旅立って行くパターンを全て考え、 何人目でプロジェクトが停止してしまうかの平均値

となります。こちらはハッピーな例であり、私自身も過去のプロジェクトに置いて主力メンバーがハネムーンでいなくなる状況を乗り切った経験があります。いくら忙しくてもハネムーンに行くなとは言えませんからね。この二つの指標はどちらも少し現実味が薄いように感じていました。ところが、最近のインフルエンザの流行により、インフルエンザナンバーというものが存在しこれはかなり現実味があるリスクであると思えます。プロジェクトメンバーの何人がインフルエンザにかかるとプロジェクトが破綻するかという観点でリスク管理が必要ですね。重要な情報は常にメンバー間で共有する事は大前提であることに加えて、リーダー自身が倒れる可能性もあるので、プロジェクトの目的とか各メンバーが独自に判断をする事が出来るような価値感の共有も必要になってきます。
経営層はどうしても、人件費の節約で最小人数で構成しようとしますが、メンバーのひとりひとりが100%以上でフル稼働するようではリスクに対して非常に弱いといえるでしょう。作業品質にも影響が出てくるはずです。物事をうまく制御してゆくには、車の運転でのハンドルの「あそび」同様な役割の「Slack」が必要となることも多いと思います。


ゆとりの法則 − 誰も書かなかったプロジェクト管理の誤解
発売元: 日経BP
価格: ¥ 2,310
発売日: 2001/11/26
売上ランキング: 63576
おすすめ度 4.0

健忘症

本日、6年前に開発したシステムに関する問合せがありました。現在もかかわっているような業務のシステムならシステム構造も似ているので、調査の勘所も思い出しやすいのですが、ちょっと特殊な業務システムということもあり、問合せ内容を調査するのに大変時間がかかってしまいました。単純に私が過去のことを忘れているせいもあるのですが、ドキュメントが悪い、コードが読みにくい、などなどいろいろな要因が重なって調査が大変でした。
そんななかで、非常に役にやったのが、JUnitによるテストコードとそのテスト用のテストデータでした。テストコードを追うことで、そのシステムが何をやろうとしているのかが明確になってきます。こうして、コードを追っていると、6年前の自分は、かなり複雑な関連のクラス構造を持つプログラミングを理解できていたなと思います。年々、コードがシンプルであること力を注いでいたのは、ある意味、もう複雑なコードを理解できない頭になりつつあるのではないかとも思ってしまいました。これは、いいことなのか?そうでないのか悩みどころですね。
いまさらですが、XUnitによるテスト重要性を改めて感じました。

複雑化するクラス

どうも設計がすっきり出来ません。一応動作しているのですが、保守性が良いとは思えないつくりで野作業で、ストレスがたまります。最初にきれいな設計が出来ると非常に見通しが良いのですが、どうもひとつのクラスに後付でさまざまな責務を詰め込んでしまっているような設計になってしまってます。部分的には、リファクタリングなどを行なっています(といってもメソッド名称変更、メソッド抽出、引数オブジェクトくらいなので、根本の構造におよぶようなリファクタリングまではできてません)。なかでも、気持ち悪いのは、プロパティ値の設定によるメソッドの振る舞いの変化とメソッドの引数による振る舞い制御に一貫性がなくオブジェクトの状態を把握するのが難しい作りになってます。これらの要因と、本来インスタンスを分けるべきものを、単一インスタンスで実行しているため、オブジェクトの状態遷移がおかしくなっているような気がします。コードサンプルなしには、何行ってるかわかりにくいですね。もっとシンプルな設計を!

やっぱり保守・運用って大切ですね

弊社は、開発中心の会社であり、つい、目新しい技術や、開発案件、要件分析などの上流工程に目が行きがちです。いま、お客様のところで運用の効率や改善などの相談を受けているのですが、開発が終盤になると開発中心の会社は、早く終わりにしようという態度がどうしても隠せません。弊社も実は開発案件ではついそのような仕事のやり方になってしまうことがあります。
システムというものは、作り上げることよりも、それをいかに有効に利用するか、とか現状のビジネスに対応してブラッシュアップし続けることが大切ですよね。以前のエントリ「ソフトウェア開発はガーデニング」にあるように庭師のようにシステムにかかわっていくことも重要ですね。それには、保守・運用の重要性が認知され、ビジネスがまわせるようになるといいのですが、世の中、現実にはまだまだのようです(その方向へ向ってはいるのですが・・・)。

新しい技術じゃないけど淡々とコーディングは進む

最近技術ネタがありませんが、そういう時って、淡々と仕事が進んでいることが多いです。技術ネタはトラブルや新しい発見があったときに備忘録としてメモしてるからです。最近は、これまでの枯れた技術の範囲内でプログラム作成していますからこれといったネタはありません。
そんななかで、我がチームのコード共同所有に関してをちょっと書いておきましょう。基本的にコード共同所有はいまいちですね。ユニットテストテスト自動化が実践されていないから仕方が無いのかもしれません。どうも、自分の主担当のコード以外には積極的にかかわろうとはしませんね。逆に、自分の担当範囲には責任感を強く持っているともいえます。しかし、バグが発生したときには必要以上に罪悪感を持ってしまうようです。もちろんバグはでないことが望ましいですけど、「バグを憎んで人を憎まず」の感覚も重要です。バグが発生したときにバグを組み込んだ人や直接的な原因の追究だけでおわりにしてしまい、なぜ、そのような問題が混入したのかを考えないことが多くなってしまいます。このような傾向が強いと、ペアプロ時等にも、ミスが見つかるとそれを恥ずかしがり隠すような人も現れてしまったりとか、レビュー指摘事項をその人の人格的問題の指摘のように思ってしまったりする状況になりやすいですね。
わたしなど、ペアにレビューされることを前提にゆるくコーディングしていると、それが非常に問題であるかのように指摘されたりします(私自身はバグが出てあたりまえみたいな感覚があるので気にしていないのですが、レビュー者は、もっとしっかりしろと思っているようです。仕事増やすなって感じですかね)。人の痛みを自分のことのように感じたり、人の良いアイディアを素直にほめられる関係が重要ですね。必要以上に自分を卑下したり、自信過剰にならないようにしたいものです。一人では完全でないことを補うためのチームですからね。
でも、私の場合は、チームにちょっと頼りすぎかな?(すぐ人に任せちゃうからな)出来る人ほど、チーム内ではつらいのかもしれませんね。

このシンプルな考え方がいいですね。複合キーが複雑さの要因であることは、現実を通していやというほど味わってきていますからね。

Railsのマインドセットには「テーブルをオブジェクトと同一構造にし、プライマリーキーにはinteger型のサロゲートキーを設定しておけば、かなり楽になる」というものがある。 Rails道を進めば、ライフ・イズ・イージー。 Rails道を進まないのであれば、別のものを使えばいい。

しかし、レガシーのホスト系システムの考え方をそのまま引き継いでいるようなシステムのDB構造は、複合キーのお化けみたいなのが良くあるよね。構造化されたコード体系がそのまま複合キー化されていたりとかね。
DHHのいいものはいいから俺について来いみたいな感じがいいね。

PragDaveの講演は、さらに深いものだった。彼は、私のようにダイナマイトを扱えない普通の人と多くの時間を過ごしてきた。データ管理グループが運営するデータベースからデータを引き出さなければならないとしたら、しかもそのデータベースが10年間ずっと複合キーで運用されてきたとしたら、ネオのようにクールなサングラスを身に着けることも、制約をダイナマイトで吹き飛ばすこともできないだろう。これに対するひとつの答えはこうだ。「組織を変「え」るか、組織を変「わ」るかだ」。だが、それができない人々は完全に見放されてしまうのだろうか、Rubyに。

ファウラーさん言うところの「組織を変「え」るか、組織を変「わ」るかだ」ですが、たしかによのなか二分化いるような気もしますね。赤いカプセルか青いカプセルか?私のようなおじさんでもあちらの世界へいけますでしょうか?

最近、オブラブのイベントに全然参加できていない私ですが、こういった動画アップされているとはいいですね。プレゼン資料のアップだけより現場の雰囲気が伝わりますね。また、同時にいろいろ検索してみると、海外のカンファレンスのセッション動画とかいろいろ探せば面白そうなものがありそうですね*1
上記リストのなかで思わず受けたのがこれ

契約書のタイトルに「〜請負」と書いた時点で「負けること請う」という言霊のせいでIT技術者が幸せになれないというのにはワラタ。

*1:これなんか面白そう[http://video.google.com/videoplay?docid=7830246530742207581:movie]