ソフトウェア開発内製化を成功させるために必要なこと

新年あけましておめでとうございます。
ディベロップメントテクノロジーセンターのあおやまです。

コロナで大変な状況はまだ続いておりますが、みなさんいかがお過ごしでしょうか?

2021年最初のテーマはソフトウェア開発の内製化を成功させるために必要な「標準化」についてお話しさせていただきます。

内製化の課題

昨今、DX(デジタルトランスフォーメーション)を実現するため、システムインテグレータに全部お任せするのではなく、お客様が主体となって内製化する流れが強まっています。例えば、AIやデータアナリティクスのPoCに取り掛かったり、アジャイル、DevOps、Microservicesなどへの取り組みを始められています。

PoCや特定プロジェクトへの新技術の導入で一定の成果をあげ、その後の内製化を着実に進められているお客様がいらっしゃる一方で、成果を横展開する次のステップで苦戦されているお客様が散見されます。

PoCなどお試しで「やってみた」だけの技術ノウハウは、特定プロジェクトへの依存が強すぎて、他プロジェクトには展開しにくいからです。こうした状況に対処するため、実は昔から「標準化」と呼ばれる成果物を再利用する汎化が欠かせません。

「標準化」について

「標準化」というのは、具体的には作業や進め方(プロセス)などをガイドとしてまとめたり、プロジェクトの成果物を再利用できるようにすることで、新しい技術や知見を現場に普及させると同時に、効率や品質の向上を実現します。

一般に、こういった標準化活動に関してはシステムインテグレータに一日の長があります。例えば、私たちもWebアプリケーションを開発するための「Ciel2(シール・ツー)」と名付けた統合開発フレームワークを社内展開しています。

主な機能・サービスは、以下のとおりです。

・開発言語/フレームワーク/アーキテキチャの提供
・ドキュメント(設計書やテスト仕様 書など)の標準化
・各種処理方式設計の提供
・再利用可能な共通部品の提供
・設計作業を標準化する設計指針や設計書テンプレートを継続改善
・上記テンプレートからソースコードや定義ファイル等を自動生成する開発支援ツール群を充実
・プロジェクト雛型の提供
・コーディング規約/ローカル環境構築ガイドなど各種ガイドの提供
・開発プロセスの標準化
・配布場所・情報共有・QA場所の提供
・教育・サポート

この原稿が書かれた2020年12月現在、Ciel2は当社内で相当数の本番プロジェクトで活用されています。

「標準化」の難しさ

ただし、こうした標準化はさじ加減が難しいものです。汎化しすぎると痒いところに手が届きにくくなる一方で、自由度を高めすぎると標準化活動としての効果が薄れ、効率化/品質向上の横展開には至りません。

また、従来のウォーターフォール開発ではルールをきっちりと決めた重厚な標準化が好まれましたが、アジャイル開発では、アジャイルと標準化は相容れないという方もいたりして標準化の有りようも変わります。

運用面でも課題が多くあります。私が直面した数々の課題の中から代表的な3つを紹介します。

なかなか認知してもらえない
足掛け5年以上、活動していても知らない社員もいます。
全社で行っている夕礼で度々紹介したり、全社の情報サイトなどを準備しても見てもらえないなど、なかなか認知してもらえません。

なかなか使ってもらえない
ガイドを準備して、各部門に通って説明しても、なかなか現場では使ってもらえません。「なぜ、フレームワークを使ってくれないのか?」と直接技術者に問いかけても、フレームワーク主機能への不満はほとんどないため、改善の糸口がつかみにくい事も多いです。また当社は良くも悪くもお客様毎に臨機応変に対応することが多いため、こちらからの標準化を必ずしも受け入れられない場合もあります。

維持が大変
前出の「Ciel2」は、Springがベースとなるオープン系システム開発の総合開発フレームワークです。母体がバージョンアップすると、当社フレームワークも追随しないといけません。その都度、ドキュメント更新も発生しますが、これが運用する側にとっては大きな負担となります。さらに、フレームワークを活用してくれる現場からは、フレームワークとは無関係な質問も飛んできますが対応が必要となります。

「標準化」を進めるために

実は「標準化」の成功のために必要なのは「内容の良し悪し」ではなく、きちんと標準化を現場に適応するプロセスが準備できて、現場で使ってもらえるように考えて工夫することです。

そのため標準化においては「良い標準化の内容を準備すれば大丈夫」「よいツールを導入すれば大丈夫」と考えていると、なかなかうまくいきません。また現場の意見を無視して一方的に押し付けようとしても、やはりうまくいきません。

上記の「Ciel2」も最初は再利用可能なフレームワーク・共通部品の提供から始めたのですが、現場でなかなか使ってもらえませんでした。
色々現場の意見を聞いたり、自身で積極的に使う中で、設計の時点からフレームワーク・共通部品を利用を前提としないと導入しにくいことに気づき、設計時の標準化も併せて提供することにより、ようやく使われるようになってきたという経験があります

こうしたな努力を積み重ねたとしても、現実には標準化活動はなかなか認知されませんし、現場に根付きません。そういった中でも地道に活動を進めて行くしかありません。

まとめ

標準化は一回まとめたら「終わり」でなく、繰り返し何度も現場に適応して改善していかなければなりません。

「より使い勝手が良くなる」よう、私たち標準化推進チームは地道な改善を繰り返しました。こうした課題をいくつも乗り越え、提供した標準化が現場に普及していくと、今度は現場から「あれもこれも」と希望であったり、Q&Aが寄せられて、よりよいものになっていきます。

最近は私たちの経験に基づいて「事業部門でソフトウェア開発を内製化したい」「DevOpsを推進しようとしているがどうしたらいいか?」といったお客様の相談に乗る機会も増えてきてます。この記事を読んで気になられた方はお気軽にご連絡をください。

  • このエントリーをはてなブックマークに追加