2012年4月29日日曜日

“技術的負債だらけのプロジェクトに「人員投入」して、多大なコストをかけ続けるでしょう。開発者が技術的負債が増えるのを軽減したり防ぐのに必要なスキルや習慣には投資しません。”

InfoQ: 2012年、アジャイルの雲行きは?予想を振り返る

これは、技術的負債がそこに存在するという事を認識できているかどうかって話だと思う。
受け入れる側、また、マネージャがそういう評価をすることができるか?という話。能力的にも政治的にも。
システムは作ってる時間よりも使ってる時間の方がはるかに長い。
『カットオーバー』は始まりであり、終わりではない。
技術的負債を返済するのは誰か?

Source: infoq.com

ドライアイでBABOK


右目の違和感みたいなのが気になっていて、やっと眼科に行ってきた。
ドライアイだそうだ。
今まで比較的健康だっただけに、ちょっと面倒だなって思ってしまう。
でもこの程度の事で済んでいるうちはラッキーだと思うことにする。
今更ながら、BABOK2の本を読んだりしている。 
ビジネスアナリストは、ステークホルダーがあらわした要望だけにとらわれず、新のニーズを引き出すことに責任を負う。
とある。
これは、個人としては結構前から意識していた事でした。そして、なかなか実践できていない事でもある。実際、ステークホルダーだけで要求を明確に正確に定義することは困難なことは少なくない。出来ないと思って最初から言わないことだってあるし、テクノロジーが新しい要求を導き出すことだってある。人間関係やその組織の空気感、その時の各担当者のモチベーションが大きく影響することだってある。
真のニーズ、『ホントはこうでしょ』ってのを引き出して、ちゃんと裏付けありで定義すること。これを強く意識したいと思う。
 ホントは今日一気に読み進めたかったんだけど、瞳を広げる目薬の影響で今日は目のダメージが…もう戻ったけどね。

2012年4月27日金曜日

ひと区切り


本日で、あるお仕事が終了。
プロジェクトは継続中なんだけど、私は離脱。
このお仕事では、なんとC言語のプログラムをちょっと書きました。
emacsでCを書くなんてのは随分とやってなかったけど、体が覚えてましたな。
ありがとうございました。

2012年4月20日金曜日

納得できそうでできない事


プロジェクトメンバーの平均的スキルに合わせた設計、開発手法を選択するという事。
まあ必然と言えば必然なんだけど、本当にそれでいいのかと思う。
エンジニアのスキルが不足していることによって、最良の選択ができないとした場合、その『最良』を選択できなかったことの不利益を被るのは最終的にユーザだ。
ちゃんと使える要求管理をするとか、モデル駆動とか、すべてが大きなハードルでもない。100歩譲って『今わからないからやらない』は受け入れるとしても、明日、半年後、一年後はわかるようになっていないとずっと同じことを繰り返すことになる。これは誰にとっても不幸なことだ。
プロジェクトはエンジニアの技術追求の場ではないので、妥協チックに折り合いをつけることはたくさんあって当然だと思う。
ただ、その時に、これが現時点のベストだと納得しながらも、ほんのりと悔しさみたいなモノを感じる、そういうマインドをマネージャもエンジニアも持ったらいいと思う。