田坂さん
Vistaはやっぱあかんやろ
Vistaを使い始めて約３四半期。Vistaについては、いまだにフォントであるメイリオ以外良いと思うところがない。UIもイルカや冴子先生が恋しくなるぐらい直感的でない。遅い。しょっちゅうハングる。管理者権限が必要な操作をするごとにsudoライクな確認手順を要求するアーキテクチャも過去のアプリとの下位互換というWindowsの最大の売りを大きく損ねている一つの原因のようだし、素人には、なんでこんなことしなくてはならんか全然わからんだろう。使いにくい。
これからService Packで良くなる部分とならない部分があるが、Vistaで問題かなあと思うところのほとんどはService Packで解決できるところとは思えない。SPで解決するのは、一般的に非機能的要件か機能の追加だ。たとえば安定性とか性能、脆弱性への対応、標準への対応、そして新しい機能やサービスの追加などだ。UIの変更とか根本的なアーキテクチャの変更はありえない。
というわけでVistaはやっぱだめやろ。XPがいいなあ。やっぱ。けど、親に新しいマシンを買おうと今日調べたらVistaしか選べないところが多い。選べても高い。困った。
すべてのプロセスにWhyがある
この前、開発の現場の人と「設計書をゼロからもう一回書き直せるならどこを直すかという」話題で話していたのだが、その人が言ったのは「なぜそういう設計にしたのかをすべての設計書で明確に記述しておけばよかった」ということだった。一ヶ月ほど前、友達でパッケージソフトの開発やっているやつもまったく同じ事を言っていた。一般的にウォーターフォール型の開発では営業から要件定義のフェーズで、そのシステムがなぜ必要でなぜこのような機能を持つべきかというのを記述する。しかし、逆に言うと「なぜ」を記述することが重要視されるのは要件開発に含まれるプロセス群に対してだけであるということである。
しかし、設計や実装、テスト、維持管理とまあ開発に限定しただけでも他にさまざまなプロセスはある。そして、それらのプロセスは何らかの意思決定によって具体を決定していくプロセスであるはずだ。つまり、そこに「なぜ」そうしたのかがあるはずだ。もちろん、いわゆる「方式設計」では、それなりに「なぜ」を検討し記述してある。ただ、業務機能開発での設計以降は「なぜ」をあまり記述として残さないようだ。それは、要件開発が済むと業務機能開発での設計以降は'そこそこ自動的に決まるようなイメージ'があるからではないか。どうもウォータフォールでは「Why」の決定(要件開発)->「What」(要件開発-外延的・設計-内包的)->「How」(製造)->「Verification->Validation」(テストもろもろ)とフェーズ切りになっていると思いがちだ。しかし、そうではなくて「すべてのプロセスに意思決定は存在し、それゆえすべてのプロセスに「なぜ」は存在するはずなのにと思う。テストの世界では、Wモデルというものがあるが、すべてのプロセスに「Why」を記述するというモデルが本当は必要ではないか。一方、本当に「なぜ」がないプロセスなら、それは、徹底的な自動化を検討すべきプロセスであり、そのようなプロセスの自動化の効果は大きなものであろう。
また、参考に言えば、同じく開発現場の人が言っていた事だが「あるプロセスを100%自動化できないツールはgarbage(ゴミ)だ」ということもある。これは開発におけるアクティビティ群を粒度の大きいプロセス群に分類整理したとして、その区切ったプロセスの範囲だけでも100%自動的に処理できないようなツールは、結局ツールがやることとほぼ同じ処理を人が再確認・修正しなくてはならなくなる。で、それはプロセスの部分的ではなく全体的にわたる場合が多く、さらにツールが自動化している処理を人が可能にするため、処理に必要な背景知識を学んでおかなくてはならずその勉強の稼動も必要となる。結局、ツール導入効果が非常に薄いという体験からきているらしい。
たとえば、オブジェクト指向言語でのユニットテストデータ生成プロセスの自動化ツールとかを考えた場合、網羅率100%は非常に困難*1で、通常後で人がテストデータを付け加える。つまり、100%自動化できる部分だけをプロセスとしてきれいに区切るのが非常に難しく、ツール化があまり意味がないということだ。それなら方向性としては、AgitatorみたいにAgitatorを使う場合の全体的なテストプロセス群を、Agitatorでほぼ自動化できる部分とまったく自動化できない部分をなるべく明確に分離したプロセス群として定義するべき*2なのだ*3。その点でAgitar社はよく考えていると思う。
この話からおぼろげながら示唆できることは、プロセス改善の一般的な指針だ。
- 人の意思決定が存在するもしくは重要なプロセスには「なぜ」を文書化しておいて、以降「人の意思決定を支援する」知識体系を構築することを目指す。
- そうでないと思えるプロセスは徹底的に手順を定義し機械的な自動化できないか目指す。
- プロセスを区切る観点、特になんか大きすぎる粒度だなあとか感じるプロセスの場合、このような自動化可能かどうかで分割してしまうという観点もあるのかもしれない。
田坂さん
上記は田坂さんの著書を読みながら、自分の仕事に対してこの本のいっていることから学ぶことはないかと思い気づいたことだ。
この人の話をはじめて聞いたのは、確か会社に入った2ヵ月後ぐらいのコマースネット・ジャパン*4のカンファレンスの時だ。最初の林芳正という議員が50分ぐらいしゃべり、一日六万円のセミナーでやたら豪華な昼ご飯がきれいなお姉さんからserveされて、会社に入るとこういうことができるのかーと勘違いしたり、電子マネーの普及はアメリカの策略だということを忘れるなという、今から考えると文系の教授にありがちな「技術的にありえないだろ」という話を熱く断言している東大の経済系の教授(名前忘れた)の話に、素直に世の中って怖いのお*5とか思っていた、勘違い全開の頃だったが、この人の話だけは具体的に何かは忘れたが、かなりまともに聞こえたことだけは覚えている。
今日、本を読んでいて、たった本を読んでいるだけなのに久しぶりに説得されそうな感じを体験し、で、どっかでこんな感じの話聞いた覚えがあるなあと思ったら会社に入った頃かあ。ふむ。
