Life is beautifulのsatoshiさんは以前から、User experience︵satoshiさん訳‥おもてなし︶を製品開発の主体におくべきであると主張されていたが、正直﹁そんなの当たり前だろ？﹂と思い、賛同していながらも腑に落ちていなかった。で、昨日たまたま研究室の先輩と雑談をしたときの﹁企業ではソフトウェアの上流工程をできる人が必要﹂という話を聞き、そして、上記のエントリーを読んでようやく腑に落ちたように思う。
先輩が言っていたのは、﹁ソフトウェアの上流工程とは、インターフェースの定義である。インターフェースは、入力と出力を定義することで、システムの設計とは、この入力と出力をどんどん細かく分割していくことである。﹂そして、﹁上流レベルでは、Howを含めないWhatを明らかにする。現在は、要求分析の段階でHowを含めてしまう人が多いため、上流工程ができる人がいないといわれている。﹂とのことだった。また、同席していたボス曰く﹁システムが提供する機能というのは部品の機能を足し算したものではない﹂とのこと。また、この話の例としてミグ25の亡命の話︵ミグ25が亡命してきたとき、アメリカの技術者がミグを解体して使われている部品などを調べたら、かなり粗末な部品を使っていて驚いたという話︶、中国のロボット開発においてシステム工学の専門家に指揮をとらせて、ロボットの品質をあげたという例を教えてくれた。何か、似たような話を読んだことがあるなと思って思い出したのがMacbook Airの分解話﹁開いてみたら平凡な部品と平凡な設計だった﹂というもの。
どこのことわざか忘れたけど﹁一頭の獅子に率いられた百匹の羊は、一匹の羊に率いられた百頭の獅子に勝つ﹂というのがある。これなんかは典型的にシステムというのは単なる部品の足し算ではなく、あるデザインに沿って正しく配置されることの重要性を述べていると解釈できる︵ことわざなんていかようにでも解釈できるものではあるけど︶。われわれがソフトウェアやハードウェアに関わらずシステムを設計し、構築する理由は、そのシステムを持って現実に存在する問題を解決したいからである。
satoshiさんは、製品が解決すべき問題というのは﹁ユーザーの生活をよりよくする﹂という点にあると認識し、開発する製品を持ってその問題を解決することのみに注力すべきだと言っているのだと思う。そして、気にすべき点は﹁その製品を用いてユーザの生活をよりよくすることができるか否か﹂だけで、﹁新しい技術が投入されているか？﹂﹁最高品質の部品が使われているか？﹂は二の次、三の次であると。確かにスペック勝負というのは﹁最高の部品を組み合わせれば、最高のシステムができる﹂という発想に近づきやすい。
でも、実はわれわれは﹁最高の部品を組み合わせれば、最高のシステムができる﹂というのが、あまり正しくないということをしょっちゅう目にしている。特にスポーツなどで顕著だけど﹁ドリームチーム︵オールスターチーム、日本代表選抜など︶﹂がリーグ戦を長く戦ってきた﹁普通のチーム︵玉石混合︶﹂に負けることは良くある。別のチームのスター選手をつれてきたけど、そのチームでは全然活躍できなかったということも良くある。もちろん、時間がたてばドリームチームやスター選手はその輝きを見せつけてくれるが、ほとんどの場合、戦術やチームメイトに馴染む時間を必要とする。小説、漫画、ドラマ、映画などでも、金にあかせて最高の部品︵武器、品物︶を用意してみせた敵役が、使い慣れた道具や部品、信頼できる仲間を持った主人公役に敗れるという物語は王道中の王道だ。
私たちは﹁﹃最高の部品を組み合わせれば、最高のシステムができる﹄というのが、あまり正しくない﹂と知っているのにも関わらず、なぜ、自分たちがシステムを作ろうとするときには﹁最高の部品を組み合わせれば、最高のシステムができる﹂という主張をしがちなのか？それは、私たちは今手持ちのカードで戦うしかないということと常に締切りがあるということの2点が原因だと思う。
私たちの能力や使える資材や道具には必ず制限がある︵それが、個人であっても、企業であっても、国であっても同じ︶。この持っている能力や使える資材と道具に基づいて﹁どうやってシステムを作り上げるか？﹂がHowの部分。一方、﹁ある問題を解決するためのシステムはどうあるべきか﹂と考えるのはWhatの部分。本質的にWhatとHowは独立の話だ。なぜならば、Whatをどうやって実現するかについては多くのやり方が考えられるためである︵あるサービスを提供するソフトウェアを複数のプログラム言語で同等に作れることを想像してほしい。あるいは、東京から沖縄まで行く方法が何種類もあることを思い浮かべて欲しい︶。本来はHowと独立にWhatを考えるべきなのに、﹁この話は最終的には自分が成し遂げなければならない﹂と考え、無意識あるいは意識してHowから逆算してWhatを考えてしまう。この結果、私たちの能力や使える資材や道具の制限内で開発しようと﹁システム﹂が定義され、﹁システム﹂が定義された結果から、その﹁システム﹂が解決できる﹁問題﹂が設定されてしまう。
上述の話は、システムを納入する︵公表する︶締切りが大きく関係している。もし、システムの納入締切りが無期限であった場合、交渉や買収、あるいは学習により私たちは自分の使える能力や資材、道具を増やすことができる。締切りがタイトであればあるほど、増やせる能力や資材、道具は減るので、自分が持っているカードで戦うことを余儀なくされる。自分のカードだけで戦わなければならないとき、上述のHowから逆算してWhatをでっちあげるという自体が発生する。
以上のように原因が分析できても現状は変わらない。依然として私たちが使える能力や資材、道具は限られているし、システムを納入する期限にも制限がある。現実には、Howから逆算してWhatをでっちあげるという自体が発生しやすい。だからこそ、Whatを列挙するときにHowを混ぜず、純粋にWhatの列挙に徹し、その後、列挙したWhatを使えるHowを駆使して実現してみせた個人、企業、組織が賞賛に値するし、指示されるのだと思う。﹁自分たちが実現できないかもしれない﹂や﹁結局、実現しないならばこんなことやっても無駄に終わるんじゃないか﹂という恐れを堪えて、解決すべき問題にだけ焦点を当て、それを解決するためのシステムはどうあるべきかを淡々と誠実に列挙していくことが、システム設計および開発に重要なことだろうと思う。
そういう意味ではLife is beautiful: 私からの提案‥おかえりなさいテレビのコメント欄は興味深い。私もそうだけど、技術者というのは、おもしろいアイデアを目にするとすぐに﹁それは〜という製品で実現されているのでは？﹂とか﹁そのアイデアは〜を使えば良いですね。﹂とWhatをより洗練あるいは明確にするのではなく、すぐにHowの検討を始めてしまう傾向にあると思う。一種の職業病。一方で、よく、素人が＊＊の開発のキーパーソンだったという話があるけど、それは、素人はHowを知らないから、純粋にWhatに注力できるために生じることと私は解釈している。
長くなったけど、まとめると、システム︵製品︶開発において、そのシステムで解決したい問題に目を向け、問題を解決するためにシステムは何ができなければならないかというWhatを、どうやって手持ちの能力、資材そして道具で実現するかのHowとは独立に列挙することがとても重要であり、これを自覚し、実践している技術者︵研究者︶がこれからの産業界では求められていると思う。そして、そのような、ある意味では無駄に終わるかもしれないチャレンジを許す度量がシステムを開発する企業や組織には求められていると思う。
