ソースコード自動生成やテスト自動化等の開発自動化を推進したPJほど、維持管理フェーズで生産性は飛躍できる！
僕が参画したPJは、大規模な金融系システムで、数十年ぶりの全面更改案件だった。設計書からソースコードを自動生成するツールを適用した開発や、テスト自動化の取組など、自動化を推進した先進的なPJだと評された。
ソフトウェア開発自動化は、ある程度大きいSIerなら、どこでも取り組んでいる施策だが、どこのSIerも期待通りの効果が得られず、パッとしないのが現実。でも適用したこと自体が、成果のように社内で報告されるため、その闇の部分には光が当たらず、名ばかりの自動化開発プロセスが、イタズラに作業を増やし、現場を圧迫し、維持管理フェーズに入ってからも、十分な利益が上がらないPJ運営が続く。案件を受ければ受けるほど、辛くなるという、最悪の状態になる。
でも、僕は、自動化開発プロセスを多く採用したPJは、維持管理フェーズで、ドル箱になるチャンスを大いに秘めている。それが開花しない原因は、「導入しっ放し」で終わらせてしまうことにあると考えている。
その問題点を明らかにしつつ、実際に取り組んできた改善と、今まさに取り組もうとしている改善について論じて行きたいと思う。自動化をやりきった感が蔓延るPJで、さらなる原価削減の使命をもつPMの方や、非効率な作業に頭を抱える現場のSEの方が、今を変える一助にきっとなるはず。
一般的に、自動化の生産性向上効果はないと言われる理由
ソースコード自動生成ツールの仕組は、設計書をインプットにソースコードをアウトプットする。というものだ。だから、設計書の情報をソースコードが吐き出せるレベルに詳細化し、ソリューションが解釈しやすいように、構造化する必要が出てくる。
担当者は、設計書の記述ルールを覚える必要があるし、ルールに沿って記述する必要が出てくる。結局は、「ツール専用言語によりコーディングするに等しい労力」が必要になる。ゆえに、普通にコーディング出来る技術者からすれば、鬱陶しい限りだし、プログラミングができないとキチンとした設計もできないので、誰でも出来るわけでもない。また開発期間についても、製造の作業が設計に寄るだけで、本質的な生産性向上には繋がらない。更には自動化といいつつ、実際は半自動化だ。業務ロジック部分はの設計は、ツールは解釈できない。完全に自動生成できるのは、DTOなどの構造化された設計だけ。その解釈できない部分は、人間が作業で補う。僕のPJでは、まさにツール専用言語があり、設計書の通りに、コーディングする作業がごっそり残っている、半自動化PJだった。そのため、設計書どおりに実装されていることを確認するUTレベルの試験も、全てやる必要がでてくる。はっきり言って、生産性向上への直接的な寄与はないだろう。
それでも、品質が重要な巨大PJでは選ぶ理由になる
自動化なのに、生産性向上に寄与しないなら、選択する意味がないじゃないか！というのが、よくある批判であり、直接的な生産性の観点では、そのとおりである。それでも現実に適用するPJがでてくることは、政治的理由もあるだろうけど、実質的な効果もあるからだと、僕は思う。例えば、自動生成は、自由度が低いため、設計思想からの逸脱した実装の防止や、コードの標準化を実現できる点は、評価できると思う。特に僕の参画したPJでは、言語のネイティブライブラリは介さず、FWのライブラリを使用することで、言語のバージョンアップ時の影響から保護しようという発想の設計思想だったので、こうしたライブラリの選択なども制限できていた。もちろん他にも方法はあるとは思うが、数百人規模の開発で、実装を標準化できた事実もあり、このこと自体は否定できない。大型案件の開発で、品質確保を実現することは、口で言うより難しい。金融系の重要なシステムであれば、通常レベルの生産性で、高品質を実現できるのであれば、効果あると言わざる得ない側面もある。日々、開発に勤しむSEの方はよくよくお判りだと思いますが。PDCAなどと言いますが、P（計画）はいい加減、D（実行）は人海戦術でのりきる、C（確認）は疎かゆえに、繰り返し、問題が生じた事後のA（対処）は、迅速。皆様もそんな現場なのでは？
ソース自動生成適用PJで、生産性が上がらない理由は簡単。ソースが自動生成されないからだ！
ソースコード自動生成ツールは、品質面での寄与しかないと言ったが、それは結果論。導入時には、PMが期待する主眼は、生産性の向上にある。そもそも、設計書を必要としない案件において、自動化適用した場合、設計書執筆は純増作業になるが、設計書が必要な案件においては、その増分は問題になるほどではない。では、問題は何かと言うと、ツールだけで100％自動生成できないことである。僕のPJでは、以下の手順で製造を行う。
- 設計書をツールに食わせると、新たな設計書が生成される。
- 元の設計書に記載された通りに、人間が業務ロジックをツール専用言語を使って、新たな設計書にコーディングする。
つまり、ツールが解釈できない設計書の内容があるから、結局は人間が作業を埋める必要がある。100％自動生成できず、人間の作業が入るので、UTも省略することができない。結局は、ちょっとした便利ツールの範疇の効果しか実現できてないツールになっている。基本的に、企業の本部施策の自動化ツールは、いろいろなPJに適用できるよう、汎用的に設計された上で、ある程度の個別カスタマイズができるようになっている。もちろんツールにJustFitするようなシステム、させられるシステムであれば、100%自動生成を最初から実現することもできるだろう。しかし、現実は、以下のような壁があり、開発中にリアルタイムに100%自動生成には持っていけない。
- 新しいシステムを構築する場合、新しい設計思想が適用されており、実装が定まりきってない部分もあり、設計と実装を紐付けることが難しい。
- 個別カスタマイズには、社内取引で、ツール開発部署の要員を雇って、進める必要があるが、その費用が捻出できない。
- 仮に、費用が捻出できたとしても、ツール開発部署要員は、現場を知らない理論重視の頭でっかち。現場の課題を分析して、リアルタイムにカスタマイズを行うようなスピーディで柔軟な対応はできない。
このような感じで、自動生成が達成されることはなく、半自動生成にとどまる。だから生産性があがらないんだ。
ツール開発部署は、導入したら終わり。でも自動生成率の向上は、導入した後にこそ実現性が高まる！
僕の会社のツール開発部署は、導入部隊だ。導入して、開発が終われば、PJから去ってしまう。しかも、ツール開発部署のサービスとして、アフターフォローのメニューもない。もともと、導入した後により良くするという概念を持たない組織が、ツールを開発してしまってる。その影響を受けて、PJ側も「自動化はやりきった」と勘違いしてしまう。でも、僕のPJで自動生成できない部分をどのように補っていたか思い出してほしい。「設計書に記載された通りに、ツール専用言語でコーディング」していたんだ。設計書に書いてあるのに、ツールが解釈できないので、人間が作業で埋めていたということだ。ということは、ツールが解釈できれば、人間の作業を排除できるんだよね。僕のPJの場合、製造／単体試験の工程が、全体の3割くらいを占めてるので、これを仮に100％自動生成にもっていくと、30％の原価削減、利益向上に繋がることになる。これだけ聞くと、理想論だと思われそうだけど、実際そうでもない。ソースコード自動生成を導入したPJの設計書は、かなり精緻だ。そして、維持管理フェーズでは、その設計書に対応するソースコードも全てある。設計書とソースコードを分析していけば、自動生成できるポテンシャルが相当量あることに、気がつくはずだ。この分析を徹底的にやって、今より自動生成の幅を広げることは、確実に出来る。ここを無理だと諦めず、リソースをつけて、しっかり検討することで、維持管理フェーズはドル箱パラダイスに生まれ変わることができる！！
今日はここまで。次回は、テスト自動化を題材に、自動化に関する問題点と、実際に僕がPJで実施し、効果がでた改善策を書いてみようと思います。
