開発技術は日を追う毎に複雑になってきます。
昔勉強したものも今現在では役に立たない、むしろ固執することで足かせになることが多いかもしれません。
なまじ過去に成功体験を多く持っている人は、時代の変化によって、勝利の方程式だと信じてやまないプロセスが通用しなくなってきたことに焦りや苛立ちを持っているのではないでしょうか。私もその中の一人だったりします。
システムの利用者にとって「価値あるもの」の定義も時間とともに変化していきます。システム開発当初に合意した仕様が今も正しい仕様である保証はありません。ビジネス自体が変化しなければならないのにシステムが追いつけなくて足かせになっている、というのは非常に不幸な状況です。
システムの作り方に問題があるのでしょうか？
開発言語の選定が甘かったのでしょうか？
ケース・バイ・ケースではあるでしょうけど、ただ、１つ言えるのは、時間の経過により、仕様の『鮮度』が落ちるものがある、ということです。システムは作って終わりではありません。
長期間変更が不要な保存の効く仕様ばかりではありませんし、システムが提供する機能に対して使用されているのか、仕様はこのままで良いのかの棚卸が必要ではないでしょうか。
要件定義の際には必要だと思われた機能が今では誰からも使用されていない場合、思い切ってdropし、機能を必要最低限のものとして保守工数を減らし、その分新しい機能の追加工数に充てる、とか、技術的、ビジネス的な観点でジャッジできる体制にならなければなりません。
一括請負の受託開発の場合
仕様の決定に関しては開発費用を出すユーザ側が立場が上であることが多く、その決定は開発側だけでは如何ともし難い状況が多いでしょう。場合によっては、ユーザ側は予算の中で開発側に機能をいくつ作らせるか腐心することもあるかもしれません。機能が多いからといって、良いシステムになるわけではないのに、です。一般的にはお金を払う側が強いので、主従関係となってしまうことが多いでしょう。
このような関係では、良い提案が出てくる可能性は皆無で、開発側は提示された仕様を愚直にシステム化することだけに専念します。契約から逸脱すること無く、それ以上でも以下でもないシステムが出来上がることになります。
で、開発現場の若手は今までの成功事例を元にした超保守的な仕事が面白くないもんだから社外の勉強会に参加するようになって新しいことを学ぶんだけど「結局今の状況じゃ何も変わらない」と思って社内で活かすことをせず、「誰かの目に止まらないかな」と淡い期待を込めながらgithubにソースコードを上げてキャッキャウフフすることに注力するようになります。悪循環。
頑張ってシステムを完成させて、利用者から改善要望が来た場合、追加工数が無ければ何もしないと突っぱねます。要件の考慮漏れだったとしても同様。金を貰わずに作業をするのではビジネスは成り立たないのも理解できます。
多くの人が受託開発に見切りをつけようとしているこの状況を改善するには、継続的にシステムに携わることのできる契約形態を模索しなければならないと思います。
システム開発の成功は、QCDも確かにあるかもしれませんが、当初の予定通りの費用対効果が出たか、ということであるべきで、「完成したか」ではないはずです。ですが、一括請負の受託開発の場合、契約として成果物責任があるので完成させなければなりません。
アジャイル開発と呼ばれるものの本当のメリット
小さな機能に分割して作りながら様子を見ながらやりましょうよ、と言ってますけど、基本的には開発側と利用者でゴールを共有しようよ、ということが大前提にあるはずです。
契約で縛り合うのではなく、良好な信頼関係を築くほうが生産性は何倍も上がるだろうし、多少の無理は聞くでしょう。基本的に開発側は利用者に喜ばれたいんですから。
契約による縛りとその限界
一括請負の契約で縛ることで開発側は下手な見積を出すわけにもいかず、それなりに精査し、リスクを積み、失敗しないようにしようとします。時間もかかるし結局高くつくことでしょう。一括請負は「発注したシステムが完成しなかった」リスクを回避する為の契約で、「価値あるシステムを保証する契約」ではありません。
これからはシステム開発に関しても費用対効果を鑑みることが重要だと思います。「システムが完成しない」よりも「コストをかけて価値がないシステムを作った」方がよりリスクだと考えなければならないでしょう。
企業と社内システムのあるべき形とまとめ
仕様の叩き台を元に開発(実現)するための工数と、得られる効果を天秤にかけて、実施のジャッジ／合意をするようにならなければ、システム化の目的がブレてしまいます。また、機能を詰め込みすぎてシステムが肥大化し、リプレースを行う時のハードルにならない様にするために、機能の棚卸も必要でしょう。使わないものは捨てる、部屋と一緒ですよ。
本来、そのジャッジはユーザ企業で行う必要があるのですが、社内システムを内製する文化にない企業では難しいでしょう。実現する為の工数が検討もつきませんから。そこで、信頼出来るパートナーを見つけることと、いつでも相談できるような契約を結ぶ、ということが必要だと考えます。
ユーザ企業と開発側が、契約でなく信頼関係で結ばれれば、受託開発も面白く感じる人が増えるんじゃないかなぁ、と考えます。幅広くそれなりのスキルがなければやっていけないと思いますけどね。ただ、厳しい時代には変わりない。
