「 2010年02月 」一覧

積ん読

積ん読状態の本のみなさん。

中には読んだものもあるけど、これを片付けないと次に読みたい本が買えないな。

  (by findup)


イベントドリブンなマネージャにならないように

イベントドリブン=何か起きてからそれに対応する、というのはソフトウェアでは多いけどマネージメントとしては避けたいことの一つだと思う。

マネージメントで何かイベントが発生(発覚)したタイミングは、たいてい対応するにはタイミングが遅くなっていることがほとんど、つまり後手に回っているのだ。

  • 実は進捗が遅れてマイルストーンに成果物が間に合わない
  • 見積もり時に想定してなかった重大な項目があった
  • 客先から仕様追加が出てきた

などなど。

何か問題が起きてから対応をすればいいや、と思っているマネージャが率いているプロジェクトでこういう問題が発生しやすいように思う。

リスクの洗い出しと管理がきちんとしているなら、こういう後手に回るようなことはなく、むしろポーリングするかのように、新しいリスクの芽が出ていないかを常に探して潰していくというマネージメントをするのが本来あるべき姿だろう。

本当はマネージャでなくても、チームリーダでもSE/PGでも、自分とチームに関わりそうなリスクに敏感であり、かつそれをできるだけ事前に潰しておくようなチームワークがトラブルを避けられるのでマネージャだけにリスク管理を求めないように。


プロジェクトメンバー送別会

今日は名古屋から長期出張で来ていたプロジェクトメンバー10名超の送別会。

一部のメンバーは名古屋に作業を持ち帰ることになっているけど、去年の7月末から約7ヶ月間、一緒に仕事してきたのでこれで終わりなんだな、という実感はまだ無い。みんな確執なく仕事もできてたのでなおさら。

プロジェクト自体はまだまだ佳境で気が抜けない状態なので、これから九州側のメンバーと名古屋に帰ったメンバーと遠隔地での開発となるのでコミュニケーションの密度が下がりすぎないように注意しないと。

今まで遠隔地の開発はいつもコミュニケーション不足で失敗するから。でもチャットツールなどコミュニケーションツールが使えず、制約が多い会社だから工夫が必要だ。

私のいるチームは九州と名古屋と混成だったのだけど、人数も含めてチームとしてよくまとまっていたほうだと思う。少数で回してしたので多少負荷は高かったかもしれないけどね…。

機会があればこっちから向こうへ出張とかあると良いかも。


送別会とUターン組の失意

今月で退職する人の送別会。

中途入社で2年くらい在籍だったのかな、おそらくこの会社の体育会系なところと、仕事のハードルが合わなかったのだろうと思う。

ふと思ったが、少なくとも自分の周りではある程度の年齢(30歳くらい)以上の中途入社組は定着率が悪いように思う。ここ10年の肌感覚だけど。

うちの会社が若い人が多いというのもあるし、若くて体力ある人が残業しまくってプロジェクトを回しているという側面や、条件の悪いプロジェクトを取ってくることも過去多かったりして、30代以上や家庭持ちの人がその仕事のサイクルに入ると体力的、精神的に辛いかもしれない。

若いうちから社風として「こんなものだ」と慣らされた人は、残ってる感じがするな。私も含めて。

東京などからのUターンだったりすると、東京での仕事に少し疲れて戻ってきたという人もいる。でもここも仕事の内容から言えば決して楽では無いので、その目論見が外れてしまったと思う人も多い感じがするし、実際に失意のうちに辞めていく人も目立つような気もする。そういえば、今日の主役の彼もUターン組だった。

彼もしばらく休養したあと、この業界に戻ってくるかどうかは分からないと言っていたので、人生として彼にもっと合う職業と職場が見つかると良いな、と願う。


TDDは品質担保のためでは無い?

TDD談義への反応に対する雑感 – 千里霧中

自分はTDDすらやったことの無い、ある意味時代遅れの開発しかやったことはないのだけど、先のエントリを読むとTDDのテストと単体テストは別物という解釈らしい。

それを聞いたとき、「?」と思ったのが本音だ。テストコードなのに品質とは関係ないのだろうか?と。

TDDに対する私なりの解釈

私はある関数のコードを書くときにJavadocやDoxygenで関数ヘッダをある程度詳しく文章で書く。

そして関数内にコメントの形式でどんなコード(処理)を実装すべきかを書いていく。イメージとしては以下のような感じ。

private List<nnnn> func(int id) {
    // xxオブジェクトのインスタンス取得
    // XXXDAO経由でidに関連するデータを取得
    // 取得したデータからxxxとxxxの条件に合致するものを抽出しリストにする
    // リストを生成し返す
}

あとは上記のコメントを実際のコードに置き換えて行けばよい。また自分以外のメンバーに作ってもらうときもこの形式で渡すこともある。

ただこの方式だと、単に文章をコードに置き換えただけでそのコードが正しく動作するものかどうかを検証する手段がない。

なので、上記のようなコメントを先に書く代わりにTDDのテストコードを書いて、その通りに関数本体側を実装する。そうすると、

  • この館数ではどういうコード(処理)を書くべきかの情報が残せる(コメントで残すのと同じ)
  • 実装したコードが意図した動作をしているか”実行して”評価することができる

という2点が一緒に満たせるというのがTDDというものなのかな、と。

実際に境界値評価だったり網羅性の評価を行う”単体テスト”の場合は、もっとしっかりとテストコードを書く必要があるのだと思うし、その単体テストコードのベースがTDDのテストコードであることは問題無いということだろうか。

TDDと単体テストコードは、誤解を恐れずに言えば前者が”コーディングの補助”、後者が”品質の担保”ということになるのだろうか。

感想

TDDのテストコードが品質担保(これだけでは単体テストとしては不十分で使えない)とすると、開発工数の見積もりにTDDのコーディング工数を入れるのは、TDDに理解の無いSIerなどでよくある開発現場だと説明するのが難しいかもしれないね。

何も言わずに実装工数見積もりの中に含めてしまうか、単体テストコードへ昇華させることを視野に説明して見積もりに乗せるかということになるだろうか。

個人的には、TDDだけならやる意味は少し薄いのかなという気持ちはある。TDDのテストコードを単体テストコードへ昇華させるという前提でやるなら、取り組む価値はあるかと思っている。


短い開発期間とメンバーへのプレッシャー

組み込みにしても業務系、Web系にしても納期・開発期間はどんどん短くなっていると思う。

組み込みの場合はハードも無いときに設計を始め、開発用ライブラリの提供が遅れ、動作確認と試験のためのハードが遅れ、しかし開始から4ヶ月後のマイルストーンでは全機能が動作し一定の品質であること、なんて要件の案件はよくある。さらに開発費もそれほどかけられない。

納期短縮の流れに対しての特効薬はなかなか無いのが現状だとは思うけど、プロジェクトの進め方や人のアサインなどは昔から変えず、単に開発メンバーに工数や作業面で強いプレッシャーをかけ続けて作業させるやり方を取ったりする現場が多いのではないか。

少しでも見積もり時間と差異が出たら、マネージャからとても厳しく理由などを問われるとか、突発的な割り込み作業まで考慮して月間の工数見積もりをしないといけないとか。何かあるとマネージャに長々とお伺いを立てたり、謝ったりしないといけないプロジェクト。

自分が行う作業の見積もりは重要だし工数管理はきちんとやるほうが良いに決まっているけど、厳しすぎると現場の息が詰まらないだろうか。

時間=コストだから無駄にして良いというわけでは無いが、明らかに多い仕事を積んでおきながら規定の工数でやれなかったから、お前の作業効率は悪いだのという言われ方をするプロジェクトだと、たぶんみんな殺伐としてくるように思う。

工数は確かに抑えられるかもしれないけど、サビ残が発生しやすくなるだろうし。逆に生産性落ちたりしないのだろうかね…。

景気が悪くて仕事が少ない、取れても予算が少ないという状況だとこういう締め付け型のプロジェクト管理が横行していそうだ。もっと作業のスコープを調整するとか、人のアサインを変えてみるとか、メンバーに負荷をかける前にやれることはあるんじゃなかろうか。


仕事で心が折れ気味

いろいろあって、ここ最近は仕事に対して心が折れている感じがする。

上手く進まないし、プロジェクトの外野からは厳しい言葉を浴びせられるし、来月以降の仕事の進め方も今ひとつ決まっていない。

4月に年度が変わると年間労働制限時間もリセットされるので、また徹夜や休出で一気に片付けないといけない事が山積みで確定っぽいという暗い情報だけでもお腹いっぱいなのになぁ。

なんだろうな、頑張ってるつもりなのにこんな状況なのは何故かってのは、まぁ実際は私の認識が甘いだけなのかもしれないし、頑張ってると自分で思い込んでるだけで実は何も成果を出せてないのかもしれないけど、どうもこの先に悪い話ばかりが見えていると落ち込んでしまう。

今のプロジェクト自体も外野からはボロボロに言われてるようだし、プロジェクトの中の人間にとってはなんか辛いね。今の気持ちのまま次の案件も頑張りましょうって気分じゃないなぁ。会社が悪い誰が悪いって言っても仕方ないけど、落ち込んだ気分をどう変えていこうかな。


買った本「小さなチーム、大きな仕事―37シグナルズ成功の法則」など

今日はジュンク堂で3冊購入。

文字コードは時々意識しないといけないシチュエーションが来るし、昔の仕事と比べてUnicodeを扱う場面が増えたので、きちんと囓っておく。

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)
プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

Amazonで詳しく見る by G-Tools

37signalsの本。ハヤカワがこの手の本の翻訳をするのって珍しいんじゃないだろうか。

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice 11)
小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice 11) 黒沢 健二

Amazonで詳しく見る by G-Tools

SEの教科書 【完全版】 (技評SE選書)
SEの教科書 【完全版】 (技評SE選書)

Amazonで詳しく見る by G-Tools


20年くらい前に見かけてたタイプの自転車

福岡市役所の駐輪場にて。

懐かしいタイプの自転車が。

  (by findup)

自分が子どものころ、小学校の高学年だったか中学生だったか、こんなの乗ってた。

シフターの位置がフレームについてるパターンね。あとリアサイドに折りたたみのカゴをつけて、ハンドルはストレートに変えてもらった気がするけど、大体こんな感じの自転車だった。

中学か高校からは一般車に乗るようになったけど、20年くらい前はときどき見かけてたタイプ。


ロディアメモを切り取ったあとの保存に便利そうな、キングジムの小型ポケットファイル

JETSTREAMボールペンの替え芯を買いにインキューブをさまよいながら、そういえばロディアの切り取ったメモを入れられるものは無いかと思って探してみたら良さそうなのを発見。

キングジムのJacket Holder(No.744)という商品。

  (by findup)

RHODIAのNo.11を入れると以下のような感じに。

  (by findup)

このケースは写真のL版サイズなので、おそらくロディアならNo.12くらいまでは入ると思う。

私のロディアの使い方は、カバンにはNo.11(カバー付き)とNo.16を入れていてちょっとしたメモ用にはNo.11を使っているのだけど、切り取ってもすぐに捨てられない内容を書いていることもあるのでちょっとした保管用の入れ物が欲しかったので、しばらく使ってみるつもり。


スポンサーリンク