製造業の管理手法「バリューストリーム」をIT部門に援用──GitLabが語る、DevOps導入の要諦

依然として低い、日本企業による「DevOps」の普及率

　GitLabは2014年に米国で設立され、DevOpsに係る製品やサービスの開発・提供を手掛けている企業。世界のDevOpsリポジトリ製品市場において70％のシェアを持ち、米ガートナーの「Magic Quadrant」でも、DevOps Platforms分野のリーダーに位置付けられている。

　同社の日本法人は2020年に設立されており、パートナー企業を通じてDevOpsソリューションを展開する。同社でエリアセールスマネジャーを務める村上氏によれば、米国に一足遅れて日本でもDevOpsの重要性に関する認識が徐々に高まってきているという。

　「IPAが発行した『DX白書2023』では、DX実現のために必要な要素技術としてITシステムのニーズを素早く具体化するための『デザイン思考』、素早くシステムを開発するための『アジャイル開発』と並んで、システムを素早く安全にリリースするための『DevOps』が挙げられています」

　DevOpsは、CI/CDなどの活用によるシステムリリース頻度の向上、セキュリティスキャンやシフトレフト（不具合の早期発見）による品質の維持・向上、そしてリリース後のシステム利用状況のモニタリングやユーザーフィードバックなどを通じた市場ニーズの吸い上げといった各種の活動を通じて、システムを素早くかつ安全にリリースするための一連の取り組みを指す。

　既に米国では、多くの企業がDevOpsに積極的に取り組んでいる一方、日本企業による取り組みは遅れているのが実情だと村上氏は指摘する。

　「『DX白書2023』によれば、企業におけるクラウドインフラの活用度合いを調査した結果、日米で極端に大きな差は見られなかったものの、DevOpsやアジャイル開発、デザイン思考といった開発プロセス・組織のモダナイズに係る取り組みについては、米国企業に大きく水をあけられています」

　また、日本のみならず世界的に見ても、ITシステムのライフサイクル全般において「付加価値を生まない作業時間」や「待ち時間」が多く発生している。そのため、これらを削減して「付加価値を生む作業」により多くの時間を費やすことができれば、DXをより加速できるとも言う。

製造業におけるプロセス改善活動の知見を援用「バリューストリームアセスメント」

　では、具体的にどうすれば無駄な作業時間を減らし、システムの開発・リリースのプロセスを最適化できるのか。ここでよく利用されるものが、製造業のプロセス改善活動で長らく用いられてきた「バリューストリームマッピング（VSM）」の手法だ。これは製造業の世界でよく知られる生産管理手法「トヨタ生産方式」「リーン生産方式」などで用いられてきた管理手法。ここで言う「バリューストリーム」とは、その名の通り製品やサービスなどの価値を顧客に提供するための一連の“仕事の流れ”を指す。

　このバリューストリームは通常、複数の作業ステップによって構成されており、バリューストリームマッピングではこれら個々のステップのどこにボトルネックが潜んでいるかを洗い出し、解消することによってバリューストリーム全体の最適化を図る。GitLabでは、この管理手法をITシステムの開発・リリースのプロセスに適用した「バリューストリームアセスメント」という独自のメソッドを提唱しており、その実現を支援するための製品・サービスを提供している。

　具体的には、ITシステム開発プロジェクトのバリューストリームを構成する個々の作業を「プロセス」として定義するところから始まる。どのようなプロセスが存在し、互いにどのような関係にあるのかを整理・可視化するためだ。バリューストリームを可視化できたら、個々のプロセスにおけるリードタイム（プロセスの開始から次のプロセスに移るまでに要した時間）と実行時間（実際に作業している時間）、そして正確性の割合（プロセスが手戻りなく進む割合）をそれぞれ算出して定量化する。

　「こうしてバリューストリームの現状を可視化する『バリューストリームマップ』を作成できたら、その内容を基にボトルネックを抽出し、それを解消するための施策を検討します。具体的には目指すべき理想のプロセス（To-Be）や実現可能なプロセス（Can-Be）を定義したり、部門間のコラボレーションをスムーズに進めるためのKPIを設定したりと、検討を重ねてお客様に提言します」

実践企業にも悩み、DevOpsツールが散在する現状も

　こうしたプロセス改善活動に長く取り組んでいる企業も多く、既に成果を上げている例もあるだろう。しかし、その過程でいくつかの課題に直面し、思っていたような成果を上げられていないケースも少なくないと村上氏は語る。

　「DevOpsを支援するためのITツール、たとえばチケット管理ツールやソースコード管理ツール、CIツール、CDツール、セキュリティスキャンツールなどを個別に導入し、これらを組織や部門ごと独自にインテグレーションして運用しているケースが多く見受けられます。このようなアプローチは当たり前のように行われていたのですが、いくつかの点で問題があります」

　たとえば、DevOpsは前述した通り、開発プロセスのバリューストリームについて共通のKPIで可視化・定量化して課題を抽出しながら、継続的にプロセスを改善していく取り組みである。つまり、個々の活動を可視化・定量化するツールがバラバラだとKPIもバラつき、共通指標の下でプロセスを客観的に評価することが難しくなってしまう。

　また、バリューストリームを最適化するためには、部門の垣根を超えたコラボレーションも必要になる。これをスムーズに行うためには部門間で同じKPIを共有し、客観的な指標を基に議論を交わせる土台が必要だ。ツールとKPIがバラバラな状態では、部門間のコラボレーションも円滑に進まない。

　さらに作業の受け渡しにおいても、各工程のツールやKPIが異なっていると工程をまたいだプロセス最適化がうまく進まなかったり、最悪の場合はデータの不一致によって品質に大きな支障が出たりする可能性もある。

　こうした課題を解決するためには、工程や部門ごとにDevOpsツールをバラバラに導入・運用するのではなく、プロセス全体にわたって共通のデータとインタフェースを共有できる「DevOpsツールのプラットフォーム化」を指向する必要があると村上氏。

　現在多くの企業が同様の課題意識を共有しており、米ガートナーが2022年に行った調査によると「ツールチェーンの統合を望んでいる組織の割合」は69％、「DevOpsプラットフォームを使用している、または今年使用する予定である」と答えた企業は75％、そして「2024年までに、複数のポイントソリューションからバリューストリームデリバリープラットフォームに切り替える」と答えた企業は60％にも上っているという。

単一の「DevOpsプラットフォーム」による一元管理、その効力とは

　DevOpsプラットフォームを導入することで得られる具体的な効果について、村上氏は次のように説明する。

　「これまではプロジェクトの進捗会議やレビュー会などを開催するたびに、進捗や品質などに関する情報、たとえば設計資料やソースコード、テスト結果、メール、チャットツールで交わされた議論などを各ツールから人手でかき集める必要がありました。しかし、DevOpsプラットフォームを導入すれば、プロジェクトに関連するあらゆる情報が1ヵ所に集約されるだけでなく互いに関連づけて管理されているため、必要な情報を即座に参照することができます」

　人手で資料や情報を集め、整理するような「付加価値を生まない作業時間」を減らした分だけ「付加価値を生む作業時間」を増やすことにより、システムのリリース頻度や品質を上げていくための活動により専念できるようになるだろう。GitLabでは、まさにこれを実現するためのDevOpsプラットフォーム製品を開発・提供しており、単一プラットフォーム上でDevOpsに必要とされるあらゆる機能をカバーできると村上氏は自信をみせる。

　たとえば、プロジェクト内に新機能の実装に関するスケジュールを策定し、そこからタスクを分割し定義していくことで、実際のソースコードの変更を行うマージリクエストを作成でき、変更に対するレビューや議論、自動テスト結果、新規脆弱性の作り込み有無などが自動的にまとめられて管理される。分割したタスクの完了具合によって策定したスケジュールに対する進捗も自動で算出されるという。

　また、各プロジェクトメンバーの役割に最適化されたインタフェースが標準で備わっている点も特長の一つだ。たとえば、開発者には今どのメンバーがどのタスクに取り組んでいてどのような状況なのかを把握できる“カンバン”などの画面が提供される一方で、プロジェクトマネジャーにはプロジェクト全体の進捗状況を一目で把握できる画面が用意されている。他にも生産管理部門には各プロセスで要した作業時間を把握するためのダッシュボードが提供されるという。

　最後に村上氏は、「GitLabでは、こうしたDevOpsプラットフォームの機能をさらに使いやすくするためにAIの導入を進めています。具体的には、AIを使ってコードやCIパイプラインを自動生成したり、セキュリティスキャンで発見された脆弱性をAIで自動修復したりする機能実装を考えています。今後も日本企業のDXをDevOpsの側面から支援すべく、製品の改善を続けていきます」と展望を述べて締めくくった。