弊社の鈴木が2019/6/25に開催された＠IT ソフトウェア品質向上セミナー 2019夏の基調講演として「DX時代に目指すべき品質向上とテスト」という話をしました。

資料は以下にて公開されています。本記事では講演内容のサマリをお伝えします。

リードタイムを早くする

近年のシステム開発では、実装スピードではなく、企画してからリリースするまでのリードタイムが非常に重要になっています。エンタープライズでありがちなシステム開発プロセスにおいてリードタイムが長くなるのは、多くの場合、調整や待ちといったものです。

アジャイルソフトウェア開発

アジャイルソフトウェア開発は

• 先にリソースを確保しておく
• 定期的に計画し、リリースする
• 動くソフトウェアを重視する

といった特徴を持ちます。これは実装の開始と終了タイミングを先に定めてしまい、そのタイミングに企画側が合わせる事によって調整や待ちを無くしていきます。特に複数部門から要件が出るような状況において、先に実装タイミングを定めることによって、以下のようなメリットが生まれます。

• そのタイミングで部門を跨がる優先順位をつけることができる
• 要件が曖昧な場合に、次のリリースに回す交渉がしやすくなる

これは「電車」のようなアプローチです。アジャイルと聞くと、融通が効く「タクシー」をイメージしがちですが、タクシーは調達に時間がかかったり、思った台数が集まらないことがあるため、実際には非効率なのです。電車のように、発車時間までにホームにいる人を対象に、優先順位をつけて満員になるため乗車してもらうことで、安定したリリースを実現することができるのです。

DevOps

次に実装が完了してから、リリースするまでの流れを自動化するのがDevOpsの取組みです。DevOpsとは運用作業の自動化を通じて、開発者がセルフサービスでシステムを運用できるようにすることです。

重要なことは、自動化すべき対象にテストが含まれることです。リリースを自動化するためにはリリース判定そのものを自動化する必要があるのです。CI/CDといった言葉は、開発者がコードをマージしたことをトリガーに、以下のような工程のテストを自動化する取組みです。

• Continues Integration：単体テストや結合テストを自動化する
• Continues Delivery：システムテストや受入テストを自動化する
• Continues Deployment：本番確認テストを自動化する

適用に向けた壁

アジャイルソフトウェア開発やDevOpsを導入できればリードタイムの圧縮が可能です。しかし、そのためには部門を超えて協力し合うことが必要です。

実際、これらの適用にあたって壁になるのは既存プロセス、組織、規則、文化といったようなものです。

• 何をやるか決めないと稟議が通らない
• 部門同士の丸投げ、無関心
• 既存ルールの無意味な遵守
• 自部門の仕事を無くす仕事ができない

もちろん、既存に対する敬意は必要です。しかし、これらに固執するあまり変革をしなければ、リードタイムを短くすることはできません。

地道だっても、これを解決するのに大事なことは部門間の話し合いであり、部門を超えた協力です。そして、全社最適になることを目指さなくてはなりません。

弊社では、話し合いの第一歩として、バリューストリームマッピングのワークショップ開催を推奨しています。企画開始からリリースまでの全てのフローを書き出すことによって、まずはお互いの仕事を理解し、そして、課題に対して部門をこえた協力を行うのです。

さいごに

新しいシステム開発プロセスをリードするのは現場であるべきです。全社を通じて実現すべきことは一緒です。部門を超えた協業によって、これを達成していきましょう。