2024.12.24
ビジネスが急速に変化する現代は「OODAサイクル」と親和性が高い 流通卸売業界を取り巻く5つの課題と打開策
リンクをコピー
記事をブックマーク
西田圭嗣氏:2点目は、開発が運用を主導することです。
これはどういうことかというと、我々は、起こり得る問題を先読みをして対処することを意識して開発していました。
(当時)政府はワクチン接種記録システム(VRS)を使って国民の接種状況を管理したいと考えていました。それに基づいて各自治体がVRSに接種状況をどんどん登録していくので、政府がそれを見てワクチンの配分スケジュールを決定していました。
接種の予約はワクチンの配分スケジュールが決まってからでないと予約枠を作れないので、兎にも角にもワクチンを配分してもらうためには、このシステムに記録しなくてはいけない。ワクチンを打ったら、片っ端からそれをシステム上に記録していくオペレーションが必要でした。
ただ、そこで政府が推奨したやり方は、タブレットで接種券を1枚ずつ読み取るというものでした。当然これにはすごく読み取りには時間かかるし、ミスも発生します。我々は接種記録を登録する部分がボトルネックになってしまって、サイクルがうまく回せなくなるのではないかと最初に懸念というか、予期していました。
この問題を見つけた時に、我々は急遽予約システム上に接種履歴の出力機能を追加することで、この問題を解決しようと試みました。
接種履歴を我々の予約システム上で取り扱うというか、「この人は接種済みだよ」ということを管理できるので、それを一括でVRSに互換可能な形式であるCSVで出力して、(そうすると)接種結果一覧がCSVでズラーッと並ぶので、それを最終的にVRSにアップロードすることで、接種状況登録を一括で行って、ボトルネックを解消しました。
この試みで先手を打ったことで、なんとかサイクルが回らないとか、エラーが起こる問題を解決しました。
残念ながら弊社のシステムを使ってこなかった自治体さんは、けっこうこの問題に苦労したみたいです。というところで、端的にやっておいてよかったなと思っているところです。
最後に、コミュニケーションの基盤を整えることを言いたいと思います。
開発の現場において、往々にして起きる問題ですよね。仕様に関するコミュニケーションの齟齬というか、仕様策定をする時に十分に時間が取れなくて、運用者と開発者の間で情報を十分に共有できない。そういうことが開発の現場では多々起こっています。
例えば、ワクチンだったら、1回目の接種した人が2回目の接種を受けられる。接種後はその予約ができる仕様でないといけません。
この仕様策定やコミュニケーションを怠ると、開発側が「ワクチンを予約時刻に接種するということは、その予約時刻を過ぎたらもう全員接種したってことにしちゃえばいいんだな」と勝手に思い込んでしまい、その後その時刻が過ぎた人はすべて予約が取れるようになってしまいます。
そうすると、予約だけをして接種会場に来なかった人も2回目の予約が取れるので、「どうなっているんだ」とお叱りを受けることになります。ただ一方、開発側は、「そんなケースがあるなんて聞いていない」ということで、コミュニケーションの齟齬が起きて失敗してしまいます。
当然こんな問題は起きないので、これはすごく陳腐な例ですが、このバリエーションというか、多かれ少なかれこのようなケースが実は開発の現場では起きているのではないかなと思っています。
我々がそれに対してどういう対処の仕方をしたかというと、とにかく最も重要なのは運用者と開発者の間で、用語を正しく定義することだと感じています。
(スライドを示して)例えば、1回目の摂取済みに対しては対象のユーザーがいて、そのユーザーに紐づく予約が1つであること。それから、予約時刻より現在時刻のほうが後であること。それに加えて、接種状況という人為的にいじるパタメータを作って、それを接種をしたら物理的に書き換えることによって接種済みになること。
この3つの条件です。この3つの条件が満たされた時に、ユーザーのステータスは1回目接種済みになると定義をして、それを開発と運用の間でしっかりと合意しておくことを心がけています。
例えば、ワークフローは運用側が主導権を持つもので、ビジネスロジックは開発側が主導権を持つものですが、スライドのような流れにすることで開発の中でのロジックやフローを、齟齬のないかたちで接続できます。それが非常に大きな利点です。
それがどういうふうに活きるか、ワクチンの事例でいうと、ワクチン(予約システム)はもう1年以上続いていて、長期運用をしているので、それに耐えられるシステムになっていなければいけません。
例えば、初期の段階ではファイザーとモデルナという2種類のワクチンしかありませんでした。
時を経てアストラゼネカが追加され、さらに時を経て、どのワクチンでもOKですが、3回目の接種のプロセスが追加されました。
運用の中でワークフローが追加あるいは変更されたとしても、きちんと「これは何か」という定義にさかのぼってデータと照らし合わせることで、そこに処理上論理的な矛盾がないかどうかを検証できます。
この検証を経ることによってシステムの安全な拡張が可能で、テストの設計や、さらにいえば自動化もしやすく、必要なテストケースも少なくて済むという利点が生まれます。
我々は運用の全容を把握するとか、開発の運用を主導するとか、コミュニケーションの基盤を整えるということをやってきましたが、このおかげで問題を起こしたりとか、接種計画を妨げることなくここまでこられているのではないかと思っています。
今あらためて振り返ってみると、日本のワクチン接種は初動は遅かったのですが、比較的安定的な早い接種で、10月には世界のトップに立っていたので、すごくよかったのではないかなと思っています。
これに対して予約システムがそれほど貢献したとは思わないというか、どれほど貢献したのかはわかりませんが、それでもこれは我々と日本国にとって1つの成功体験で、誇れる出来事だったのではないのかなと思っています。
NHK「世界のワクチン接種状況」,ワクチン接種が完了した人(割合)
「ワクチン予約システムを国が開発すれば、もっと効率的だったんじゃないの?」という意見をもらいます。ワクチンではありませんが、デジタル庁が発足して、国のシステムを一括で管理をしていくようなことを国主導でやろうとしています。
しかし、日本はけっこう大きな問題を抱えています。それは何かというと、多重下請け構造という問題です。元請けから二次請け、二次請けから三次請けというように一方通行で流れていく構造と、それからその間には壁があって、開発からは顧客のことが何もわからないということです。
そういう状況がある限り、このコロナワクチンのような、機動性を求められるプロジェクトは難しかったのではないのかなと僕の観点からは思っています。
(スライドを示して)それに対して、我々が提唱したいことはアンチテーゼです。多重下請けの構造の分断に甘んじず、運用と密に連携を取って、開発が運用を理解するとか開発が運用を主導するとか、コミュニケーションの基盤を整えるとか。そういうことをしっかり実践して、長期の運用にも耐えるシステムを開発することを目指しています。
これによって多重下請け構造の問題を克服して、日本のIT業界を変革していきたいと考えています。
(スライドを示して)これは最後のスライドです。冒頭になぜかスイスの話を始めて、「swiss made」というものがあるという話をしましたが、我々日本には、「MADE IN JAPAN」という表記があります。
30年という長い停滞の中で我々はもの作りに関する誇りを失いつつあるんじゃないかと、失ってしまったんじゃないかと。そういうふうに感じることも多々あります。
これには先ほど示したような構造的な問題がけっこう大きな要因になっていると考えていて、弊社はこの問題を解決したいと思っています。
事実、我々の手法によって、荒波に揉まれたワクチンの接種プロジェクトはある程度うまくいったわけです、なので、我々はこれから成功体験を積み重ねていって、日本がIT大国として、「MADE IN JAPAN」を誇れるようにしていきたいと考えています。以上で今回の話は終わります。
最後にちょっと話せといわれたので話します。(スライドを示して)弊社では今、プロジェクトマネージャーを絶賛募集しています。
先ほど「MADE IN JAPANを盛り上げていくんだ」という話をしたのですが、まさにデジタル庁がこれからやろうとしているような、行政向けのシステムにも我々が足を突っ込んでいきたいと考えています。
デジタル庁がガバメント・クラウド・プロジェクトをやろうとしています。自治体のIT基盤も一新するというプロジェクトなので、それを我々も一翼を担っていきたいと考えています。
ワクチン予約システムのようなスケジュールのハードなプロジェクトにはしたくないですし、我々も生活が重要ですし、健康も重要です。当然リーズナブルに進めていきますが、ガバメントクラウドみたいな自治体向けのプロジェクトをやることが、我々のその次の日本のITシステムを作るうえでとても重要だと思っています。
もしこういうものに興味がある方がいれば、ぜひお声がけください。きっとこの求人情報はどこかに貼られると思うので、ぜひそこから探して応募というか、お食事でもいいので声をかけてもらえれば幸いです。
以上です。みなさん、ご清聴どうもありがとうございました。
関連タグ:
2025.01.16
社内プレゼンは時間のムダ パワポ資料のプロが重視する、「ペライチ資料」で意見を通すこと
2025.01.20
組織で評価されない「自分でやったほうが早い病」の人 マネジメント層に求められる「部下を動かす力」の鍛え方
2025.01.21
言われたことしかやらないタイプの6つの言動 メンバーが自主的に動き出すリーダーのマインドセット
2025.01.15
若手がごろごろ辞める会社で「給料を5万円アップ」するも効果なし… 従業員のモチベーションを上げるために必要なことは何か
2025.01.14
目標がなく悩む若手、育成を放棄する管理職… 社員をやる気にさせる「等級制度」を作るための第一歩
2025.01.21
今までの1on1は「上司のための時間」になりがちだった “ただの面談”で終わらせない、部下との対話を深めるポイント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.01.14
コンサルが「理由は3つあります」と前置きする理由 マッキンゼー流、プレゼンの質を向上させる具体的Tips
2025.01.22
部下に言いづらいことを伝える時のリーダーの心得 お願いを快く引き受けてもらう秘訣
2025.01.09
マッキンゼーのマネージャーが「資料を作る前」に準備する すべてのアウトプットを支える論理的なフレームワーク
コミュニケーション能力の高い人が“無自覚”にやっている話し方 5選
2022.08.07 - 2022.08.07
チームの生産性を上げるマネジメント術
2024.12.11 - 2024.12.11
特別対談「伝える×伝える」 ~1on1で伝えること、伝わること~
2024.12.16 - 2024.12.16
安野たかひろ氏・AIプロジェクト「デジタル民主主義2030」立ち上げ会見
2025.01.16 - 2025.01.16
国際コーチング連盟認定のプロフェッショナルコーチ”あべき光司”先生新刊『リーダーのためのコーチングがイチからわかる本』発売記念【オンラインイベント】
2024.12.09 - 2024.12.09