■

システム開発の方法。
傾向と対策に1つの結論を持ってからというもの、
世間とのズレを日々感じるようになったことに気が付いた。

無知からでる行動の選択肢は、知識を得たときに終わるはず。
しかして現実はなかなかそうはいかない。
知識を得てなお、それが有効であるかどうかを判断できる知恵がない。

ってことが多いな〜としみじみ感じる。

要求定義にしろ、その後のスケジューリングにしろ、
テストや納品、その後の運用保守に至るまで。
範囲が広いので話題をプログラマの作業管理に絞ってみる。

プログラマのやるべきこと、為せることに興味が無い世の多くの「ＳＥ」は
常に管理の仕方を間違う。
ＳＥにとってプログラマの作業はブラックボックスかもしれないが、
それならそれで管理のしかたというものがある。
しかして出来ている方々はごく少数だ。

以下の状況をもってして、その次の答えを導き出せるのだろうか。
　・プログラマの作業をわかってない
　・仕様書に変更はないはずと思う
　・スケジュールを作ったら見直しなどしない

　　　→『このプロジェクトを成功に導こう』

わからないことへの対策をせず、
予期せぬ出来事への対応策も打ち出さず、
願望の結晶にすがりつくだけ。
イチかバチかの賭けですらない。
人事を尽して天命を待っているわけでもない。

これでプロジェクトがうまくいくとどうして信じることができるのだ？

それでも状況を見ずに方法論ばかりに躍起になっている。
「本」にすがるだけで現状が変わるのなら世話はない。
心底そう思う。

そんなプログラマの管理はどうやって行われているかと言うと、
画面や機能あたりの工数を棒で引っ張った表と、
「(,,ﾟДﾟ)＜進捗は〜」「(;´Д｀)＜60%くらいです」って会話で終わる進捗管理は多い。
1つ言える事がある。
無駄っ
よくわからないことに対してよく信用できると思う。
5日で終わると言われたものが3日経っても4日経っても90%といわれたら怪しいと思え。
思ったところで何も出来ないのなら、やるだけ無駄。何の解決もできないのだから。

プログラマに言わせるだけで実際には違うなら他の手段を取ればいい。
会議に時間を取りすぎるなら短時間で済む方法を考えたらいい。
プログラマは放置しても関わりすぎても生産性に差が出る生き物であることが理解できなくても対処はできる。
何が問題で何が原因なのか。
考えもせずに解決すると思うのが大きな間違いだ。

かつてを思い、今を見ても思うことがある。
いわゆるそんな「ＳＥ」は仕事をしていない。
進捗の現状把握のための手間を惜しみ、
ルーチンワークの如く場所だけ設けて聞いたふりだけとか、
今ある問題に対応することから出来る限り逃げ、
願望スケジュールの遵守というプログラム実装者への余計な手間を押し付けて、
失敗したら実装者のせいにする。

でもそれが世の多くを占めている。
仕組みの上ではそんなのがまかり通るようになっている。
仕組みを作るのは多くの無知どもだ。
数少ないそうでない人々が作り上げたカタチが、
世の中のシステム開発成功率の底上げをしているのであり、
そうでないのはひたすら失敗し続けているのだ。

そうなる必然ってのが見えたら、そう思えた。