前提
大型プロジェクトにおいて設計段階が終わり、いざプログラミング作業が始まり、現場には数多くの開発者達が集められて会議、プログラミング、単体テスト、結合テストを集中的に行う姿はもはや見慣れた景色でしょう、ところが、ところが、ですよ、入れ替わり立ち代わり大勢いの開発者達が作業をしています、しかも、3か月単位で働くような非正規社員が大量に導入されます、それでも、オンスケ（オンスケジュール）にはなりません、夜遅くまで、あるいは、休出して頑張る開発者達、問題は何故そうなるのかを私の経験した範囲で記述してみたいと思います
一番大きな要因
システムが完成した暁にはエンドユーザーにてシステムが実利用されます、そして、この日はシステム開発が順調に進んだことを前提に決められています、ここが肝心、この日程は後ろには伸びません、ユーザー活動のすべての環境がこの日からシステムが順調に実行することを前提に動いており、エンドユーザーへも大々的な周知が行われています、もし、システムが順調に稼働しなかったら、もし、システムダウンしたら、ユーザーは将来不安となり、ニュースにもなり、何よりもエンドユーザーにも迷惑がかかります、もう一度言いますね、システム稼働初日の日付は後ろには伸びないのです、特に、設計の遅れは、以降のスケジュール全体の大幅な遅れとつながっていきます
設計期間が延びて開発期間を圧迫
設計の不備を開発段階で訂正しようとすれば10倍の期間が必要と良く言われます、設計の不備は何故起きるのでしょうか、単純な見方として開発側の設計者の実力不足、経験不足、管理能力不足が挙げられるかもしれませんが、それだけではありません、大きな企業相手のシステム化はまさに伏魔殿の世界、現状のユーザー実態の把握は簡単ではありません、部署だけでもかなりの数です、その部署間でどのような情報がどのように行きかっているのかを把握するのは簡単ではありません、開発者がユーザーに確認しても「さあ、どうなっているのか、調査しますね」と言ってはみたものの返事は来ません、このような保留項目が多数発生するのです、そして、その保留項目は設計段階が終わり開発段階が来ても解決しなかったりします「お客様は神様です」ユーザーに対して開発側はあまり強くは言えないのが現状でしょう
ペンディング事項の解決方法、二人のSE
このようなペンディング（保留）事項の解決手段として、開発者側から優秀な案を提示しユーザーを納得させなければなりません、経験豊かな実績ある開発者側のSEが必要な理由がここにあります、欲を言えば、ユーザー側にも自社を良く知る、かつ、システム開発に熟知したSEが必要です、双方のSEが揃っていなければ設計段階を順調に乗り切るのは難しいのです
設計とプログラミングの並行作業が意味するものとは
設計段階が順調でなければ設計段階が開発時期に食い込んでくるわけです、こんな状態はもはや、珍しくもなんともないのでしょう、そして、設計の会議が行われている横でプログラミングが行われている光景は危険な匂いを感じさせています、設計とプログラミングの同時並行作業はプロジェクト崩壊の未来を予見しているのです
開発側の問題点を深堀
例えば、小さな病院ステムを作ってきた企業が大規模病院システム開発を受注した、小さな新聞システムの実績ある企業が大規模新聞システムを受注した、こんなケースに私は遭遇した経験があります、まず、最初の問題点として設計の複雑さがまったく違うのです、はっきり言って別物です、第二の問題点は小規模と大規模では使われるはネットワーク、言語、データベース、等はこれもまったくの別物です、別物の正体は得意分野や性能がまるで違うのです、当時はこの辺の意識がまだまだ低かったように思う、受注した開発企業の技術者達は使いなれた言語やデータベースを使いたがるのです、しかし、それでは大規模開発には向かないことを開発の途中で気が付くのですが、やり直す時間なんてありません、とことん、そのままで乗り切ろうとしますが悲劇が起きます、それは応答時間の遅さです、システムとしては致命的です、単体テストでは気がつきませんでしたが、結合試験を行った時の応答時間の遅さには絶望感さえありました、ですが、開発者全員がそこには声を上げずに作業に集中していたような職場だったのです、後日、このプロジェクトが頓挫（失敗）したと聞かされた時は驚きもせず納得感を感じたのを今でも覚えています
開発現場のこんな雰囲気、危険プロジェクトの証
今、思うと、このプロジェクトに要件定義書なんて存在していたのでしょうか、開発作業（プログラミング、デバッグ）は声を出さずとも作業は可能です、しかし、営業担当の会議は声を出さないとできません、一つの大きなフロアー内で坦々と行われているプログラミング作業、声が行きかう営業担当の会議、営業担当は毎日のように病院システムの足りない部分、あるいは、不具合な部分の洗い出しを行っていたのです、その声は作業をしているプログラマー達には良く聞こえていました、その内容から「もしかして、今、プログラミング中の箇所は変更があるのでは」と何度も感じました、プログラミング側としては梯子をはずされた気持ちになります、そうなのです、このプロジェクトは火を噴いています、短期間作業を行う非正規社員が繰り返し繰り返し、月末になると去って行き、月初めにはやってくる、机や椅子の移動が頻繁に行われるとても落ち着かないプロジェクトなのです、もうお分かりですね、このプロジェクトの行く末は？、あなたの期待した通りの結果になりました、のちに、開発会社がユーザーに支払った賠償金がX億円であるとの噂が流れました
昔と今
ここまで読んでくれてありがとう
「今は昔と開発手法が違うよ」と感じた方もいると思います
何かの参考になってくれれば、それだけで十分ですね
残すことが大切なのです
コメント