- 「これならずいぶん楽になると思うよ。いいね。」
- 「業務を知ってれば、すぐに分るからマニュアルもあんまりいらないんじゃない？」
今日、今のプロジェクトで作っているシステムを実際にユーザーに触ってもらった。実は今日で4回目。ただ、今までと違うのは、システム担当のユーザーが、ついこの前までホントにエンドユーザーだった人(異動してきたらしい)を連れてきたこと。上記は、その人から出てきた言葉でした(かなり脳内変換してるかもしれないけど、ともかく喜んでもらえた)。思わず心の中でガッツポーズですよ。
つくりやすさより、つかいやすさ
今回のプロジェクトでは「つくりやすさより、つかいやすさ」（どこかのブログでみた言葉。多分Seasar界隈。）をとても意識した。これまで、そのユーザー企業でうちの会社が開発してきたシステムと比べると、ちょっとやりすぎか？と思うくらい。その分、プロジェクトメンバーは大変だっただろうなぁ。でも、それがどれだけできるかが、そのプロジェクトの価値であり、他者(他社)に対する競争力でもあるはず。目指す価値はあると思うし、これからも目指します。
一方で、プロジェクトの内部にも目を向けなければ。今回のユーザーの要求は、期間・コストそしてプロジェクトの能力と対比して、妥当な量だったのか？プロジェクトの目標は、本当にプロジェクトの目標だったのか(メンバーレベルまでちゃんと動機付けできてたのか)？「作ってから直す」方式になってしまった作業品質の低さと、それに伴う作業効率の低下。ふりかえると(まだ終わってないけど）、失敗したと思うことの方が多い。まぁ、目指す理想があるからこそ、見えてくる問題だと信じたいですが。
というわけで
再度、ここで自分に言い聞かせる。私が(願わくば我々が)目指すのは次の通り。
- 決められた期間とコストの制約の元、ユーザーのビジネスに価値をもたらすソフトウェアを開発すること。その価値は、大きければ大きいほどよい。それがそのまま、我々の価値だから。
- QoEL(いい言葉だ。平鍋さんに感謝)。プロジェクトメンバーがエンジニアとして充実した時間を（公私共に）過ごすこと。
ああ、一応これもいれておきますよ。
- (あんまり好きな会社じゃないけど :P)自分の所属する組織にプロジェクト活動を通じて利益をもたらすこと。
まだ終わったわけじゃないし、テスト工程で取り除かなきゃいけない欠陥もまだある。気を引き締めていきますかね。
