読者です 読者をやめる 読者になる 読者になる

世の中に良いやり方あると教えてから「標準かサンプルちょうだい」という人はそれを使えない

「聞いてくださいよ」
「どうしたの。技術支援しているプロジェクトで普通なら使っていそうな開発のスタンダードのようなものをまったく使っていなくて、良いやり方ありますよ、って言ったんですよ。そうしたら、標準かサンプル欲しいっていうから出したんですよ」
「いいことしたじゃん」
「それがそうじゃないんですよ。チラッとだけ見て、うちでは使えないだって。はぁっ、なに言っているんだ、ですよ」
「相当ご立腹だねぇ」
「参考にしたいからっていうから、時間を割いて紹介したのに」
「で、そのプロジェクトはどうなの」
「全然ダメです。炎上しますよ。すぐに」
「なんで」
「要件にあった開発手法になっていないですから」
「そうか…コーヒー飲みに行こうか」


自分たちのプロジェクトに適合するシステム開発手法や開発ツールを選定できない時点でアレですが、世の中にある標準や良いやり方(=プラクティス)をそのまま適用できると思っている時点で話にならないですよね。


世の中に出回っているものは、誰かが経験したことのうち、他人に教えられる程度まで情報を薄めたものか、デファクトスタンダードのように共通概念だけになったものが多いのですから。


そうしたものは、特性を持っているプロジェクトになにも加工もしないで適用できるわけがないのです。かならず、テーラリングをしなければならないのです。


つまり、自分たちで使う道具は自分たちに合うように修正して使ってみて初めて使えるかどうかがわかるんですよ。それを使っても、テーラリングもしないで自分のプロジェクトに適合するかどうかを見極めることができるなんて、とても素晴らしい見識眼をお持ちだと思います(褒めてない)。


そもそも事例なんて自分のプロジェクトに持ってきただけでは100%適合しないんですよ。プロジェクトは唯一無二なんですから。違うものに他所から持ってきてもフィットするわけがない。


だから、自分のプロジェクトという現場で合わせないといけない。そういった手間をかけないから前のプロジェクトのように設計やプログラミングの工程プロセスで品質を作り込むことをしないし、試験も作ったコードに合わせて試験項目を書くから試験結果はオーケーでも低レベルのバグが総合試験やUATででるわけです。全くもって進歩ゼロです。


プロジェクトのスケジュールが短期でそんなことやっている時間なんてないよ、といったらそれこそ嘘ですよ。また、バグ潰しと品質のキャッチアップでコストオーバーランさせるのかって詰めるしかない…。