2018年1月に羽生章洋著『はじめよう！ システム設計 ～要件定義のその後に』が発刊され、2015年から続く『はじめよう！ 要件定義 ～ビギナーからベテランまで』『⁠はじめよう！ プロセス設計 ～要件定義のその前に』の上流工程三部作が完結しました。3回目である今回は、著者である羽生章洋氏に『はじめよう！ 要件定義』の前段階である『はじめよう！ プロセス設計』についてお話を伺います。

――前回は、要件定義をちゃんとやるためには、それより前のことをちゃんとやらなきゃダメって話でしたけども。

羽生：要するに、材料がないと成果って出せないよね、と。生卵がないと目玉焼きって作れない。で、世の中には、要件定義の前工程がほんとないんだなあ。これが数十億円規模の案件でも多発してるの。

――でも、元受けとか二次受けレベルがいるわけですよね。

羽生：あのね、結合テストの仕様書の作成支援をする仕事に行ったときに、単体テストがコンパイル通ってなかったんですよ。

――それは、スケジュールが遅れてたんですかね。

羽生：そうなの。スケジュール的には開発が完了したことになってんだけど、実際にはまだ開発の真っ最中なので、単体テストが動かないんですよ。工程が全部ずれてて、結合テストが終わる段階で、単体テストができるレベル。

――ってことは、開発が終わる頃に要件定義……。

羽生：そうなんですよ。一個ずつ見事きれいに工程がずれてて。じゃあなんでって言ったら、一番初期の段階で業務設計をやるべきところで、誰も何をやっていいのかわかんないから、何にもやってないんですよ！ 何もやってないまま、業務要件の設計が終わったことになっちゃってる（笑⁠）⁠。

――要件定義をしなきゃいけない人たちが、もっと上から手を付けなきゃいけなくなってるわけですね。

羽生：そうそう！ だから、要件定義で困ってる人は、要件定義で困ってるわけじゃないの。一つ前なんですよ。結合テストがうち大変なんですって言ってるところは、結合テストじゃなくって、単体のレベルがもうすでにダメなんですよ。前工程の尻ぬぐいをやってるの。これね、100パーセントなんですよ。

結局、何のために、どんなソフトが必要やねん

羽生：『はじめよう！ プロセス設計』にも書いてるけど、プロセスは前工程の成果が後工程の材料になって、これが連鎖して行くんですよ。よくね、トヨタ式とかでさ、後工程はお客様とか言うじゃないですか。なのに、後工程にとりあえずゴミを流して、うち（自工程）は終わりましたーって言っちゃうんですよ。これね、運用に入ってからもそうなんですよ。もうね、運用以前なの。前工程としての開発のね、尻ぬぐいを運用とか保守の名のもとにやってる。

――よく「運用でカバー」と言いますけども。

羽生：違う意味で「運用でカバー」してるんですよ。開発そのものの不備をカバーしてるの。じゃあ、それはなんでだろうっていうのをいろいろと追及していったら、結局は「要件定義」っていう言葉のなかに、いろんなもんを全部混ぜすぎちゃってて、工程がでかくなってるんですよ。

――「要件定義」をもっと小さくしないといけない。

羽生：うん。一番大事なのが「業務要件」とか「ビジネス要件」とか、言葉は定まんないんだけど、要するにユーザーニーズをまとめて、ソフトウェア要件に落とす前に決めるやつですよ。アジャイルでいうと、ユーザーストーリーですよ。結局、何のために、どんなソフトが必要やねんっていうときの「何のために」が、誰もわかってなかったんですよ。それで、『⁠はじめよう！ 要件定義』の11章を抜き出してできたのが、『⁠はじめよう！ プロセス設計』なんです。

――当初は出す予定はなかった？

羽生：なかった。本当は『楽々ERDレッスン』をリバイズしたものを先に出したかったんだけど、いや待て、これはデータベース設計以前だと。そんな話より先にプロセス設計をやんないと辛いって話になって。

――工程が逆流してますね。

羽生：それで、11章を抜き出したものだから同じシリーズにしましょうっていうことで、まず中身の体裁が同じになって、表紙のイメージを決めるときに「どういう仕事をしたいのか」っていう、前作の俯瞰的な状態にしたかったので、こっちの（要件定義の本の）花が、ここ（プロセス設計の本の表紙）にもあるんです。

――目玉焼きを作ってる人もいますね。

羽生：そうそう。つまり、目玉焼きを作って、こういう接客をして、こういうレストランをやりたい、っていう要件を実現すると、こう（⁠『⁠はじめよう！ 要件定義』の表紙を指差して）なるよねっていう意味合いがあります。後付けなところもありますけど（笑⁠）⁠。

一番のゴミ溜めみたいな言葉になってるのが「要件定義」

――この2冊は本当に姉妹というか、対象読者も同じですか？

羽生：そうですね。でも、失敗したのは「プロセス設計」っていうタイトル。「⁠プロセス設計」は自分の仕事じゃないとみんなが思ってるんですよ。

――たとえば「業務設計」だったらよかったかも？

羽生：それも悩ましくて。昔から工程としてはちゃんと一応あるにはあるんですよ。ただ、今でこそIPAの「共通フレーム」に「業務設計」っていう言葉が入っているんですけど、日本だと「要件定義」って言葉に丸められがちで。しかもメーカーごとに派閥があって、用語がぜんぜん違うという。だから業務設計って言っても通じないというか。

――「外部設計」なのか「基本設計」なのか、とか。

羽生：こっちの「要件定義」はこっちの「システム分析」ですよ、とかね。ちなみに、僕はNECの「STEPSII」育ちで、下請けでガッツリやってたのね。それで、転職してから富士通（の手法）の案件に行くと、言葉遣いが微妙にずれてて。そういうずれてる中で一番のゴミ溜めみたいな言葉になってるのが「要件定義」ですよ。

――（ゴミ溜め……。）

羽生：プロジェクトの企画の話から、詳細設計のところまで、よくわかんない工程は全部「要件定義⁠」⁠。そんな状況で、派閥によって用語が違うから、プロセス設計はみんなが自分の持ち分じゃないって思ってるんですよ。

――「サービスデザイン」なんかがいいんじゃないですか？

羽生：確かに（2017年5月に出た「デジタル・ガバメント推進方針」で「サービスデザイン思考」という言葉が明記された）今だったらいいのかもしれないけど、『⁠はじめよう！プロセス設計』は2016年じゃないですか。当時は、言葉遣いとしてのサービスデザインはまだまだ微妙で、タイミングが合わなくって。

プロセス設計は忘れられた「黒歴史」

――まあでも「プロセス設計」のほうが普遍的な言葉だから、長く持たせようと思えばそっちのほうがいいですよ。

羽生：読んだ人はね、みんな褒めてくれんの。でも……。

――あ、本を手に取るまでが。

羽生：そう。自分に関係があると思って買ってはくれない問題があってね。そもそもなんでみんなこんなにやらないんだろう、まあ知らないからやれないんだけど、なんで知らないんだろうって調べたの。そしたら、昔僕たちが読んでたような本が今絶版なのよ。たとえば、IE（インフォメーションエンジニアリング）って今手に入んないじゃないですか。

――手に入らないですね。ぼくは古本で買いました。

羽生：良かった。僕ね、IEを読んでない人の語るソフトウェア開発プロセス論って、あーはいはいって感じで流しちゃうんだけど（笑⁠）⁠。働き方とか見える化とかって、90年代にブームになっているんですよ。BPRとか仕事の流れ図を書こうみたいな本がすっごいたくさん出てて。でも、今はほんとになくって、何冊かあるにはあるんだけど、どれも悪くはないんだけど、なんていうかちょっと……。

――要件定義の本と一緒で、おじさんが読む系って感じですかね。

羽生：そうなんですよ。この話題に飛びついた人たちが読む感じのものにはなっていなくて。

――歴史に埋もれちゃってますね。

羽生：そうそう。だから、それをもう一回掘り起こす必要があるんですよ。これはね、まさに「∀ガンダム」（⁠※1）のテーマであるところの「黒歴史⁠」⁠。∀ってね、ザク[2]を掘り出して「ボルジャーノン」って名前を付けるんですよ、ザクって名前を知らないから。そうそう、数年前にartonさん[3]に「∀を見てないのはどうかと思う」って言ったら、素直に50話見て「よかった」って言ってくれたの。

――ちゃんと見たんだ、すごい（笑）。

羽生：すごいよね。artonさん、いい人だから（笑⁠）⁠。「⁠∀」はほんと素晴らしいから。お勧め。長いけど。まぁ、それはともかくとして、要するに「黒歴史」っていうのは、今は恥ずかしい思い出みたいな、人に言えない思い出みたいなイメージだけど、元々はいろんな出来事があって人々の記憶から忘れられてしまった、歴史に埋もれてしまったという意味なんですよ。

――『はじめよう！ プロセス設計』も「黒歴史」を掘り起こしたものであると。

羽生：まさに。プロセス設計は昔あったのに、今ないから、これを全部掘り返すんだっていうね。

顧客になる義務も義理もない

――最近だと「サービスデザイン」とか「カスタマージャーニー」みたいなのも、ここで言うプロセス設計と近い感じはありますよね。

羽生：そうなんですよ。結局、ユーザーストーリーの最後の項目があるじゃないですか。「⁠なぜなら何とかだからだ」っていう。あれを抜きにしてやってもダメなんですよ。エロゲーのバトルにこういうエロい機能があったらユーザーがガンガン課金して金落とすんだよ、とかね。業務システムなんかでも、こういう機能があれば現場が楽になるんだよ、みたいなこと言うんだけど、それって本当か？ と。こっちが作りさえすれば、ユーザーは利用して当たり前でしょ、みたいな傲慢さですよね。

――使ってもらうためにどうするかが抜けている。

羽生：そう、ユーザーには使う義務なんかないんだよ。だから、そういう配慮を目指すという意味で、サービスって言葉を使うのはいいと思うの。でもね、「⁠サービスデザイン」って、いろんな意味でわけわかんねぇっていう気持ちがあって。デザインするのはサービスなのに「サービスデザイン」を実装しましょうみたいな感じになってて、サービスデザインが名詞になってて、気持ち悪いじゃないですか。

――UX（ユーザーエクスペリエンス）なら。

羽生：まだまし。あれは許せる。「⁠カスタマージャーニー」とかも全然許せる。だけど「サービスデザイン」って、モヤっとした感じがありますよね。「⁠サービスエクスペリエンス」とかって言えばいいのに。数年前からいろんな本が出てるけど、みんなこの名前問題に見て見ぬふりしてんじゃないかな。

――いちおう歴史はあるらしいんですけどね。はっきりしないですよね。

羽生：ビジネスプロセスと何が違うのとか、サービスプロセスとかでもいいじゃんとか、いろいろ言いたい気持ちはあるんですけど、百歩譲って、タスクをこなすんじゃなくてサービスをやるんだよっていうマインドで捉えましょうよっていうところは、僕も正しい方向だと思うんです。だって、顧客になる義務も義理もないんだもん、そもそも。

――作り手側に寄りすぎるとダメですね。

羽生：オープンソースでも成功するのとしないものってあるじゃないですか。成功するやつって、ユーザーがエンジニアやプログラマのやつが多いんですよ。あれって、作り手側が、エンジニアエクスペリエンスとか、プログラマエクスペリエンスを感じているからですよ。

――そうですね。

羽生：それと同じで、業務プロセスを設計するときは、ジョブエクスペリエンスというのかな、そういったものを感じながらサービスを提供していくというマインドで作らないと、使ってもらえないというか、成功しないんじゃないかな。

お客さんのために我々は何をすることが求められてるのか

羽生：そもそも「IT」って言葉が出る前から、企業のプロセスは変わってなくて、何が違ってきたかというと「オンザウェブ」なんですよね。ウェブを使って、しかもカスタマーダイレクトにビジネスをやれる。それまでのITは、単なる「記録」なんですよね。売上が立ったら伝票を書いてから、それをコンピュータに入力するっていう。だけど、今は違うじゃないですか。たとえば、Amazonでポチってやったら、その場で売上も立つわけ。

――発送の手配もするし、在庫管理も、全部つながってますね。

羽生：昔っからある本屋の既存システムも、個々の機能としてはAmazonと同じかもしれないけど、その組み合わせ方がビジネスに直結してないじゃないですか。だけど、システム化というのはビジネスに直結している状態を作ることなので、分断させる考え方はナンセンスになっていくと思うんですよ。

――社内業務に使うものとユーザーが使うものを区別しないとか？

羽生：区別する必要はないと思う。それこそAIみたいなもんが入ってきて、業務自体がAIで済んじゃう世の中になったら、バイモーダルでSoRとSoEって分ける理由とか、社内システムのユーザビリティは低くてもいい理由ってのは、多分ない。お客さんのために我々は何をすることが求められてるのかっていう、その一点において合流するしかないよ。

――なるほど。

羽生：ただ、商売的にね、法人はこっちのほうが買ってくれやすいとか、同じ題材でもエクスペリエンスを分けるとかはあると思う。そういうのは、売れてナンボよ、みたいなゲスい気分はあるけど、土台は原理原則だから。「⁠商売の原理原則」「⁠人が顧客になる原理原則」「⁠問題解決の原理原則」「⁠技術の原理原則⁠」⁠。そういうものを組み合わせていった先っていうのは、そんなややこしい面倒臭い、わざわざ区別するようなやり方ではないと思うんだよね。

次回予告：突然の明太子屋さん！