開発・運用変革のためにやるべきこと　～アシストの実践的サービスをもとにした最初のステップと手法をご紹介～（開発編）

企業の デジタルフォーメーション（DX） 活動に伴い、DX を支える開発や運用管理にもトランスフォーメーション（変革）が必要になってきています。アシストではIT部門にDXをもたらす開発＆運用手法として、IT基盤が大きく変化する４つのタイミングを捉えアプローチしていくことをお勧めしています。

　参考記事： 「DXをもたらす開発、運用へアップデート！面倒くさいをなくす変革アプローチとは？」

本記事では、システムリプレースやビジネスにおけるDX推進のタイミングで変革を推進する「開発変革アプローチ」の中から、最初のステップである、現状の可視化と組織内での共通認識化を中心に、アシストが実際にお客様にご提供しているサービスをベースに手法を解説していきます。実践的な手法ですので、是非、開発改善の取り組みのヒントにしていただきたいと思います

アシストでは、開発プロセスに対する課題を深掘りし、開発担当者間でボトルネックの可視化により改善計画を立案する手法として「アジャイル開発スタートアップソリューション」を提供しています。本サービスを提供するに至った背景には、アジャイル開発を始めるにあたり、どこから始めるべきか迷われているお客様が多いと感じていたことがありました。

少し古いデータになりますが、アジャイル開発を実践している日本の企業は約30%ということでしたが、アシストのお客様の中でもここ2～3年でアジャイル開発の採用が確実に増えています。一方で、アジャイルを採用してもなかなか効果が出ていないというお客様のお悩みもお伺いします

なぜお客様企業ではアジャイル開発がうまく進まないのか、その要因について考えてみました。

まず、慣れ親しんだウォーターフォール型のプロジェクト進行とは異なり、アジャイル開発ではスクラム、プロダクトオーナー、スクラムマスター、ディリースクラム、またCI/CD、テスト自動化といった新しい概念や要素が語られていて分かりにくいという側面があります。

また、アジャイルを構成する要素を分解し、アシストが着目したのは、「プロジェクト運営」と「技術」の2点です。 例えば、プロジェクト運営、つまりプロジェクトをどう進めるのかについては、開発プロセスとして、ウォーターフォール、プロトタイプ、スパイラル、アジャイルスクラムのどれを採用するのかが挙げられます。もう１つの技術面、つまり開発をどう自動化・省力化するのかについては、テスト自動化、継続的インテグレーション／デリバリ（CI/CD）、Infrastructure as Code、コンテナといった手法があります。

1つ目の「プロジェクト運営」でアジャイルを採用した場合、スクラムのフレームワークに準拠するだけではうまくいきません。これまでの仕事に対する考え方や取り組み方を変える、いわば、文化が従来と大きく異なることが壁になります。しかし、文化の壁はなかなか乗り越えられるものではなく、数年かかることも予測されます。

また、2つ目の「技術」としてアジャイル開発を採用した場合、決められたものや漠然としたアイデアをスピーディに具現化する技術力が必要となります。その技術力はやはり一足飛びに得ることはできません。いわば、技術が壁となります。

アジャイルの実践をはばむ２つの壁「文化」と「技術」をどうやったら乗り越えアジャイル開発を成功させることができるか。これについては、短期的に効果の出やすい「技術」の壁を乗り越えることが現実解であるとアシストでは考えます。

アシストが考える現実的なアプローチは、プロジェクト運営を現状のウォーターフォールから一足飛びでアジャイルにするのではなく、下の図のように、現行の開発プロセスを踏襲しつつアジャイルに向けた技術を採用していくという手法です。

プロジェクト運営として「ウォーターフォール」を採用していても、CI/CDやテスト自動化を十分活用することはできますし、大きな効果をあげることもできます。まずは自動化を中心とした新技術を採用し、小さな成功体験を積み重ねて、改善のサイクルを加速させ、アジャイルが向いていると分かればプロジェクト運営を変えていけばよいのです。

アシストが考えるアジャイル開発への現実的なアプローチをまとめると次のようになります。

　1.　文化を変える以前に、技術を備える

　2.　闇雲な技術の採用は、効果が得られないケースも多く、現場の反感や抵抗を生み出しかねないため、

　　　明確な戦略に基づき、段階的に新技術を採用する

　3.　小さな成功体験を積み重ねていくことが重要である

アシストが提供する「アジャイル開発スタートアップソリューション」は、アジャイルありきのソリューションではなく、現場の開発プロセスを改善するところからスタートします。「アシストが考える現実的アプローチ」で紹介したように、ウォーターフォールを継続しつつも技術面を最新化し、改善を図りたいというお客様にとって特に有益なアプローチだと考えています。

進め方は、課題可視化、改善提案、改善実行の３ステップです。

ステップ１：課題可視化

　（1）VSMワークショップ前の基礎知識習得支援

　（2）VSMワークショップにて客観的に課題を可視化

ステップ２：改善提案

　（3）ボトルネックに対する最適な改善策（ツールキット）を提案

ステップ３：改善実行

　（4）PoCや実証実験のための環境準備を支援

　（5）ツールについての教育支援

ステップ3の改善実行では、PoCや実証実験を行い、まずは小さな成功体験を生み出します。アシストは課題可視化ワークショップのファシリテーターや、改善策の提案またツールの教育や実証実験環境の準備などを支援しています。

見えないものは改善できないため、まずは開発プロセスを可視化して、ボトルネックを正確に把握し、優先順位をつけながら改善へと進めるアプローチをお勧めしています。ここで開発プロセスの可視化を行わず、場当たり的に新しい技術やツールの採用に走ってしまうと、新しいものを覚える、合わせるという現場の負担が非常に大きくなってしまうからです。

アシストでは開発プロセスの可視化とボトルネックの洗い出しのために、バリューストリームマップ（VSM）を利用したワークショップを行っています。

VSMは、アイデアを思いついてからお客様に届けるまでに必要な、関係者全員のタスクをすべて記載することで、一連の流れにおける無駄を排除・改善できる手法であり、開発の現場でも可視化する手法としてよく活用されています。

アシスト社内においても、以下のように、業務プロセスをマップ化し、課題を洗い出す際の手法として活用しています。

本サービスでは、ステップ１の課題可視化で洗い出された課題を解決するためのツールキット（ CI/CDキット）をお客様の課題に応じて提案します。

CI/CDキットは、アジャイル実現に向けてアシストが提供する技術要素の総称です。Jenkins、GitLabを使ったCI/CD基盤（CI/CDキットコア）を中核とし、ボトルネックや優先度に応じて、画面テスト、負荷テスト、ソースコード解析、サーバ構築自動化など必要なオプションを組み合わせてお客様に提案しています。

本サービスを導入された株式会社J-POWERビジネスサービス（J-POWERビジネスサービス）様のIT部門では、ビジネスの中核を成すシステムの開発・運用・保守を行っています。企業の１部門が分社化されるという大きな組織改編に向け、契約管理システムをはじめとする既存システムで、組織情報などの膨大なデータ修正作業が必須となりました。

データ修正作業は複雑で難易度が高く、過去の経験が必要となったため、特定の熟練担当者に作業が集中。スキル面とリソース面で属人化が深刻な課題になりました。また、このデータ修正作業に限らず、IT部門内ではリソース不足を補うために、主担当・副担当という形での複数人体制で各作業にあたっていましたが、結局どの担当者も他の業務を兼務していたことからリソース不足は解消されませんでした。

また、データ修正に関連するシステムに対し漏れなく検証作業を行わなければなりませんが、今回のような大規模な組織改編では、リソースと時間に限りがあります。結果として十分な検証ができないまま本番に移行し、データ修正不備に起因した障害件数が増加してしまいました。

J-POWERビジネスサービス様では、このままの状態が続くと現行水準のサービスを提供できなくなることを危惧し、保守・開発プロセスの見直しに着手することになりました。

J-POWERビジネスサービス様では、次の３つの理由によりプロセスの見直しが必要だという結論になりました。

●リソース不足。しかし増員するだけだとかえって負担が増える

人を増員すると教育が必要となり、一人前になるまでに時間がかかるだけでなく、教える側も時間と手間をかけることになる。

＜ここでの結論＞

まずはプロセスを見直し、簡素化し、教育の手間を軽減させたい。

●「今までこうしていた」は迷惑

これまでの慣習通りに作業を継続すると、実際には無駄な作業を行っていることに気づかない。また、作業の必要性に疑問があると作業者の意欲が低下し効率が落ちる。

＜ここでの結論＞

惰性で行っている無駄な作業は排除したい。

●属人化による弊害をなくしたい

属人化することで長期の休みが取得しづらい、休んだとしても気が休まらない、担当者が辞めたら引き継ぎが大変な状況になる。

＜ここでの結論＞

誰でもできる作業にすれば教育も簡単になり誰かに任せられる。また、自動化できれば手作業自体がなくなり、余剰時間を別の業務に割り当てることができる。

ワークショップでは、マネージャー、ベテラン SE 、若手SEなど様々な立場の人が参加して開発プロセスに関するVSMを作成したところ、４つの問題点が洗い出されました。

（1）承認プロセス

本来実施すべきタイミングで修正内容のレビューや承認が行われていなかったため、後工程で指摘され、手戻りコストが多くなっていた。

（2）コーディングルール

プログラムの中に現在は不要となった過去のコメントが大量に残存している。それがあるがゆえにプログラムの可読性が落ちる。

（3）開発環境の整備

不具合が発生するので開発環境の整備が必要になっており、この作業が非常に手間になっている。

（4）回帰テスト

修正した箇所はテストしているが、修正箇所以外の影響テストの方に時間がかかっている。

●承認フローの改善

部門内各個人の頭の中にある「こうするべき」をドキュメント化し、現在はフローに従って作業を行っている。

＜効果＞

開発手戻りの原因が参加者の共通認識となった。またやるべきことをやったうえでプロセスの簡素化・自動化が大事であることを認識できた。

●コーディングルールの改善

コメント挿入のルールを再定義し、運用開始した。

＜効果＞

実際にコーディングが読みやすくなり効果を実感している。

●開発環境の整備／回帰テストの改善

繰り返し行う必要のある保守作業の自動化やテスト自動化に向け、アシストから紹介されたいくつかの自動化ツールの検討を行った。

＜効果＞

十分検証を行い、ツール導入を決断し、現在利用中。徐々に効果が出始めている。

●VSMワークショップの横展開

グループ内の関係会社の業務分析にも利用可能だと感じた。今回のワークショップ体験をもとに、現在システムの再開発を検討している中で、業務分析が必要なものについては、各社からメンバーを選抜してVSMワークショップの開催を計画中である。

●属人化排除

属人化の排除という課題に対しては、手順の簡素化が面倒だったり教えるより自分でやってしまったほうが早いという心理的な壁があることに気付いた。このようなマインドを変えていくことこそ大事。

以上が「アジャイル開発スタートアップソリューション」を採用されたJ-POWERビジネスサービス様の感想・効果となります。

「アジャイル開発スタートアップソリューション」というアシストが提供するサービスを通じて、課題の可視化と改善の方向性をまとめるための手法を紹介しました。

繰り返しになりますが、運用・開発業務の現場でDXを推進するためには、システムリプレースやクラウドリフト＆シフトといったようなIT基盤が変化するタイミングでの実践が現実的かつ効果的です。

お客様の変革アプローチはシステムの状況により様々だと思いますが、ASIS（現状）からTOBE（あるべき姿）へ変革していくためには、言われれば当たり前だと思われるかもしれませんが、現状の振り返りと組織合意を愚直にやることに尽きるというのが結論になります。

アシストではこれらのワークショップを通じてお客様の課題を整理しお客様の課題に合わせた提案を行いビジネス成功のパートナーと思っていただけるよう努めていきます。