チームでの振り返り結果

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

何が情けなかったか。

 

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

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

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

 

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

 

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

 

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

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

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

 

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

 

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