宮坂さんのTweetを拝見し、僕もここ数年DXだとかFintechだとかよくわからない業界でもがいてきて少し見えてきたことがあるので言語化してみたい。
おさらい。IT調達の呪縛とは
まずはじめに、この国の遅れたIT化や、いけてない（ようにみえる）システムがなぜ起きているか、その原因の多くが、システム開発を「モノの調達」と同じフローに載せていることである。
たとえば、コピー機を100台、カラーレーザー複合機で冊子綴じ機能付きで導入する場合、1台100万円で1億円ではあるものの、そんなに失敗したとかいう声は聞こえてこない。このような既製品を調達するノリでITに関しても発注が行われ、失敗を繰り返していることをIT調達の呪縛と呼ぶ。
ではなぜ、ITシステムは調達ではいけないのか。それは（海外を含む）民間事業者の努力により、市民は、スマホをはじめとしたデジタル機器をカンタンに使いこなすことが日常となっているからだ。
考えても見てほしい、日常的にガスコンロやIHでお湯を沸かす人たちに対して、少々不便ですがお湯は温まりますので・・・とチャッカマンと薪木を渡して許されるだろうか。各家庭がまだかまどで、マッチしかなかった時代にチャッカマンを配れば「よくやった」と褒められるかもしれないが、いまではキャンプに行けばいいのですか？となってしまう。
使う人の方が求めるレベルが上がっている
適切なたとえだったかはわからないが、言いたいことはこれだ。UXピラミッドなどと呼ばれるが、使う人たちがいるシステムはおおむねこのような段階を経て満たされる。
- レベル１：【存在する】いままでWebで出来なかったのが、私のPCでできる！私のスマホでできる！
- レベル２：【信頼できる】Webでできるのは当たり前になったけど、セキュリティにも配慮されて、ちゃんと広報されてて信頼できる！
- レベル３：【使いやすい】いままでは結構説明読んだり、事前準備が大変だったけど、1分でできちゃった！
- レベル４：【感動・やりがい】このシステムを使っていると社会に参画してる実感が持てる。もっと自分の地域に貢献したい
ここで問題が起きる、レベル２までは、おおむね事前に予測がつくが、レベル３はベストプラクティスを知っている人も少なければ、関係者間でも感性的に意見が分かれる。民間のマーケ系制作でも偉い人が気に入らないとか言ってちゃぶ台返しされるアレだ。
そして、この事前予測が難しい事と、合格かどうかに感性的な要素が加わるのが、合議的な意思決定組織、あるいは受発注の関係で成果物責任を問われる場合に致命的に相性が悪いのだ。
あわせて、お役所的には広く市民にサービスを提供する観点から古いブラウザや視聴覚が不自由な方向け対応など、さらに難易度が高まることは付加しておく。
アジャイルにすれば解決する問題ではない
役所に関わらず、このような組織のトップや管理職の方は、課題意識はちゃんと持っている。なんとかならんのか。と。うちもアジャイル開発とやらを導入すればいいのではないかと。
そして残念ながら解決しない。１スプリント１か月もかかるようなアジャイルという名のフェーズ分けしただけのウォーターフォールが出来上がって終わる。アジャイルが問題なのではない、アジャイル開発はあくまで開発手法であって、予算取りや事業企画、コンプラチェックや既存の基幹システムを保守してるベンダーの折衝はスコープ外なので。そして大きな組織、硬い組織というのはこの開発以外のボリュームの方がでかいのだ。それらから目をそらし開発だけアジャイルにしても退職者を増やすだけである。
ではどのようにすればいいのか（提言）
ここでもうお役所のシステムは内製化しようなどというのは暴論である。100人のエンジニア組織をつくって、そのメンバーにお役所の業務知識を学んでもらうのに何年かかるのか。この高騰した相場でいくらかかるのか。完成する前に責任者が入れ替わってしまってぽしゃるのは目に見えている。
大切なのは、既存のフローやルールの枠組みの中でまずは何とかしてQuick Winを作ることである。そのためには以下の方式を提案したい。
予算に含める内容を工夫する
まず予算取りからだ。予算を取るステップをたとえば以下の4つに分類する。
調査フェーズ
これはいくつかあるが、簡単にいうと業者に対する入札仕様提示を精緻にするための調査予算だ。内容としては、既存システムとの連携や影響度調査（既存システムの改修が走るのかどうかとか）、業務フロー調査、法務・コンプラ調査、技術調査（先日のiOSでのNFC開放など新技術の場合）そしてUX調査をここに加えるのだ。
開発フローの中でUXの改善を行うのはまずあきらめる。パワポで作る代りに、紙芝居のHTMLをRFP用ドキュメントとして作成するのだ。
これは宮崎県が取り入れた手法だ。中の職員がイケてる。
togetter.com
つまり、従来は「機能を満たすための付属品であった委託内容に含まれる画面設計」から「使いやすさの仮説を検証するためのUX調査および成果物としてのモックUI紙芝居RFP」にスライドさせる。できればここは民間からの出向を受け入れたりして内製できると好ましい。既存の業務フローとのすり合わせや、過去に飛んできたクレームなど、中の人しか経験していない暗黙知がたくさんあるからだ。
開発フロー
開発は今まで通りウォーターフォールで行うが、APIの提供を義務付ける。政府CIOが公開しているAPIガイドラインに沿って、すべての読み書きをAPIで出来る事を義務付けるのだ。それにより、サーバ側とフロント側の開発ベンダーを分ける事ができ、ベンダーの得意分野を生かすことができる。
標準ガイドライン群 | 政府CIOポータル
そしてここにきて、先ほどのRFPにおけるUIモックが生かされるのである。UIモックを実現するためにどのようなAPIが必要かサーバベンダーも見積もることができるので齟齬が少ない。
なお、SPAでアクセシビリティ高くサイトを構築できるベンダーが見つからないことも予見されるので、その場合は超絶シンプルなLiteバージョン、NintendoDSやガラケーでも動くバージョンを簡易版として納品要件に入れるとよいだろう。全員に同じ体験を提供する必要はなく、プログレッシブエンハンスメントを行えばよいのである。かつ、そのシステムがあるとデバッグの効率もよくなるだろう。
保守運用フロー
保守と運用を分けたが、単に予算計上の仕分け科目が異なるから、くらいの意味合いだ。
大切なのは運用フローにおいて、フロント側のみ改修を行うのである。これもウォーターフォールで構わない。運用予算というのは月額決まった範囲で運営されるので、要件定義から開発までを2週間で行い、各種内部審査・テストを受けて3週間目に公開される、このフローを実現できれば月2回改善できることになる。まるで2週間スプリントだ。
市民の声を受けて改善するのに、アジャイル開発でなければいけないわけではない。従前のモノリシックなシステムでは、責任分界点があいまいなので一つの改修に何週間もかかって莫大なコストを負担する必要があるのが問題なのだ。
ちょっとした文言の工夫、ちょっとしたJavaScriptでのアシスト。それで足りるカイゼンは山ほどあるし、それで足りない範囲は2次フェーズとして改めてプロジェクト化すればよいのである。
本当の脱却はこれからだ
これらは、既存の予算調達やいろいろなしがらみをエスパーしながら書いたものだ。導入に当たっての最初の第一歩は、とにかくUX調査フェーズをシステム的な実現性調査フェーズに入れ込むこと、API提供によるフロントとバックの分離だと思う。
しかし、これらが実現した暁には、真にシステム化された組織（職員の多くがデータ分析ツールを使いこなし、なんならNoCodeでさっと市民向けのプロダクトを提供する）にむけた、既存の仕組みを改革するためのノウハウが組織の中にたまっていくのではないかと思う。
追記：ぶっちゃけた話これを変えるだけでも相当な組織変革が必要
ブコメ見て根本的なことを書いていなかったのを思い出した。硬直した組織で、山のように規定された行動様式があって、縦割りによる弊害もあってがんじがらめになってる現場では、この程度の変化さえ受け入れが難しいと思っている。
このようなIT改革は別にITに限ったことではなく、組織改革であり業務フロー改革なので、いちメンバーやましてや、そこから発注を受けているSIerさんでは無理な話だ。
変革リーダーをたて、トップが多少の失敗をものともせず強く後押しし、まずは既存のルール内で解釈の幅、各部門長に根回しネゴしたうえで、各部門の裁量で何とか許せる範囲で新しいことを試す。Quick Winを作るというのが定石だ。
そして、多少の犠牲をはらいつつ、刺したり刺されたりしながら成し遂げるのがDXとか言うんじゃなかったでしたっけ。
