2011年3月30日水曜日

生産性の前提

今日、改めて、なぜ先日リリースしたシステムの生産性が悪かったのか、打ち合わせがあった。

お偉方はソースコードのSTEP数でしか判断できないので止むを得ないが、STEP数に含めるものの前提が違うのに、ある指標を使って生産性を測るのは勘弁して欲しい。
今回は、一部ソースコードを自動生成した。

今回のプロジェクトに限って、その分を規模として認めてもらえない。
自動生成すればする程、生産性が下がることになる。そんな馬鹿な話があるかと思ってしまう。

過去の指標を参考にするのは構わないが、前提が違うものを参考にされてはたまったもんじゃない。

クラウド時代は、システムで実現できることを基準とすべきで、ソースコードのSTEP数で、判断すべきでない。そもそも、生産性を計測すること自体、意味の無いことになっているのではないか。

プロダクトアウトの考え方で、システムを作るのはもう終わりにしたい。

2011年3月20日日曜日

チームでの振り返り結果

今月初めに納品したプロジェクトチームの振り返り。自分の考えを申し上げたが、情けない回答が返ってきた。

何が情けなかったか。

 

一点目は、「お客さまの言われたとおりのシステムを作っていればよい」ということを言われたことだ。確かに、お客さまの要望は大事だ。しかし、お客さまにも予算があり、何から何までお客さまのご要望に応えていたらビジネスとして成り立たない。

今回、自分がどうしても納得のいかない余分な機能があった。開発規模は少ないが、難易度は高い。試験パターンが複雑で工数が膨らむので、自組織としてはコストがかかる。お客さまの業務に必ずしも必要だとは思えない。しかも、この機能を開発することで品質が悪くなると確信できる。保守時にシステムを改変したい場合、余分なコストがかかる。

本当に、これがお客さまのためになるのか...

 

また、「見積もりに制約条件をつけたらどうか」という問いに対して、上司は「競合他社に取られる」と言う。確かに、競合他社を意識する必要はある。それ以上に、お客さまのシステムを知っている自社のアドバンテージを意識したい。私がお客さまの立場だったら、「何でもできます」という姿勢は、かえって何も考えていないのではないかと疑う。具体的な言葉で説明できないエンジニアでないと信用できない。

 

品質を上げるために「このドキュメントも必要だよね。」とか「このタスクも必要だよね。」とか、管理するために「この項目も必要だよね。」など、様々な意見が飛び交った。そりゃ、お金と時間が沢山あれば、先ほど書いたことも全部できるさ。でも、限られた時間で本当に、こんなことまでできるの?と言いたくなる。所詮、他人ごとなのだと思った。

 

もちろん、周りの意見を聞いて改善せきる点も多々あった。

ただ、コスト削減が中心で、新たに価値を提供するという観点では、何の改善もみられなかった。お客さまの業務改善まで踏み込まなくてよい、あるいは、そこまで踏み込む必要はないという上司の言葉に対し、非常に悔しく思った。これでは、永遠にお客さまの奴隷だ。だから悔しかった。こんな会社、組織のスタンスでお客さまと付き合いたくない。

もちろん、お客さまの業務改善まで踏み込むには、お客さまから信頼を得ていることが前提だ。今回は、私にとって初めてのお客さまであったため、まだ、業務改革案を出しても受け容れられないだろう。だが、お客さまに断られても提案はする。なぜ、この方法をとらないのですか?と。納得できる理由が無ければ、他に理由があるはずだ。

 

今回は、初めてお客さまのための自分の作品とよべるアーキテクチャを作成した。今どき、0ベースでスクラッチ開発するケースは少ない。フレームワークの選定から共通部分のアーキテクチャ、メンバーへの教育...さまざまなことを経験させていただいた。お客さまからの厳しい要求の中、納品できたことは、自分にとって次に繋がると確信が持てる。

 

次こそは、提案のチャンスをいただきたい。社内だろうが、社外だろうがどちらでもいい。自分を必要としてくれる人がいるなら、オファーをいただけるなら、ビジネスのゴールをヒアリングして、企画、アーキテクチャ策定段階から参画したい。

 

2011年3月12日土曜日

逆に、災害情報だけになってしまうtwitter

今回、自分のtwitterのタイムラインが災害の情報でほとんど埋まってしまい、他に必要な情報が得られないというちょっとツライ状況になっている人も多いのではないか。

今回、首都圏に住んでいる人で普段と同じように生活できている人も多い。もちろんそれは幸せなことであり感謝すべきことであるが、人それぞれ知りたいことがあるはずだ。

あらかじめ想像できたことだが、実際に体験してみると、自分が伝えたいことが地震関係のtweetでかき消されていうく感じがする。

だから、地震の話題が収まるまでtwitterを使用を控えます。使用したとしても、mentionくらいかなぁ。

 

今日も、仕事している私...いや、こんな時こそ、仕事が捗るからいい。そう思うようにしよう。

災害時のSocial Mediaの威力

昨日から、日本のインターネットのインフラは、改めて凄いと思った。 電話は通じなくても、ネットは通じる。 みな、携帯電話から情報を取得していた。 特に驚いたのが、twitterの情報伝播の速さだ。 災害時は、twitterをやっている人が、口頭で情報を伝える。twitterをやっていない人に驚く程伝わる。

日本人が冷静に行動できた理由の一つに、Social Mediaでうまく情報の取捨選択ができたことが挙げられるのではないか。

2011年3月7日月曜日

やりたいこと

プロジェクトが終わって、改めて自分がやりたいことを再確認した。

自分がやりたいことは、世の中に受け入れられるサービスを創りたい。
お客さまの要望を分析して自分で仕組みを考えて、新しいサービスを創りたい。
お客さまに喜んでいただくというより、無意識に当たり前のように使っていただけるものにしたい。

もう少し具体的に落とし込むと、お客さまの求めているモノを把握し、ソフトなりシステムに落とし込みたい。

今回のプロジェクトに参画して改めてそう思った。
また、現場のメンバーが新しい知恵を出し合って最高のモノを作りたいとも思った。

ただ、仕事をする以上、納期とコストという壁は、避けられない。
ただ、人月的な生活が送れなくなる状態だけは避けなければならない。

生産性とか人月商売、価格で勝負をする前に、価値で勝負したい。

恐らく、今週はプロジェクトの振り返りがあるだろう。
今の自分の軸と照らし合わせて、将来に向けて行動する。
振り返りが自分のターニングポイントだ。

2011年3月6日日曜日

プロジェクトをひと通り終えて

昨日、お客さまに納品した。ある意味、一区切りついた。
これから、お客さまが受け入れ試験を行うので正直油断はできないが、振り返りする上ではいいタイミングではないかと思った。

以下、気持ちを徒然と書いています。テクニカルな情報などは記載していませんので悪しからず。




今回のプロジェクトで自分の心に残った悔しい言葉がある。「生産性が悪い」という言葉だ。
プロダクトコードの規模の割には人手が掛かりすぎているという。
確かに数値だけ見れば、指摘の通り。
今回は、フレームワークや共通化を図って規模を少なくしてくださいというお客さまの要望があった。
共通化や抽象化をすることで、プログラムの難易度が上がる。
しかも、フレームワークを使用する、ソースコードを自動化するなどして規模を抑えた。
しかし、上司は自動化した部分も含めて規模として認めてくれなかった。
規模を減らすために努力した結果が「生産性が悪い」という言葉につながった。
非常に残念で悔しい。

規模を減らした結果、試験の工数が減るかどうかといったら何も工夫しなければ試験の工数は減らない。むしろ、単位規模あたりの試験工数は増える。
比較対象が、過去の非効率なたくさんのコードであるならなおさらだ。
徒競走する際に100メートル走と300メートル走でかかる時間が同じかどうか比較しているようなものだ。

規模が減ることに比例して工数を削減できるとは限らない。
開発現場を直視している人であれば理解してもらえるのだが、単純に集計した数字でしか物事を判断できないようでは、同じように社内で開発している人にとっては、先が思いやられる。
ただ、上から規模ではなく、工数を減らすための工夫を求められているのも確かだ。
工数を減らすために何をすべきか、これは自分にとっての新たな課題だ。

ただし、自分にとってたくさんの成果があったことも確かである。

・ リスクの高い新技術、アーキテクチャを採用したこと
その際にさまざまな数値を記録することができた。
新技術を導入する場合、何をどこまでする必要があるか分かった。

一番の成果は、自分にとってこのしんどいプロジェクトをやり遂げたこと。
そして、これからこの成果を元にさまざまなエンジニアの方と情報交換ができるのではないかと考えている。

これから、自分の策定したアーキテクチャを使用したプロジェクトの第二弾が始まる。
それは、今回リリースしたシステムとは別のプロジェクトだ。
ゴールデンウィークまでまた、家に帰らない日々が続く...