■

IT部門に求められる「標準化」と「開発現場の統制」
http://itpro.nikkeibp.co.jp/as/nri4/index.html

通常の場合、要件定義や基本設計はユーザ企業のIT部門が主導で推進、
その後に続く詳細設計や開発、単体テストを開発ベンダーが担当、
さらにその後の連結テストや結合テスト、運用をIT部門が担当することになる。

これはさておき。

ここで大きなリスクが生じるのが、詳細設計から開発・単体テストの部分である。

(..´Д｀)＜ん？

この部分は開発プロセス全体の中でも最も多くの工数が費やされる部分であり、
この部分を外部に丸投げすることで、工数が肥大化したり、十分な品質が保たれないという危険性がある。

(..´Д｀)＜あなたも「私の要求定義にミスはない」といいたい人ですか。
　　　　　　要求をキャッチアップできないのは外注のせいと言う類のひとですか。

実物も見ずに基本設計まで「完了」といえるのか？
使用する技術検証も行わない段階での方針にミスは紛れないのか？
それらは全て「詳細設計」のせいだとでもいうのか？
開発コストの増大の要因は、丸投げすることにあるのではない。
自分の行動にはまったくミスが入る余地はないと思い込む
要求定義者、基本設計者がいることだ。
そんなやつらの脳みそに変化を抱擁することを刻みたい。

自動車製造の現場では、複数車種の生産に耐えられる汎用的なラインを整備し、
小さなパーツからエンジン、ミッション、アンダーボディに至るまで、
できる限りの共通化を行った上で、
作業手順の平準化によって現場技術者のスキルに左右されない環境を整えると共に、
作業平準化をサポートする徹底した自動化を行っている。
これによって開発・生産のコストを抑えながら、一定の品質レベルを維持しているだ。
システム開発の現場でも、これと同じことを行うべきなのはいうまでもない

自動車製造はそれができる。できた。目に見えることだし。
ソフトウェア開発の場合は、現場の技術者のスキルに頼らずに済むことなどない。
まず目に見えないことを想像する難しさをみんなが認識することからはじめなきゃいけなさそう。

しかし多くのシステム開発現場では、このようなアプローチは成功していない。
それは何故か。
最大の理由は自動車製造に比べ、ソフトウェアの製造の自由度が高いからである。

(　Д )　ﾟ　ﾟ
そうきたか。

自動車製造に比べて、パーツ数が圧倒的に多いとか、
自動車製造に比べて、製造が難しいとかそういうことにはならないのかね。

自動車製造ではすでに作成されたパーツを、組み立て段階で修正することは考えられない。
これに対してソフトウェア製造では、ソフトウェア部品を組み立てる際に、
その内部コードを修正してしまう、といったことが日常茶飯事のように行われている。

前述の理由をもとにすれば、これらは必然として在る事象でしょが。
パーツや部品はまだ完成していないのです。
必要なパーツがまだ製造されていないのです。

これによってコードとドキュメントの差異が生じたり、
予想もつかなかい障害が発生するという問題を引き起こしているのだ。

ドキュメントはあくまで方針決定の材料であり、
完全遵守の目標ではない。
もし。
目標にしてそれ通りに作成した場合でも
「( ´∀｀)＜なんか使いにくいよね〜。こうしてよ」
と平気な顔して告げてくるのはどこのだれだと思います？
そのドキュメントを作ったひとですよ。基本設計者ですよ？ＳＥですよ？
ドキュメント作成者が自らの成果を否定する行為ってやつです。
不完全なものだったんでしょうねってことが想像できます。
不完全なものを金科玉条として扱う必要がありますか。
いやない。（反語）

おおかたそれに従う。けれども違いは必ず沸き起こる。
違いを認識せずに進めば必ず歪む。
歪みを拡大させないためにわれら開発者は事前に手を打つのです。
その打たれた手に気づくためには開発者を使う側の意識が必要なのです。

ソフトウェア製造における開発技術マネジメントを成功させる鍵は、
このような“現場の自由度”を、どのようにして制限（適正化）するかにある。
つまり標準化と開発現場の統制が求められるのである。

問題点がずれてるから結論まで妙なことになる。
締め付けを厳しくして開発が成功するのが正しい方法なのであれば、
世の中のシステム開発の成功率はもっと高いものになっているだろうことが想像できます。

現実はそうじゃないだろ。

ってなことを改めて考えたときに。
開発技術のマネジメントは悪いことじゃないけれど、
世の中の言葉を修正するための知識が必要だなと思えてくる。
意識を変革させるための結果が必要だなと思えてくる。

*

ってか。
IT技術を披露する側がこんなんだと未来がとても暗く感じる。
こんなんを見て、こんなんをそのまま実行されたときの方向修正のための労力がいるかと思うとクラクラしてくる。
そんなことを思いながら、
開発者への依存度を適正化する「開発技術マネジメント支援サービス」
のリンクをおしたらもっとクラクラした。
http://itpro.nikkeibp.co.jp/as/nri4/02.html
ここの「図5」

＿|￣|○