2012年07月03日

開発方式、処理方式、開発標準という夢物語

日本のSIerは過去、もしくは弊社では未だに現在進行形で、開発方式、処理方式、開発標準を考えるべきだということが叫ばれています。それがないから開発に失敗すると。
実際のところ、そんなものは弊社では立てられないと心のなかで分かっていながらも、私も「そうだ、そうだ」と叫んでいたこともありました。

そして、今現在進められている案件でもまだ、開発方式、処理方式、開発標準をどうするかだけでなく、各案件で開発方式、処理方式、開発標準が策定されている始末です。つまり、確定していないし、現在進行形でそれぞれの人達がそれぞれ開発方式、処理方式、開発標準を作っているのです。

が、はっきり言えば、日本のSIerが叫ぶ開発方式、処理方式、開発標準(以下、まとめて方式と呼びます)というものはいずれも、中身が無い空虚なものです。これができれば、開発が少しはうまくいく、効率化、省力化できるという夢が語られたりもしましたが、絶対にそんなことはありません。最近はそんな風に考え方が変わってきました。

これら方式とは誤解を恐れずに言えば、究極的に抽象化された、たった一つしか存在しない銀の弾でなければ作る意味はないでしょう。
でも、さすがに作れないため、現在では各プロジェクトごとになんとか銀の弾を作ろうとしています。それすらも結局作れずじまいです。
たったひとつ、全てを抽象化した完全な方式は存在するのでしょうが、存在しても作ることができないでしょう。できて規約までです。

規約はとても有効に働くでしょう。規約は反転すればチェックシートになります。チェックシートはそれを満たせば、成果物が規約の範疇を保証する強力な武器になり、チェックシートに記載された事柄が満たされなければ、突き返すことができる強力な防具にもなります。
そう、開発の現場では、規約とチェックシート、マニュアルやガイドさえあれば、実は十分開発を行うことができます。あえて事前に方式をたてる工数を作っても無意味なことがほとんどです。

それはなぜか。

その理由は案外単純です。方式とはある種現状では中途半端に抽象化されたレベルにしかならないため、実際にしようが固まれば固まるほど、方式の範囲を超えたどうしようも無い例外が発生するためです。結局、最初に立てた方式はなんとなく実現できそうでも、何時の間に苦しまぎれ例外が多くなります。これが後々の保守性を非常に低下させます。

例外ばかりで実装されたシステムほど、どう見たらいいのかわかりません。どう修正したらいいのかもわかりにくいのです。
であれば、中途半端な方式を立てるぐらいなら、まだ何もないほうが工数は無駄になりません。
ただし、もちろん事前に完全に抽象化された方式が立てられ、例外が出ない、もしくは方式に吸収可能なレベルを実現できるのであれば、あったほうがいいでしょうが、ここではそこまでのレベルのものはそもそも作ることができないという立場に立っています。


本当に使える方式を立てるにはどうしたらいいのか。

それは、全ての開発工程を今まで苦労も含めて経験し、そして技術も業務も管理も保守も運用も全て熟知した人間だけが、それらを俯瞰してあるべき姿、つまりべき論を導き出すことができます。

ですが、今現状、弊社で方式を立てようとしている方々は、いかに今わかっている仕様だけで自分の考えている方法論で作るかしか頭にありません。
そうではなく、本当に使う側に立った視点で見ていないのだから、作れないというのが私の意見です。
まずは、本当に各プロジェクトでどういうことがあったのか、分析するところから始め、上から目線をやめ、いろいろな工程の担当者から話を聞き、コミュニケーションを受け、真摯に耳を傾けなければ、真の方式はいつまでも夢物語でしょう。

では、具体的にどうすべきかについては、また順次記載して行きたいと思います。まだ、まとめきれていないので、ちょっと時間がかかりそうですが。
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/56794963
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック