「標準化」の呪縛を解こう――まるで封建時代？ “標準化絶対主義”がもたらすもの：不真面目DXのすすめ

もともと工業をモデルの一つとしてきたIT業界には標準化を推進する文化がありますが、筆者は「ソフトウェアは工業製品とは違う」と言います。何も決まりがなければ開発現場はカオスとなる一方で、標準化が行き過ぎれば弊害が生まれます。ソフトウェア開発における標準化はどうあるべきか、標準化絶対主義の“呪縛”を解いて考えてみましょう。

[甲元宏明，株式会社アイ・ティ・アール]

この連載について

　この連載では、ITRの甲元宏明氏（プリンシパル・アナリスト）が企業経営者やITリーダー、IT部門の皆さんに向けて「不真面目」DXをお勧めします。

　「不真面目なんてけしからん」と、「戻る」ボタンを押さないでください。

　これまでの思考を疑い、必要であればひっくり返したり、これまでの実績や定説よりも時には直感を信じて新しいテクノロジーを導入したり――。独自性のある新しいサービスやイノベーションを生み出してきたのは、日本社会では推奨されてこなかったこうした「不真面目さ」ではないでしょうか。

　変革（トランスフォーメーション）に日々真面目に取り組む皆さんも、このコラムを読む時間は「不真面目」にDXをとらえなおしてみませんか。今よりさらに柔軟な思考にトランスフォーメーションするための一つの助けになるかもしれません。

筆者紹介：甲元 宏明（アイ・ティ・アール　プリンシパル・アナリスト）

三菱マテリアルでモデリング／アジャイル開発によるサプライチェーン改革やCRM・eコマースなどのシステム開発、ネットワーク再構築、グループ全体のIT戦略立案を主導。欧州企業との合弁事業ではグローバルIT責任者として欧州や北米、アジアのITを統括し、IT戦略立案・ERP展開を実施。2007年より現職。クラウド・コンピューティング、ネットワーク、ITアーキテクチャ、アジャイル開発／DevOps、開発言語／フレームワーク、OSSなどを担当し、ソリューション選定、再構築、導入などのプロジェクトを手がける。ユーザー企業のITアーキテクチャ設計や、ITベンダーの事業戦略などのコンサルティングの実績も豊富。

　IT業界は歴史が短いせいか、他業界を参考にしていることが多くあります。ITでよく登場する「アーキテクチャ」はもともと建築業界用語です。前回の本連載にも書いたように、IT業界は製造業に倣って「標準化」を推進してソフトウェア開発を「工業化」することに注力してきました。

　それでは、ソフトウェアの開発は工業製品を製造することと同じなのでしょうか。筆者には強い違和感があります。

標準化の“価値”を再考しよう

　今や、安価なPCやタブレットがあれば、誰でもソフトウェアを開発できます。クラウドを使えば、いつでも世界に向けてソフトウェアを公開することもできます。

本来、ソフトウェア開発とは、自由な発想で大きな資本や設備も必要とせずにゼロから革新的なアプリケーションを生みだせるものです。

　五線譜に頭の中に浮かんだすてきなメロディーを記したり、どこでも売っている画用紙と絵の具で美しい絵画を描いたりするのと同じ行為なのです。

　このように考えれば、ソフトウェアは「アート作品」と言ってもよいと思います。

　そもそも、標準化にどれほどの価値があるのかは明確ではありません。標準化には、非標準を全く許さない強いものから、緩いガイドライン的なものなど、いろいろなグレードがあります。ただ、さまざまな標準化を定量的に評価して、標準化の効果を検証したデータはあるのでしょうか。筆者は寡聞にして知りません。

　国内のユーザー企業およびSIerは、「標準化」に長い間挑戦し続けていますが、標準化に成功した企業は非常に少ないと思います。中でも、SIerの多くは自社で標準的なメソドロジーや開発プロセスを定めていますが、そこから逸脱するプロジェクトも多く存在します。

　ガイドラインやルールが何もなく、個々のエンジニアが自由気ままに開発を行う“無法地帯”と比べれば、「標準化の方がよい」と誰もが考えるでしょう。しかし、前述の通り、標準化の効果は明確ではありません。

　それにもかかわらず、「標準化は当たり前のこと」と考える人が圧倒的に多く、その是非を真剣に考えた人は少ないのが実情でしょう。

　“無法地帯”にならない程度の緩い標準化は必要ですが、多くの企業が目指している過度な「標準化」はない方がよいのです。

行き過ぎた「標準化」は「進化停止」につながる

　そもそも日本のIT業界が標準化を推進してきたのは、深い階層構造の組織体制で成立しているSI（システムインテグレーション）ビジネスと深い関係があります。

　上流設計や基本設計、詳細設計、実装、テスト、運用など、機能役割別に担当者が分かれていて、それらの層がピラミッド型に積み重なっています。実装担当の開発者は設計者が作成する仕様を標準にのっとって淡々とコーディングするだけの業務に従事していることがほとんどです。

　実装担当者がその仕様に疑問を持ったり、より良いアイデアを思いついたりしても、上の階層にいる人たちに伝達することすらも許されていない、まるで身分制度の厳しかった封建時代を彷彿とさせるプロジェクトも多く存在しています。

　驚くことに、誰もが発想しなかったような新しいビジネスアイデアを革新的なソフトウェアで具現化すべきDXプロジェクトにおいても、このような旧態依然とした体制で進められていることが多いのが日本の実情です。このような体制で向上心があって高いモチベーションを持ったエンジニアを育成できるはずがありません。

　巨大なシステム開発プロジェクトでは、「初期に策定した標準を全員でしっかり守って進めた結果、そのシステムが稼働する時には時代遅れのテクノロジーだらけになっていた」という“笑えない話”が数多くあります。

　最低限のルールやガイドラインは必要です。そうでなければ、開発現場はカオスに陥ってしまいます。厳格な標準を規定したとしても、短サイクルでそれらを見直す仕組みがあれば、標準化も悪くありません。

　しかし、ほとんどのケースにおいて標準化は厳格で不可侵な法律的存在になり、新規テクノロジーの適用を阻止する存在になり得ます。つまり「標準化＝進化停止」になる可能性が高いのです。

　では、開発現場にカオスをもたらすことなく、標準化が進化を食い止める存在にならないようにするためにはどうすべきでしょうか。

　マイクロサービス・アーキテクチャを採用すれば、全てのシステムに共通する標準を規定する必要はありません。マイクロサービス単位で採用するテクノロジーやサービスを短サイクルで見直すことで、テクノロジー進化に対応することも容易になります。

　1人のエンジニアが設計から実装、テスト、運用を担当するようなマルチスキル・エンジニアの集団が自由闊達（かったつ）にコミュニケーションできる環境を作れば、緩やかな標準は自然発生します。テクノロジー進化に果敢に挑戦する体制を構築することもできます。

　ここで書いた解決策は一例にすぎず、唯一解ではありません。ソフトウェア開発に関わる全ての人に、全員がいつもワクワクしながらソフトウェア開発ができるようにするにはどうしたらよいのか考えていただきたいのです。

「『不真面目』DXのすすめ」のバックナンバーはこちら。