国づくりって、システム開発と似てるよね？ - バランス至上主義、そんな感じ。

今日、仕事でシステム開発の要求定義について調べていて、家に帰ってきてからふと思ったこと。
"国づくりって、システム開発に似ているなー"
ということについて。

システム開発については、知ってる人は知ってるけどとても難しいんです。
何で難しいかっていうと、物体として形のないものを作るからというところが大きいんじゃないかな。
(参考)
id:LukeSilvia さんが、Rubyという言語の作者のまつもとゆきひろさんのセミナー内容をまとめてくれたエントリー
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary

カタチがある製品（例えば単純すぎだけど財布とか?）は、これで行こう！と生産を決める前に、実際のモノを手にとって見れるのであまり間違いがないじゃない。
でもシステムって、カタチがないうえに挙動がそれはもう幾通りもあって、見る人の感じ方もその人の数だけあるってものなので、こう思ってたのに!(違うじゃん!)ということが多発するという、それは発注側にも製作側にも苦労が多いものなんですよ。

今では、システム開発の各フェーズにおける方法論なんかも、みんなが苦労して、失敗して、考えた結果それなりに体系だてられたものがあるけど（でもこれが正解!という方式はなくて、いくつかの方法論がある状態だけど）、前はそうじゃなかったんだよね。

過去の話はさておき。
何で国づくりがシステム開発に似ているかっていうと、国(=政治)における意思決定の部分がシステム開発での要求定義に似ているなーと思ったのです。

どう似ているかもうちょっと説明すると、ソフトウェアの開発では下のように業務が進んでいきます。

ビジネス検討: 「何したいよね」って漠然と思ったのを→やるぞ！にするとこ
要求定義: 「こんなのしたいんだけど」ってところを作るとこ　※ここの部分
要件定義: 「今回の開発では最終的にこうならないととダメだよ」と決めるとこ
システム設計: んじゃ、こんな機能/操作性/運用ができないとダメだね。こう作るよ！
システム開発: 作りますよー。できましたよー。
テスト: うん、大丈夫ですねー。
テスト運用: 使えるかな？いけるかな？
実運用(保守運用): 常に使える状態に保ちますよー。

この2.要求定義というのがくせ者で、発注側と開発側の境界があいまいなんです。

開発者側からすると、
「作りたいものは自分たちに聞かれてもわかんないよ。だって、自分たちが作りたいわけじゃないし。。お金を出してでも(システムを)作りたいって思ってるんだから、作りたいものはそっちが持ってるんでしょ？」
という感じ。

で、発注者側からすると
「自分たちの仕事は分かるけど、システムで出来る／出来ないとか、どれぐらい難しいとか、どこら辺までやったら(割りに合わないほど)お金がかかるとかって分かるわけないじゃん。だっておたくらがコンピュータの専門屋さんでしょ？」
という理論です。

両方の言い分が合ってるので、この思いをお互いが譲らないままシステムが出来あがっちゃうと出来あがったシステムが「なんじゃこりゃ！」になるわけですね。さらに難しいのが、エンドユーザー自身が実際に出来上がってみないとその良し悪しを判断できないというところ。

でも、その要求定義も「工学」化が進んでいるらしいです。
(参考)

うまく行くためには

エンドユーザーが自分がしたいことをよく理解していない
エンドユーザーの中でも、立ち位置によって希望や要求が違う
その状況になってみないと本当にいいかどうか分からない

などの点を、工学を用いて解決しようという試み。

システム開発のプロセス化が進んでいるのは、

開発時と、それから先の運用において
お金を出す人が最大限の費用対効果(効率、満足度)を求めて、
依頼を受けた側もそれにコミットしたい

という、「結局みんなが満足するには」の視点で見ているからじゃないかなと。

これを国に当てはめてみると、

制度や仕組みの決定時と、それから先の運用において
国民が最大限の費用対効果(効率、満足度)を求めて、
国会議員や全ての公務員もそれにコミットしたい

ということかなと。

要求定義について、自分もそうだよなーと思うのは
「要求はオーナーの意見も大事。現場の意見も大事。でも発注者だけがまとめられるものでもないし、開発者の判断も大事。3者が一番よいと思うものを手探りで導き出すことが大切。」みたいなやつ。要求はユーザーの意思決定者と、ユーザーの実務担当者と、開発者が同じコタツに付いて(ひざを突き合わせて)一番いいと思う結果を出す方がいいという"コタツモデル"とか、
開発者の視点での開発（機能重視の開発）だけじゃだめで、エンドユーザーがどう感じるか、どう思うかを判断基準に置いたユーザー中心という開発の考えかたなどが正解に近いのかなと。

これも国に例えてみると、
「制度は国民の意見も大事。行政の意見も大事。でも国民だけがまとめられるものでもないし、国や行政の判断も大事。3者が一番よいと思うものを手探りで導き出すことが大切。国(立法)の視点での制度化だけじゃだめで、国民がどう感じるか、どう思うかを判断基準に置いた国民中心という政治の考え方」
みたいになります。

うーん、どれもいい感じ。(笑)

個人的にこうなればうまくいくよなと思うパターンは、こんな感じです。

発注側が乗り気。(うまくいく方向に協力しますよ！みたいな姿勢)
受注側の開発者レベルが高い
- 最小の工数で最大の効果となるように常に考えて実践
- 勉強し続けていて、常によりよい方法をためす
責任を押し付けあわない
- お互いプラス思考
- もし問題が起こっても、問題自体を悪として両者協力して解決する

のような感じ。

これも国に例えてみると、

国民が乗り気。(うまくいく方向に協力しますよ！みたいな姿勢)
国会議員の能力が高い
- 最小の税金で最大の効果となるように常に考えて実践
- 勉強し続けていて、常によりよい方法をためす
責任を押し付けあわない
- お互いプラス思考
- もし問題が起こっても、問題自体を悪として両者協力して解決する

みたいな。
こうなるように(というかこう"したくなる"ように)、制度を作ればいいと思うわけですよ。

そのほかにも、

開発者⇒国
運用者⇒行政
ユーザー⇒国民

に当てはめてみたり、

システムは「作ったら終わり」じゃなくて継続的な見直しや改善が必要だったり
アジャイルな開発がいいものを作るのに向いてたり
運用しているものでもコストに合わないなら(一部の利用者には代替手段を残しつつ)システムを廃止するなどのリストラが必要だったりと

ほぼ置き換えが可能で、ベストプラクティスが積み上げられているんじゃないのかなーと思いました。

という事で、「開発の各プロセスにおいて手法が洗練されてくると、国づくりもうまくいくようになるんじゃないかなぁ」という結論。

ただ一つ(かつ一番重要な)違う点は、経営の判断基準は利益だけど、国の判断基準をどこに置くかというところ。これが定まってないと、開発者の立場としてはうまくいくわけないなーと思ってみたり。

そんな感じー。