
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
西田圭嗣氏: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.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
PR | 2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10