現場に戻って１ヵ月

現場に戻って１ヵ月が過ぎました。この１ヶ月間で、体重が３キロ減るほどの激務です。朝一でコンビニでサンドイッチを食べて、日が回ってから家に帰ってビールを飲んで１日が終わる日なんてザラです。絶賛、残業ダイエット中です。残業代は出ませんが。
さて、今回のシステム、詳細を書くことはできませんが、アーキテクチャ面で特徴的なポイントが多数あります。問題は、その特徴に対するアウトプットがないということです。
SIerの多くは、社内標準というモノを持っていると思います。最近、その社内標準に沿って開発を進めたものの、トラブっている案件を良く見かけます。トラブル案件の言い訳は、新しい技術か、新しい業務か、新しい顧客か、の３点を良く見かけますが、正直、素人じゃないんだから、その程度、乗りきれよ、と思います。なぜ乗りきれないかと言うと、社内標準というツールに頼りすぎてしまっていて、開発プロセスを深く考えていないからです。（ここは言い切ります。）
どのタイミングで何を考え（設計）、何を作って（製造）、何を確認（試験）するのか、システムの特徴に合わせて考えないといけないのに、それが考えられていないのではないか、少なくとも、検討が浅いのではないかと思ってしまいます。これは、単純にＷＥＢシステムの基本形が出来上がっており、社内標準として定義されてしまっていることもあって、開発プロセスを考えることを知らない人が増えてきたのかなと思ってしまいます。
たとえば、前のシステムでは、正常系２割、異常系（準正常系含む）が８割というシステムでした。なので、基本設計段階から、社内標準をだいぶ無視して、異常系や運用を意識した設計が出来るよう、成果物定義（工程定義含む）を行っていました。一番最初に作った正規のドキュメントは、異常系の処理設計規約だったりします。設計書や検討資料も、８割以上が異常系について検討／設計するものです。そのために、異常系を検討するための設計書フォーマットも新たに作り出したほどです。一部社内標準に準じたドキュメントも作りましが、非常にメンテナンスが面倒なドキュメントを作ってしまい、後悔しています。
正常系は誰が考えても作れると思ったので、こんな形で、異常系をひたすら考え抜きました。
じゃあ、開発プロセスを作る目的は何かと考えると、ある一面では、どうトラブらずに品質を積み上げていけるようにするかを考えていくことなのかなと考えています。なので、トラブル案件を見ると、開発プロセスに問題があるのではと穿って見てしまいます。
今回の案件も、もう少しマシな開発プロセスが定義され、それに沿って開発されていれば、一人で２人月も働くダイエットをしなくて済んだんじゃないかなと。
もう少し、開発プロセスについて、真面目に考えようよという感じの愚痴です。（なお、私は、アジャイル開発は、開発プロセスについて思考停止させているようにしか思えないので、大嫌いです。）