「できました、あとはよろしく」。作る側にとっての終わりは、動かす側にとっての始まりだった。
状況の3分類＝ordered・complex・chaotic（複雑性思考）。必要最小の手順に＝keep it simple and practical。まず削ってから自動に＝optimize and automate。小さく試す＝progress iteratively with feedback。改善の7ステップ＝continual improvement model。
作るチームと動かすチームのあいだに壁があると、
利用者は、その壁にぶつかります。
作る側も、動かす側も、自分の持ち場の仕事はやりきった。それなのに、公開の初日に困ったのは、取引先と営業さんでした。
経営会議が選んだ4件のひとつが、取引先向けの注文アプリでした。第4話で、FAXの注文が「旧_予備」サーバーでPDFになり、営業所の事務の人が出荷指示を作っている、という流れが見つかりました。アプリを作る前に、リーダーと営業本部の受注の課長は、その流れを1枚の図に描いてみました。手始めに営業所の共有フォルダを開くと、まだ誰も開いていない注文のPDFが、いくつも並んでいました。
この図を描いたことで、アプリで本当に縮めるべきものが分かりました。入力の15分ではありません。3回の待ちです。営業所の事務の人が、FAXが来たことに気づくまで。手が空くまで。工場への指示をまとめて出す時刻まで。
流れの手順と、チーム間の受け渡しと、待ちの時間を図にすることを、ITILはバリューストリーム・マッピング（value stream mapping）と呼びます。ある時点の写真のようなもので、理想の手順書ではなく、今の実際の流れを描くのが基本です。
アプリはベンダーの開発チームが作りました。公開の前の週、開発チームのリーダーが、使い方の説明書を1冊持って情シスに来ました。「できました。あとはよろしくお願いします」
情シスの手元に残ったのは、その1冊だけでした。取引先から「パスワードを忘れた」と言われたらどうするのか。注文が基幹システムに入らなかったら、どこを見ればいいのか。止まったら、誰が直すのか。どこにも書いていない。
公開の初日、取引先からの問い合わせは、情シスではなく、営業所の担当者の携帯にかかってきました。取引先にとって、会社の窓口は「いつもの営業さん」だったからです。外回りの途中で鳴り続ける携帯に、担当者は「確認して、折り返します」と答えるしかありませんでした。
開発チームは、契約どおりにきちんと作りました。情シスも、渡されたものを動かそうとしていた。壁は、どちらかの怠慢でできたものではありません。作ることと動かすことが、別々の契約と、別々の物差しで管理されていたから、自然にできた壁です。
開発チームの物差しは「期限までに仕様どおりに作ったか」。情シスの物差しは「止まらずに動いているか」。取引先が気にしているのは「注文が早く届くか」。3つの物差しのどれにも、壁の上を誰が渡すかが入っていなかった。
リーダーは、図2を課長に見せて言いました。「4つの側面で言うと、穴はパートナーとサプライヤーです。開発チームとの契約に、作ったものを動かす側へ渡すところまでが入っていなかった」
作る側も、動かす側も、契約どおりにやっていました。壁の両側と、問い合わせが落ちてきた営業所。どの席にも子がいます。
子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に
「アプリのことなんて、こっちは何も聞いてないんですよ」
怖いのは取引先に聞かれて初めて、自分の会社が何を出したのかを知ること
「止まったら、誰が直すんですか。説明書のどこにも書いていない」
怖いのは何が作られたのかを知らないまま、公開の日から動かす責任だけを渡されること
「できました。あとはよろしくお願いします」
怖いのは作ったものが、会社のどこにどうつながって動くのか、見えないまま渡すこと
せきのこ ── 席のうしろの、小さな子たち
立て直しの話し合いで、開発チームのリーダーが言いました。「うちは小さな直しを毎週出したいんです。でも情シスさんの変更カードを毎回通していたら、月に1回しか出せない」
第3話と第9話の経験が、ここで生きました。止まったときに痛いもの（基幹システムへの注文の受け渡し）は、変更カードで影響を見てから出す。画面の文言の直しのような小さなものは、自動のテストを通れば毎週出す。リスクの低い決まった変更は、前もって承認しておく。
開発と運用をつなぎ、価値を途切れなく流すための文化とやり方のまとまりを、DevOpsと呼びます。ツールの名前ではありません。中心にあるのは、自動化と、作る側と動かす側が結果の責任を分け合う文化です。ITILが構造と統制を、DevOpsが速さと協力の文化をもたらし、組み合わせると、速さと統制の釣り合いがとれます。
その後、開発チームは、公開した週の問い合わせを情シスと一緒に読む会に出るようになりました。「パスワードを忘れた」が多いと分かると、次の週にはログイン画面に「忘れた方はこちら」を足して出してきた。
このアプリづくりは、始まりと終わりと予算が決まった、一時的な取り組みでした。ITILは、大きな変更や新しいサービスを作るときにはプロジェクトに頼ります。プロジェクトを構造化して進める手法の代表がPRINCE2です。段階を区切り、役割を決めて進め、土台にビジネス正当性の継続、つまり「このプロジェクトを続ける事業上の理由が、今もあるか」を確かめ続ける考え方を置きます。
実際、途中で一度、その確認が効きました。取引先に聞いてみると、4割は家族でやっている小さな惣菜店で、スマートフォンで注文する人がいなかった。全部の取引先をアプリに移す、という最初の計画のままでは、続ける理由が半分になる。計画は「アプリを使える取引先から移し、FAXの流れも残す」に変わりました。
そして公開のあと、アプリはプロジェクトの成果物から動き続けるサービスに変わります。そこから先は、ITILのやり方で運用し、サポートし、改善し続ける。作る期間はPRINCE2、動かし続ける期間はITIL、と役割を分け合います。
アプリの企画書で、営業本部長は「取引先に新しいサービスを出す」と書いていました。リーダーは企画の段階で、この一文に言葉を2つ足していました。
アプリそのもの、注文を受けるサーバー、基幹システムとのつなぎ、それを動かす人。会社の資源を組み合わせて作ったものがプロダクト（product）です。そのプロダクトを通じて取引先に届くのが、「FAXを送らなくても、いつでも注文でき、出荷までが早い」という結果。取引先は、サーバーを買ったり障害に備えたりしなくていい。望む結果を、コストとリスクを自分で抱えずに得られるようにすることがサービス（service）です。
ITIL 5はこの2つを、ひとつの解決策の両面として一緒に管理します。そして「デジタル・プロダクト」「デジタル・サービス」の「デジタル」は、届け方を表しているだけで、プロダクトやサービスの意味そのものは変わりません。
productは、組織の資源（人・技術・情報など）を組み合わせて、価値を届けられるようにしたもの。serviceは、利用者が望む成果を実現できるようにして、価値の共創を可能にするもの。利用者は特定のコストやリスクを自分で抱えなくてよい。「デジタル」は届け方を表すだけで、定義は変わらない。
注文アプリと、それを支える仕組みがプロダクト。「いつでも注文でき、出荷が早い」ことを取引先に届けるのがサービス。
アプリを動かし始めると、もうひとつ見えてきたことがあります。取引先が注文し、工場から出荷される流れ。これは会社の外の利用者に、直接価値を届ける流れです。ITILはこれをコア・バリューストリーム（core value stream）と呼びます。
一方で、アプリの裏では、営業所の担当者にアプリの管理画面のアカウントを用意する、という社内向けの流れも動いていました。社内の受け手に価値を届けて、コアの流れを支える流れ。こちらがイネーブリング・バリューストリーム（enabling value stream）です。第1話から作ってきた共通窓口とカードは、ほとんどがこちら側の流れでした。
どちらの流れも、8つのライフサイクル活動を、その場面に合わせて並べたものです。会社全体に共通する8つの活動の運営の型がバリューチェーン、それを特定の場面のために並べた道筋がバリューストリームです。
最後に、流れの図をどう使い続けるかを決めました。図1は、1回描いて終わりの写真です。そこに責任者（営業本部の受注の課長）と指標（注文から出荷指示まで4時間以内）を置き、毎週追いかけて、待ちを減らし続ける。描くことがマッピング、責任者と指標を置いて改善し続けることがバリューストリーム管理（value stream management）です。
value chainは、価値をつくって届けるための8つの活動からなる運営モデル（組織全体で共通）。活動はライフサイクルの8つ（発見・設計・取得・構築・移行・運用・提供・サポート）と同じ。ITIL 4のバリューチェーンは、計画・改善・エンゲージ・設計と移行・取得/構築・提供とサポートの6つの活動だった。value streamは、それを特定の場面のために並べた一連の手順。coreは外部の利用者に直接届ける流れ、enablingは社内向けでコアを支える流れ。mappingはある時点の流れを図にする技法、managementは責任者と指標を置いて統制し改善し続ける取り組み。
取引先の注文から出荷はコア。営業所の担当者のアカウントを用意するのはイネーブリング。図1を描いたのがマッピング、受注の課長が週次で追うのが管理。
DevOpsは、開発と運用をつなぎ価値を途切れなく流すための文化とやり方のまとまり（ツールではない）。ITILとは補い合い、ITILは構造と統制、DevOpsは速さと文化をもたらす。PRINCE2は構造化されたプロジェクトマネジメントの手法で、一時的な取り組みを管理する。土台はビジネス正当性の継続。続いているサービスを管理するのはITIL。
開発チームと情シスが問い合わせを一緒に読み、小さな直しを毎週出すのがDevOps。期間と予算のあるアプリづくりはPRINCE2、公開後の運用はITIL。
開発チームと情シスは、問い合わせを一緒に読むようになりました。そして、作る途中で確かめたことで、もう1体、誰も見ていなかった子が見つかります。
怖がっていたこと取引先に聞かれて初めて、自分の会社が何を出したのかを知ること
怖がっていたこと何が作られたのかを知らないまま、公開の日から動かす責任だけを渡されること
怖がっていたこと作ったものが、会社のどこにどうつながって動くのか、見えないまま渡すこと
怖がっていたこと店の事情を聞かれないまま、ある日FAXが使えなくなること
作る、確かめる、置く、使えるようにする。注文アプリのしくみは、どれも壁の上に橋をかけるものでした。途中で見つかった4体目の子は、壁の外、会社の外の席にいました。
番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス＝資源のまとまり」と2つのグループまで。
せきのこ ── 席のうしろの、小さな子たち
次の機能を出す前の週、開発チームのリーダーがまた情シスに来ました。今度の第一声は、「できました」ではありませんでした。「戻し方、ここに書いておきました。問い合わせが来たら、まずこの画面を見てください」
「できました、あとはよろしく」は契約どおりの誠実な言葉で、「出すなら、変更カードを通して」も、情シスが第3話で痛い目を見て覚えたことです。どちらも引っ込めずに、取引先の側から1本の流れとしてつなぎ直す。それが、この回の仕事でした。
| プロダクトとサービスproduct / service | 資源を組み合わせて作ったもの／利用者がコストやリスクを抱えずに成果を得られるようにするもの。「デジタル」は届け方 |
| バリューチェーンvalue chain | 8つの活動からなる、組織全体で共通の運営モデル |
| バリューストリームvalue stream | 特定の場面のために8つの活動を並べた、端から端までの道筋 |
| コアとイネーブリングcore / enabling value stream | 外部の利用者へ直接届ける流れ／社内向けでコアを支える流れ |
| マッピングと管理value stream mapping / management | ある時点の流れを図にする技法／責任者と指標を置いて改善し続ける取り組み |
| DevOpsDevOps | 開発と運用をつなぐ文化とやり方。ツールではない。ITILと補い合う |
| PRINCE2PRINCE2 / continued business justification | 一時的なプロジェクトを管理する手法。土台はビジネス正当性の継続 |
もっと詳しく：ITIL 5 解説ガイド（プロダクトとサービスの管理／バリューストリーム／ITILとDevOps／ITILとPRINCE2）
Q1. アプリを作る前に、FAX注文の流れを待ち時間も含めて1枚の図に描いた。公開後は、その流れに受注の課長を責任者として置き、「注文から出荷指示まで4時間以内」を毎週追いかけている。前者と後者は、それぞれ何にあたるか。
A。マッピングは、今の実際の流れを描くある時点の写真。管理は、そこに責任者と指標を置いて、統制し改善し続ける取り組みです。図1で作業25分・全体1.5日と分かったように、マップは待ちとボトルネックを見つけるのに使います。
Q2. アプリづくりは期間と予算を決めて進め、途中で「続ける理由がまだあるか」を確かめて計画を変えた。公開後は情シスが動かし続け、開発チームは小さな直しを毎週出しながら、問い合わせを情シスと一緒に読んでいる。この組み合わせの説明として、もっとも適切なのはどれか。
A。PRINCE2は一時的なプロジェクトを管理する手法で、土台はビジネス正当性の継続。続いているサービスを管理するのはITILです。DevOpsはツールではなく文化とやり方のまとまりで、ITILが構造と統制を、DevOpsが速さと協力の文化をもたらします。