「アイスクリーム味のチャーハン」を攻略する

アイスクリーム味のチャーハンとは：

チャーハンください。味は……えーと、アイスクリーム味で。

ちなみにうちの子は卵アレルギーなので、代替食で。

味にはこだわります。

最近流行のエビ風味あんかけチャーハン、あんな感じがいいかなぁ。

何かお薦めあります？

あ、あと、安くしてね！盛り付けは綺麗なのが当然。

プロなんだから、そこは気を利かせて

いい感じにしてくれたらオーケーです(^-^)

みたいな話。

ひどい話だけど、よくある話。

初めてこの言葉を世に問うたのは、「予定通り進まないプロジェクトの進め方（宣伝会議）」である。

新たな価値創造の取り組みを、着手するまえのこの混乱は、いかにすれば対処できるのか。

要望、要求、要件、仕様、設計に、仕分けていこう、ということが、基本的な指針である。

https://gyazo.com/79b98eeab1207fc263954e367180a756

例えば、「車」を例にとって考えてみる————

要望

気分がムシャクシャするときに、スカっとかっとばせる車がほしい

普段の買い物にも気軽に乗れる車であってほしい

近い将来、子どもの習い事の送迎にも使いたくなるかもしれない

燃費は良いに越したことはない

ツウ好みな感じで、人にちょっと小自慢できるような車だと理想

要求

アウトドアではスピード感のある走行を楽しめ、街中ではスタイリッシュで人の目を惹く、おしゃれなSUV

納期：◯◯

価格帯：◯◯

要件

型式「XXX-AAAA」をベースに拡張開発を実施する

外観、意匠、機能等について、◯◯の条件を満たすものとする

仕様

馬力：◯◯

燃費：◯◯

排気量：◯◯

最高速度：◯◯

最大積載量：◯◯

・・・

設計

外観設計

意匠設計

機能設計

内部設計

・・・

なんとなく、どことなく苦しいというか、厳密性を考えると微妙なところはあるが、あくまで、イメージとして・・。

実際の自動車の要件開発手法としては、例えばホンダのA0、A00等が有名で、上記のような単純なものとは違う。(A0、A00の時点で、徹底的に、ターゲットとする要望・要求を磨き込む、というイメージが近い)

まぁそもそも、車種開発をクライアントワーク風に表現すること自体にそもそも無理があるわけだけれども、各概念の大雑把なニュアンスの違いを理解するためには、一旦、このあたりの表現でも差し支えはないかなと思う。

＜以下、思うところを徒然に…＞

戦闘機等の軍事開発では「要求仕様」という言葉がしばしば使われる。これは、戦略に基づく戦術や作戦が、そのまま仕様に直結することを象徴している。つまり、要求＝今後取りたい作戦行動がそのまま仕様＝航続距離や砲門数等の定義に直結する。

要求は物理的制約から離れて自由に設定することはできない。

つまり、航空力学的な原理原則や、エンジン開発における基礎技術の水準を無視した夢物語であってはならない。さらにいえば、要求仕様は作戦そのものだけでなく、調達難易度やリードタイムも考慮のうえ決定される必要がある。

そういうことを理解しない無茶なオーダーが上から下に降ろされ、メーカーの経営陣が無茶だとわかりつつコンペに手を挙げ受注し、開発者は面食らいながらも頑張って形にしたものの、結局どうにもならなかった・・・というのはよくある話。

そのあたりは、「世界の駄っ作機」シリーズを読むと、非常に味わい深いものを得ることができる。

https://gyazo.com/17ecd136e7e173644b33114169c3637d

宮崎駿監督「風立ちぬ」は、そうした悲喜劇を、零戦を題材として描き、映画監督自身の悲哀も重ねながら語った作品である。

https://gyazo.com/418abe524c50564165ccc2fdfb6149d5

©スタジオジブリ

なぜ、そういうことが起きるのか。

設計行為が、要求仕様という「ゴール」を満たすための手段として位置付けられたせいではないか、と、思う。

より思弁的な言い方をすれば、要求、要件、仕様、設計は、人工物としての設計解を、異なるパースペクティブで捉えた個別の表現である、という状態が、唯一正しい。つまり、本来は「要求→要件→仕様→設計」という順序で落とし込めるようなものでなく、あらしめられるべき人工物が「要求＝要件＝仕様＝設計」という状態を満たしている状況が、突如、現れる、という話であるべきなのである。

アジャイル開発の本質は、その思想はまさに「一気にあらしめる」という理想を追求するということであるが、それが実現できるかどうかは、それを担う人材・座組み・環境次第である。理想論はいったんさておき、現実的なウォーターフォール開発とは、過去の実績や雛形をなぞりながら「要求→要件→仕様→設計」という順番のカスタマイズ開発を行う、というものがせいぜいのところである。そうして見てみると、アジャイルは、イノベーションの再現方法論であり、ウォーターフォールは改善の再現方法論と看做せるが、例えばウォーターフォール進行において、諸般の事情を鑑みて、要望をもとに要求を絞りこむ行為もまたある種の設計行為といえる。さらにいえば、要望を集める行為や要望の集め方を考える行為そのものに、すでに設計行為が萌芽している。

「設計」は、狭義においては「設計図面を引くこと」を指すわけだが、「要望→要求→要件→仕様→設計」という思考の流れ自体に、設計的思考は働いている。

畢竟、イノベーションとは、新たな巨大なルーチンを生み出す人工物の創造であり、設計とはその中核的営為である。そう見ていくと、ウォーターフォールとアジャイルは、同じ話を別の角度から眺めているに過ぎない。

＊＊＊

ちなみに、このあたりの事情はインダストリアルデザインの歴史にも、学ぶところが大きい。大学時代の授業で印象に残ったうろ覚えな話で恐縮だが、おそらくレイモンド・ローウィだったと思うが、氏は「最後に、美しく覆ってしまえ」という哲学を持っていたそうな。現代は車だろうがソフトだろうが、外観から設計するのが常識だが、意外とそういう発想から、自由になっていいのかもしれない。

https://gyazo.com/4ddf9fc603fcdbe04b827a45ed3768a8

レイモンド・ローウィ

一般的なビジネスプロジェクトの場合、特にIT受託開発の場合だと、スコープが発散しないための防波堤として、要求定義の工程を設ける、という理解が一般的である。

ただそれも、発注側の意思決定者やキーパーソンに「要求定義とはなんぞや」「必要あるのか」といわれてしまった場合、実にやりづらくなるのが通例である。実際のところ「要求定義でなにをすべきか」を受託側もうまくイメージできず、よくわからない空理空論を展開して終わってしまい、実際「必要だったのか」と言われても仕方ない状況を導いてしまうことも、ままある。

いや、それ以前に一般的なIT受託開発において「要件定義」工程でなにを決めるのか、という問題そのものからして、考えてみると、随分むずかしい話である。ローカルルールも多いので一概には言いづらいが、要件定義とは、主にUIと機能を決めるものであり、非機能要件もついでにざっくりと語っておきつつ、試験に入ってからチューニングをする、これらの議論のアウトプットとして仕様書がある、という具合のイメージを持っている人が多いのではないかと思う。

https://gyazo.com/5208cbbb714982a52017937dbcd59aa4

https://gyazo.com/8e3f2f7131bba00a393b40cd00940b0d

つまり、要件定義と外部設計（上図でいう第１～２段階）が、だいたいイコールのものとして語られることが多い。また、外部設計を決めるためにはI/F設計やDB設計にも触れざるを得ず、結局のところ、ふと冷静になったら、要件定義をすっ飛ばして設計工程に入っていたことに気づき、愕然とする、なんてこともよくある。

結果、その設計でいいか悪いかの判断基準であるはずの要求なり要件なりがあいまいなため、なし崩し的に後工程に突き進むしかない…といった話は、いくらでもある。SaaSの場合は設計と設定がほぼイコールだったりすることもしばしばあり、もはやここに至ると、なにをやっているのかさっぱりよくわからなくなる。

論理的には不可能な作業手順のほうが、実践的には容易である、というのは、興味深い現象である。おそらくそれは、人間の認知機能の深部が超高機能であることと、表層部が超低機能であるというアンバランスさによる。つまり、人間とはおそらく、無意識のうちには非常に深く洞察し、意識的には非常にお粗末に真似る動物なのである。

＊＊＊

ことほどさように、「ある程度、モノができあがってみないと、何を要件定義すればいいかすらもわからない」というのは、IT受託開発の世界では、実に日常茶飯事である。言葉で書かれても読めない、イメージがわかないという、身も蓋もない発注者も珍しくない。それを見て「アジャイル的な感じでやりましょう」という掛け声で、なしくずしに進める適当な輩も多く、それもそれで本当に、いったいいかがなものかと思う。

とはいえユーザ企業における事業戦略や事業コンセプト自体があいまいであるがゆえに、逆立ちしたって要件定義のしようがない、ということも、実は、結構よくある。実際のところ、事業戦略や事業コンセプトがなくたって、座組みとビジネスモデルがあって、ポジショニングがそれなりなら、会社経営はある程度、回るものだったりもする。

凡庸な発注者は、ITベンダの提案内容をきっかけにして、自社の戦略を見直せばよいと考える。ゆえに、IT屋はITは手段であって目的ではないと口酸っぱく言い続ける。

現実的な話をすると、開発業務の受注活動に、開発コンセプトや論理的な正しさは、必ずしも必要でなかったりする。ただし、納品においては必ずそれは必要になる。曖昧な受注は可能だが、曖昧な納品は不可能である。なぜなら受益者の使用現場では、利便性という身も蓋もない現実が問われるからだ。せっかく作ったのに、使われない、という現象は、こうした理屈によって起きる。

＊＊＊

別の側面からこの問題を検討すると、例えば後工程についての見積や計画には、情報が必要であるのは当たり前だが、開発を任せると決まっていない相手にそれを開示したくない、という力向きが常に存在する。俗に言う鶏卵問題である。開発側は非常にわずかな情報から類推し、リスクを取ってコミットせざるを得ない。そして、蓋を開けたら想定を遥かに超える駄目な状況に面食らうのは、お決まりのパターンである。

開発着手前に十分な情報が得られるベンダとは、ユーザ企業との取引履歴が豊富ベンダであるが、そのような関係性に至るときには曇りなき眼を失ってしまっていることも多い。痛し痒しである。

大規模IT開発になると、こうした矛盾のあれこれを解決する大技として、「要件定義」までを、コンサル会社が受託し、その結果をRFPとしてまとめ、引き受けられるベンダを公募する、ということがよくある。しかし、これも実は、自分に言わせればまったくもってとんでもない話で、製造者の事情や状況を鑑みずに要件が確定するなんてことは、民法的にいってちゃんちゃらおかしな話なのである。実際、「コンサル様が作った要件定義書を参考にしながら、実際に開発するベンダがあらためて要件定義し直す」なんていう馬鹿馬鹿しい話をそこら中で聞く。

賢いコンサル様なのだから、せめて要求定義までに止めてRFPにしたらいかがかとは思うが、おそらくそれも、原理的に言って不可能な話なのだ。このあたりをちゃんと理解するためには「一即全」「啐啄同時」といった仏教語を頼らなければならなくなる。

＊＊＊

さらにちなみにいえば、建設業界では「ゼネコン」「デベロッパー」という業界的な役割分担があって、これはこれで一定程度の合理性のある形である。

https://gyazo.com/1798b49ca92898645e7f743066b67188

IT開発におけるデベロッパーの役割を、誰が担うべきなのか。経営陣か、DX推進部門か、はたまた情報システム部門なのか、IT戦略コンサル屋なのか、それともやはり大手SIerなのか。このあたりの棲み分けのあいまいさが、多くのIT開発の悲喜劇を招いているように、思えてならない。

実践的には、有能な中規模ITベンダが「ゼネコン」「デベロッパー」の一人二役をこなす、というのが、もっともコストが低く、実効性も得やすい座組みなのかもしれない。実際、そのような事例に近そうな話も見かける。

畢竟、「要件」なり「仕様」なりといった言葉のつかみどころのなさは、こうした社会環境に深く根ざしたものであるから、あんまり深く突き詰めても、ちょっと虚しいところはある。

「要求」や「要件」とは、取引の当事者同士の政治的な握りあいの話であり、「仕様」や「設計」は物理的な握りあいである、と、これぐらいにぼやっとでも理解しておくのが、ほどほどにちょうどいい、と言ってもいいかもしれない。

＊＊＊

最後の最後に、さらに実践的な話をぶっちゃけてしまうと、筋の悪い構想には付き合わない、というのが最善である。筋悪なインスピレーションには、なにをやっても駄目である。まさに、度し難い、という言葉が相応しい。つける薬はない。とはいえしかし、世の中の大半は筋悪である。泥水をすすりながら、忸怩たる思いをちゃんと抱え、捲土重来を期すことができる人が、生き残るものである。

唯一やりようがあるとすれば、筋の悪い状況から、再構想する、ということである。

将棋用語を借りると、プロジェクト活動には光速の寄せか泥沼流の、二択しかない、ということである。

本稿の締めくくりとして、光速流と、泥沼流を、止揚する。平時においては絶えず伏線を散りばめておき、一朝事あらば即座にブラコラージュしてしまう機転。それこそが、プロジェクト思考の真髄である。

なにごとも、泥棒を見てから縄を結うようでは手遅れである。