090.開発手法なんて何でもよい
初回：2020/08/19
1.開発手法は何でもよい
P子「また、喧嘩売ってるの？」（※1）
開発手法は大きく分けると「ウォーターフォール」「プロトタイプ」「アジャイル」「スパイラル」などに分類できますが、要するに開発手法なんて何でもいいんです。
P子「何でもいいって事はないでしょ」
納期通りに予算の範囲内で要求仕様通りのシステムが完成すれば...ですけど。そういう意味では何でもいいハズです。ここで開発手法を選択する場合、組織の開発手法に対する理解度、リーダーやメンバーのスキルなどを考慮の上、先の要件(QCD)を満足させる事ができる手法を選択すればよいのです。
さて、システム開発で一番費用が掛かるのは何でしょうか？
P子「そういう聞き方をする場合は『開発費』じゃないってことね」
深読みしすぎですが正解です。『開発費』ではありません。『保守費』というか『維持費』です。システムの発注者と受注者を考えてみます。受注者＝システム開発会社からすれば、開発手法が重要であり、最も利益の出る安全確実な方法を採用するでしょう。所が発注者からみれば、システムがどのように作られるかよりも、どうやって維持していくかのほうが重要なはずですが、そこを意識している発注者が少ないと思います。
本来なら、発注者側は維持費のできるだけ掛からないシステムを開発してもらうべきで、そういう開発手法を採用している会社を選ぶ必要があると思います。
ここでいう『保守費』とは、システムが完成した後、運用を開始してからの運用費、システムトラブルなどに対応する保守費、時代や業界の動きに対応する改善費、システムを破棄し次世代のシステムに置き換えるためのリプレース費なども含むと考えてください。
システム開発会社は開発費についてはきちんと対応しますが、保守費については適当です。っていうか、保守費で利益を出そうとしているのでしょうか？ 保守費で利益は出しにくいというのが現実です。トラブルを起こしてそこから利益を出すなんて出来ないでしょうし、維持にお金がかかりますって、言えないでしょう。
つまり、保守費で稼げないし、保守費がいくらかかるかは発注者側もあまり気にしないから、保守費を低減するための開発手法という考え方が、生まれてきません。
2.保守費を低減する手法
システム開発会社は、何も手を打っていない事はありません。保守にあたって、開発ドキュメントを整理しましょうとか、保守担当者をジョブローテーションしてその人しか判らない(保守できない)システムにしないなどの手は打っています。その程度です。
開発ドキュメントについては、私は賛成であり反対の立場を取っています。
P子「どっちなの？」
まず、開発のためのドキュメントと維持のためのドキュメントは分けるべきだと思っています。そのうえで、開発のためのドキュメントは、システムが完成すれば不要になりますから、適当でよいでしょう。維持するためのドキュメントはきっちり作る必要がありますが、システムと別に作ると食い違いが出てきます。つまり、システムから自動生成などの手法で作るべきと考えています。これは、javaDocなどのソースと紐付いたドキュメンテーションが有効だと思っています。ソースコードの修正都度、きちんとメンテナンスしていきます。
システム開発においてDB定義書も重要なドキュメントですが、通常EXCEL等で作ることが多いでしょう。そしてマクロなどでテーブル作成スクリプトを自動生成させるとか...
そういう手法では、データベースのスキーマ(DB定義構造)とDB定義書、スクリプトが一致しません。システム機能改善等でデータベースの定義を変更した場合、DB定義書、作成スクリプトをきちんとメンテしないで、データベースを直接変更してしまうケースがあるためです。
DB定義書、作成スクリプト、スキーマは、一致している必要があります。しかも正確に低コストで。という事は、これらを管理する仕組みを最初から開発手法に含めておく必要があるという事です。
P子「開発手法というか、開発ツールね」
改善費に関しては『おでん方式』がベストだと思っています。つまり、システムを常に継ぎ足しながら改善を続けるのが、最終的に一番コストがかからない方法だと思います。ただし、何年、何十年と継ぎ足して使っていたシステムをリプレースすることはできません。リプレース費が高くつく、または、根本的にリプレースできない状態になっていると考えられます。
例えば、原子力発電所を作って運用して廃炉する。この廃炉作業は非常に困難です。逆に、太陽光発電を行っており、発電をやめる際に太陽光パネルの取り外しは簡単です。
P子「電子力発電所レベルの太陽光発電施設なら、破棄するのは大変でしょ」
そんなことは無いようなことは無い感じもしないでもないかもしれないこともない気がします。
P子「そこは弱気になるんですね」
何が言いたいかというと、大きなシステムをドンと入れるのではなく、小さなシステムを入れて使わなくなれば捨てる...という手法はどうかと考えています。
P子「マイクロサービスってこと？」
ん－、そんなことは無いようなことは無い感じも...
P子「もういいです」
マイクロサービス的かもしれませんが、いくらシステムが疎結合だといっても、複雑に絡み合って訳が分からなくなる気がします。これも『おでん方式』で継続的に維持していくことになるのでしょう。
3.まとめ
開発手法には、「ウォーターフォール」「プロトタイプ」「アジャイル」「スパイラル」「おでん方式」などに分類できますが、推奨する方式は、「おでん方式」だという事です。
P子「それが言いたかっただけ？」
そんなことは無いようなことは無い感じもしないでもないかもしれないこともない気がします。
P子「最近、そのフレーズもコピペで手抜きしてない？」
ん－、そんなことは無いようなことは無い感じも...
P子「もういいです」
ほな、さいなら
======= <<注釈>>=======
※1P子「また、喧嘩売ってるの？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。