萩本さん on 要求開発

萩本順三 @haggy335

#redajp　僕が要求開発方法論を作ろうと思っていた頃に、ビジネスモデリングに対する疑問は、モデリングはそれを適用する局面をデザインして初めて活かされるということ。その局面のつながりがプロセスだ。プロセスを作ってこそモデルが活かされる。

萩本順三 @haggy335

#redajp　僕が当時のUMLを活用したビジネスモデリングに不満を感じていた事は、それらはすべて「How」のモデル化じゃないかという事。そしてHowの根拠となるサービスや戦略をどのようにモデルとしてトレーサブルに表すべきか考えていた。

萩本順三 @haggy335

#redajp　そこで戦略とかサービスという領域をモデル化するための方法を考えたわけだが、それができないかぎりHowのモデル化では何も価値を生み出せないと思った。そうしている内に「ビジネス戦略」と「ビジネスオペレーション」という単純なレイアを考えた。

萩本順三 @haggy335

#redajp　モデルとしては価値とか戦略といった上位上位に上っていったのであるが、僕的には、どうもそれでもモデルに対する価値の実感が湧かない。このままではモデルの決定的、存在価値を証明できず。

萩本順三 @haggy335

#redajp　モデルは頭の中に描いたアイデアなどを単に絵にしているだけ。つまりアイデアのHowとしての構造を書いているだけという考えを昔から持っていたので、所詮モデルはHow。だからユースケースを買いてもよい要求など生まれない。整理のため。

萩本順三 @haggy335

#redajp　ただ、僕的にはモデルの可能性を感じていたので、なんとか価値を表現するモデルを考え、Howとしてのモデルに連携できないかと考えていた。そんな中、「描く力」と「作る力」という考え方が浮かんできた。モデルを書く際に、この二つの力が必要なのだと。

萩本順三 @haggy335

#redajp　そんな訳で、いま僕は描く力を身につけるための考え方、アプローチ方法が、大きなテーマとなっている。

萩本順三 @haggy335

#redajp　あ〜すっきりした。自己紹介というか要求開発関連つぶやき終わり。 これつぶやきって言えないよね（＾＾。 つぶやきは苦手です。 みなさん、よろしく！

萩本順三 @haggy335

#redajp　でもモデルっていいよね。分けることで分かることが実際にはある。でもそれを頼りにしているエンジニアやコンサルは青いとしか言いようがない。なぜなら、そういうことに頼るようなことでは、おとしまえをつけられない。もっと結果イメージを予測してモデルを書くべし。

萩本順三 @haggy335

#redajp　つまり楽しみながらモデリングやっているのは勉強としてはいい方法。でも、結果イメージを予測し、必要時間、書いたモデルの効果点、次ぎに向けてのアプローチ法を頭の中で手探りしておく必要がある。そんなプロフェッショナルなモデリングを身につけてほしい。

萩本順三 @haggy335

#redajp　ただ、僕はモデル依存症ではない。モデルは好むがモデルに頼らず。描く作業は頭の中に立体空間を作って、その空間の中にすべての事象が収まって安定するようなものを作り出す。これができないかぎりモデルは書かない。これは、頭の中のモデルかな？

萩本順三 @haggy335

#redajp　ところで描く力とは何だろうとジl作り考えると、人が作り出すコンセプトとかビジョンとかを、「用語」「意味」「メカニズム」「デザイン」で表現した際に、それらが非常にまとまりよく一貫性のあるものとして作り出せる事が僕的な描く力だと思っている。

萩本順三 @haggy335

#redajp　ここで用語とは、単純でシンプルな文章を発明すること。人は、そのようなシンプルな用語に対して情熱とか意思とかを刺激される。 たとえば「結果イメージの予測」「Howの手探り」なども用語の発明だと思っている。

萩本順三 @haggy335

#redajp　僕が目的と手段の連鎖のことろで、よくWhatとHowを使って説明している。これには訳がある。その分けは、HowがWhatの価値を高めている事実をおもむろに理解してもらいたいからだ。

萩本順三 @haggy335

#redajp　エンジニアはビジネスのHowの領域に存在している。しかし、エンジニアがHowをその根拠となるWhat(ビジネスオペレーション)や、もっと上位の根拠となるビジネス戦略につなげて説明できるようになれば最強である。

萩本順三 @haggy335

#redajp　これからのエンジニアは、HowとしてのITを活用して「Howからの突き上げ」により、ビジネスオペレーションやビジネス戦略の価値を高めるような、イノベーションを起こす必要がある。だから要求開発なのだ。

萩本順三 @haggy335

#redajp　だが、いまの要求開発だけではだめだ。要求開発とシステム開発を近しい所で回すためのプロセスを自社内で確立することを目標とすべきだ。それが僕の考えるビジネスアジャイルなのだけど、みんなで考えたいよね。 アジャイルはビジネスアジャイルであるべきだ。

萩本順三 @haggy335

#redajp なんか今日も要求開発関連でつぶやきたくなったので書いてみる。

萩本順三 @haggy335

#redajp 前回つぶやいた「描く力」であるが、これはITエンジニアに一番足りない部分ではないだろうか、いやいまの日本人、これができる人が少ない。 ビジョンを描く、アーキテクチャを描く、要求を描く。すべて価値を描くことからはじめよう。

萩本順三 @haggy335

#redajp そもそも「描く力」これが足りないのは、日本の学校教育の課題であるようにも思う。決められた解だけを教えるような。解があるのではなく、いくつかの解を導きだすプロセスを考えることを教えることが必要。 いまのビジネスでは解がない問題解決を求められている。

萩本順三 @haggy335

#redajp たとえば、目的を考えなさいとか「目的志向」で考えなさいとかについても、目的が唯一のものと思っていると大間違いである。目的は観点によってどうとでも定義できる。だから価値のある目的や、人が意図する行動ができるような目的を「描く」ことが重要なのだ。

萩本順三 @haggy335

#redajp 「描く力」の観点で「要求」を見るとどうだろう。少なくとも要求定義という言葉には要求を描くという観点は見て取れない。それはただ、発注者にヒアリングして要求を整理するという観点のように思えてしまう。これは「要求」という言葉に起因すると僕は思う。

萩本順三 @haggy335

#redajp 「要求定義」という言葉を使ったのはソフトウェア工学的に失敗だったと僕は考えている。 なぜなら、それは、AさんがBさんに要求するという形にしか見えないからだ。ご存知の通り、それは発注者と受注者の価値を創造する過程の中で生み出されるIT活用の定義なのだ。

萩本順三 @haggy335

#redajp 要求開発的には、「発注者と受注者の価値を創造する過程」を更に発展させて、経営者と業務とITという戦略、業務、IT活用という３つのロールモデルを採用することにした。このロールモデルにコタツモデルという素敵な命名をしてくれた安田理事には感謝している。

萩本順三 @haggy335

#redajp ただ、このコタツモデルは、実は依田理事が僕が作った図の右上に、机の上で議論しているアイコンを入れたものを作ってくれたのであるが、それが、みんなはコタツに見えたのである。なんとも愛嬌のあるメタファだ。あ、話が飛んでしまった。まあ、これもつぶやきだから仕方がない。