Knowledge base func

日本の大手SIerが建てた砂上の楼閣が崩れたというニュースが入ってきた。調査報告書がUPされたので読んだ。
そこには”設計要員”が450人動員されたと書かれいた。
あぁ、なんだファンタジー小説じゃないか！

費やした５５億円、水の泡に　特許庁がシステム開発中断

www.asahi.com/business/update/0124/TKY201201240616.html

特許庁は２４日、２００６年から始めた新たな情報システムの開発を中断することを決めた。これまでに５５億円の予算を投じたが、別のシステムを考える。
　新システムの開発期間は０６年１２月から１４年１月。設計を東芝ソリューションと、開発管理をアクセンチュアと契約した。
開発の遅れは、主に設計の不備が原因。特許庁は検証委員会を設け対応を考えてきたが、委員会は２３日、中断を求める報告書をまとめた。業者が今までに作ってきた設計情報は、特許庁の別のシステム開発に生かしていくという。

せっかくなので、Getting RealとFantasy SIerを題材に学んでみようと思う。
Getting Realは長すぎる。意訳をつくってみたけど長すぎるんだよね。
超訳だよ。

**日本のファントム vs Gettign Real
まるで大きな政府か小さな政府かの争いのようだ。
Gettign Realと特許庁の今回頓挫したシステムとの大きな違いの部分に注目して、書きだしてみようと思う。

１．機能はとことんまで削れ
他方、特許庁のシステムは「何でもかんでも」にしたようだ。当初６０Mステップの開発規模を予定していたそうだ。Gettign Realは７行のコードより４行のコードを美徳とする。７行を４行にするためには才能と努力が必要だ。三流プログラマが書いた１万行のコードは練度の高いプログラマの２００行に性能でも敵わないことがある。当然２００行のほうが保守性も拡張性も高い。
ステップ数でプログラムを評価すると、性能も低く拡張性も保守性もないプログラムを評価してしまうことになる。

２．チームは３人いれば十分
他方、特許庁のシステムは上流工程を重視し設計要員を450人体制とした。上流工程って（笑）
37signalが提案する３人のチームの中には当然設計だけしかできない要員は含まれない。そもそも設計だけの要員を想定していないのだろう。日本の現場をおもいうかべると、そもそも論理的に実装ができない設計がなされている様が目に浮かぶ。こんなの作れないだろと。実装もできない要員が設計をするケースがあるからだ。これは問題外だ。まず形にしないといけないのに形にできないひとがイニシアチブをもってはいけない。そのひと一人に任せて仕事がすすまないひとに仕事をまかせてはいけない。
仕事がメモとミーティングに埋まってしまぬよう独立して動ける規模までチームを小さくすることが必要だったのではないか。責任を分散するためだけに実質責任をとらない増員はじつに日本的。

３．皆を喜ばせようとすると、誰も喜ばない
誰のためのシステムだったのか調査報告書にない。事務費用が下がるというお題目での導入だが、利用者が不在なのではないか。何をつくろうとしているのか一言で言いあらわせたのだろうか？そのストーリーは１枚の紙に収めることができるほど洗練されていたのだろうか？
ビジョンはレガシーシステムからの次世代システムへの以降です！キリッ
じゃあその次世代システムをストーリで説明してごらんなさい？

４．ミーティングをしない
はっきりとした話の内容が決まっていないミーティングは絶対しないというルールがあったのなら、何年もやって何も決まらないということはなかったことだろう。大幹を定めることなく枝葉末節から積み重ねたのだろう。だがそんな木はたちあがらない。

５．仕様書などの書類はつくらない
Gettign Realでは仕様書は合意をしたという幻想にすぎないと切り捨てている。同じ文面のものを読んでいても、そこから考えることは人それぞれだからだ。仕様書に機能を書き加えればうるさい奴を静まらせることができる。だから機能が増え過ぎる。基本設計書は、サインされ同意されるもの。開発中アイディアが誤っていたと気付いても、そのまま進むしかない。結果、すすむことができなくなった。
彼らは書類しかつくらなかった。なんたることだ。

６．アイディアは実行しないと意味がない。
アイディアは形にしないと思いつかなかったのと同じ。形にしても公開しなかったら作らなかったのと同じ。
だがしかし、彼らはそもそもアイディアをまとめることすらできなかった。
設計すら終わらなかったものに１３３億投入した。これ以上残念なことはないと思う。

７．時間の細分化
Gettign Realでは何ヶ月も何年も先の見積もりはもはや空想だという。より現実的な6-10時間の単位で細かく考えるべきだ。一方、特許庁のシステムでは完成を６年先とした。
作らなければ利用者の評価は得られない。決断する時は必要な情報が手に入った時のはずである。優先順位をつけ、ものを作り、それがとりあえず形になってから次に何をしようかというまえに、まだ出来上がってもいないものの上に次を重ねた。やはり、もはや空想でしかない。

８．才能をさがす
遅延したプロジェクトに人を加えると、ますます遅くなる。（ブルックスの掟）
絵に描いたように２００人から一気に４５０人まで増やし、１０００人を超えたという。コミュニケーションコストはいかほどであっただろうか。文章がかけるからといって１０００人集めたところでシェイクスピアのハムレットが出来上がることはない。一騎当千の才能が混じればそれもあるかもしれないが、それはただの確率でしかない。

９．情熱
たとえ奇跡がおきて確率的にそのような才能家が混じっても、集中出来る環境と情熱がなければ事はなしえない。炎上しっぱなしの環境下でコミュニケーションチャンネルがやたら多ければ集中できる環境には程遠い。しかも作成には掛かられず、ミーティングや進捗の報告、基本設計書や詳細仕様書の雑務に追われる。現場に幸せを感じ新鮮な情熱を保つ道理はない。

**感想
とほほの一言だ。
日本の官公庁をはじめ大企業は間違いがあってはいけないと完璧なものを目指す。そのため、事態が硬直化し、間違っているとわかっても修正が効かない。それで何とか動いても、制度疲労をおこし、全体として機能しなくなる。震災後の一連の対応をみてもわかるだろう。餅は餅屋と専門家を待ち続けたが、どこからも事態を解決してくれる餅屋はでてこなかった。
何のために古いシステムがあるのか、なんのために職員がいるのか、なんのために責任を取るべき立場の人間がいるのか、なんのために新しいシステムをつくろうとしているのかを忘れて、（Getting Real）実現するわけがない。そしてそれを阻害しない環境づくりが必要だ。
だが、環境づくりも仕組み構築か。

This is Japanese Real but not getting real.

参照：：

特許庁情報システムの技術検証結果について www.meti.go.jp/press/2011/01/20120124001/20120124001.html

[続報］特許庁の基幹系刷新「中断が妥当」、外部委員会が報告書 itpro.nikkeibp.co.jp/article/NEWS/20120124/379194/

特許事務システムの刷新可能性調査結果 www.jpo.go.jp/cgi/link.cgi?url=/torikumi/hiroba/sisutem_kousin.htm

2010 年（平成 22 年）度 特許庁業務・システム最適化実施評価報告 www.kantei.go.jp/jp/singi/it2/cio/dai43/siryou2/55.pdf

「特許庁情報システムに関する調査委員会」からの調査報告書の提出について www.meti.go.jp/press/20100820003/20100820003.html

調査報告書(PDF形式：1,180KB) www.meti.go.jp/press/20100820003/20100820003-2.pdf

とても参考になったがあまりにも長いので自分のメモリの小さい頭でもわかるようにまとめてみた。リファクタリングして繰り返しになっていた部分をまとめたり、超訳したりした。
また後ほど、日本の頓挫した特許庁とのシステムとものちほど比較検証してみる予定だ。

オリジナルの訳は下記から読むことができる。
37signal Getting Real

gettingreal.37signals.com/GR_jpn.php#ch07

Getting Real は、より小さく、より速くソフトウェアを構築するのにより適した方法です。またそのアプローチは多くのビジネス・クリエイティビティの現場でも採用できるものです。

■しぼりこむ / やらないことの大切さ
***やることを削る
機能を追加するな。機能を削れば戦線は絞れる。「何でもかんでも」というやり方には気を付けろ。必要だと思えるものを選び、さらにそれを半減。最も不可欠なものだけが残るまで機能を削る。もっと、は答えでない。コードも削れ。コード量が増えるにつれソフトウェアは指数関数的に複雑になっていく。ないコードより柔軟性のあるコードはない！

***持っている資源で戦え
自分でつくれ、自分のもっている資金でうごけ。無いものを戦力に加えるな。
時間やお金が予定よりかかりそうになったら優先順位を考えて絞り込め。

***チームは３人いれば十分
制限のある人的資源は何が必要かを明確にする。柔軟性がうまれる。
プロジェクトが大きくなると、ネックになるのがメンバーの増加。コミュニケーションチャンネルが増えるとコミュニケーションコストが指数関数的に嵩む。仕事がメモとミーティングに埋まってしまう。チームを小さくし、独立して動ける規模まで小さくし、コミュニケーションのリンクを減らす。

***まだ発生してもいない問題のために時間を費やすな
必要になってから増やす。決断する時は必要な情報が手に入った時。製品を作り始めたとき、持っている情報は最低限のものだけです。何か決める時は、その情報を持っている時で、その前ではありません。
すばらしいものを作り、それがとりあえず形になってから次に何をしようか考える。いきなり規模を考えたりしない。

***顧客の要望に対してまずノーと言う
顧客からの要望は聞いたら忘れる。読んで、投げて、忘れてしまえ。重要なものはいやでも浮かんで来続ける。要望に対してイエスと言うたびに子供が産まれる。あなたはその赤ちゃんを育てなければならない。一度世に出たものを顧客から奪い取ることはできない。

***皆を喜ばせようとすると、誰も喜ばない
本当に必要としている人は誰かを知り、彼らに喜んでもらえるようターゲットを絞り込む。

***ミーティングをしない
はっきりとした話の内容が決まっていないミーティングは絶対しない。ミーティングは必要最低限の人間のみで開催する。

***人は雇わない。
他の道を探す。仕事は本当に必要なものですか？それをしかなったら問題ですか？便利なツールや代わりのアプローチ方法でその問題を解決できませんか？誰かをクビにしても、すぐに代わりを雇わなければ、そのポジションに人がいなくてもどれだけ問題がないのか知ることができる。

***仕様書などの書類はつくらない
仕様書は実用的ではない。機能についての書類は書かない。アプリケーションは制作者が作り、デザイナーがデザインし、人々が使用して初めて現実する。機能スペックの記述は合意をしたという幻想。文面で納得するのは、真の同意ではない。同じ内容のものを読んでいても、そこから考えることは人それぞれ。何か機能を加えることでうるさい奴を静まらせることができる。仕様書をつくれば機能が増え過ぎる。
基本設計書は、サインされ同意されるもの。開発中アイディアが誤っていたと気付いても、そのまま進むしかない。
YahooやGoogleやAmazonを使うのにマニュアルは必要無い。マニュアル無しの製品を作ることの重要性がわかるはずです。

■つくりこむ / 形にすることの大切さ
***ビジョンは一言で
何をつくろうとしているのか一言で言いあらわせるか？

***ストーリーをつくる
新しい機能やコンセプトについて言葉で説明しないといけなくなった時には、それについての簡潔な話を書きます。技術やデザインを詳述してはいけません。
アプリケーションが必要としているストーリーを１つ書く。簡単な言葉で手早く。1枚の紙で収まらないのなら、複雑だと言う証拠。

***アイディアは実行しないと意味がない。
アイディアを現実に。実現していないものには価値はない。

***まず大局を固めてから細部にこだわれ
インスピレーションの紙スケッチ、走り書きでいい。それを元に皆が見ることができるのをつくる。それを評価して実際につくる。実際につくったものがダメならやり直す。成功と満足の秘訣はディテール（詳細）にある

***繰り返し
１回目でうまくいくとは思わないこと。アプリケーションを成長させ、そこから学ぶ。その形を変え、進化させる。作り、使い、分析。これを繰り返す。

***ユーザーに選ばせない
任意の設定をユーザーにさせるのはあなたが最良の選択肢を考えるという作業をユーザーに押し付けているということ。

***配慮ある初体験で期待を持たせる
第一印象は決定的です。もし配慮のあるブランク画面をデザインできなかったとしたら、アプリケーションやサービスについてマイナスの（そして誤った）印象を生み出すことになるでしょう。

***うまくいかなかった場合のデザイン（エラー画面）
認めましょう：オンラインで物事はうまくいかない。どんなにアプリを注意深くデザインしても、どんなにテストをしても、顧客は問題につき当たるものです。それではこういった避けられない障害にどう対処すればいいでしょうか。守備的デザインをするのです。Defensive Design for the Web（「ウェブ用守備的デザイン」）

***アプリには覚えやすい名前を付ける
複数ユーザーに意見を求めたり、ネーミングプロセスを委員会的にしすぎないことです。名前は短く、キャッチーで覚えやすいものを選ぶ。

■さがしだす / 見つけることの大切さ
***才能をさがす
遅延したプロジェクトに人を加えると、ますます遅くなる。（ブルックスの掟）
1人で1つの仕事をこなす優秀なプログラマーは、必要以上に人やコミュニケーションを持たない。同じ仕事でも5人のプログラマーですると協力やコミュニケーションがいる。時間は余計にかかる。だから二流のプログラマーが沢山集まったところで、どれだけ時間をかけても優秀なプログラマーのクオリティ品は作り出せない。

***干渉されない時間
うまく仕事のはかどる１人の時間は、IMも電話もミーティングもシャットアウトします。メールの即時の返答もしてはいけません。外音を閉じて、自分の仕事のみに集中する。

***時間の細分化
何ヶ月も何年も先の見積もりはもはや空想。12週間のプロジェクトではなく、１週間のプロジェクトが12週続くと思うのです。30時間かかりそうなタスクではなく、より現実的な6-10時間の単位で細かく考える。

***情熱を探す
不運なことに、多くのプログラマーはプロジェクトを完遂できない。プログラムは全て決断である。とても沢山の決断は、文化的な優位、価値、理想などで決まる。オープン・ソースの参加者にはある程度の情熱がある。熱意はごまかせない。
不満だらけの優等生より幸せで熱意を持った人間を見つけましょう。1人でも仕事を任せられる様な人。

***ジェネラリストを探す
スペシャリストより早く覚えるジェネラリスト。スペシャリストを雇うつもりはありません。彼等のディテールのこだわりは半端ではなく、我々のような小さなチームには、そのような一部にとてつもない能力を発揮する専門化肌の人間は１つのことに固執し変化を見出せないので合わないのです。
小さなチームには、何足もの草鞋を履けるような人間が必要です。ものを書くことができるデザイナー、デザインの分かるプログラマー…全てのメンバーが情報を（どんな情報でも）組み立てるアイディアを持つべきです。全員整った精神が必要だし、全員が顧客とコミュニケーションできることが必要なのです。

***良い文章家を探す
採用する際には、個々の文章能力を重要視します。デザイナーでもプログラマーでもマーケティングの人間、営業の人間でもです。文章構成のスキルは高く評価します。効果的な、シンプルな文章作成と編集の力は、コードやデザインやコミュニケーションなど、様々な舞台にも応用が利きます。
良い文章家はコミュニケーションの仕方が良いのです。人に理解させるのがうまい、相手の立場を考える、不要なものを見分ける、シンプルに考える。

■具体的な手順など
新機能を追加する際には、以下のステップが必要になります：

1. ノーと言う
2. その価値を証明させる
3. まだノーだったら止める；その必要を感じたら続ける
4. スクリーン/ UIをスケッチする
5. スクリーン/ UIをデザインする
6. コード化
7-15. テスト＆改良、テスト＆改良、テスト＆改良、テスト＆改良…
16. ヘルプのテキストを修正/チェックする
17. 製品ツアーの修正（必要であれば）
18. マーケティング用コピーの修正（必要であれば）
19. サービス規約の修正（必要であれば）
20. ルール違反がないかチェック
21. 価格構成に影響が出るかチェック
22. 公開
23. 見守る

評判と期待を起こすのに、ハリウッド式に１）発表・ティーザー、２）試写会・プレビュー、３）リリース

プロモサイトで人々に製品を紹介する
概要*：アプリとそのメリットの説明
ツアー*：各種機能について案内
スクリーンショットとビデオ*：実際のアプリの見た目と、どのように使うのかを見せる
マニフェスト*：製品の裏側にある哲学と考えの説明
ケース・スタディー*：何ができるのかを示すため現実での例を挙げる
評判*：顧客やレビュー、プレス等からの、証明を引用
フォーラム*：メンバーがお互いを助け合うことができる場所を提供
価格表示と登録機能*：できるだけ早く製品に人々を引き込む
ブログ*：ニュースや助言を書いたブログでサイトを新鮮に保つ

ふぅ・・・、まだなげぇ。100行ぐらいに超訳する。