第5回　はじめよう！システム設計

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

――ここまでに「要件定義」と「プロセス設計」の話はしたので、残りは最新刊の『はじめよう！システム設計』ですけど、これはどういう経緯で書かれたんですか？: 羽生：ここまでくると、三作目は理屈じゃなくて「やるしかない」っていう（笑⁠）⁠。いやね、これまでの2冊を持っていろんな現場に行くと、要件定義はわかりました、前工程のプロセス設計もわかりました、ところでこれから何をしたらいいんですか？って言ってくるんですよ。
――誰がそんなこと言うんですか？: 羽生：情シスとか、SIerとか。
――普段は何をしてるのかっていう話ですね……。: 羽生：IFDAMを見ると、要件じゃなくて詳細設計書に見えるらしいのね。要件ってのは、日本語の文章で書いてあって、あの手のモデリング的な図で表現されたものは、もう設計なんだろう、と。で、「⁠もう下請けに出してもいいですかね？」って聞くから、お前は何を言ってるんだ[1]と。アーキテクチャ的な機能分割とか一切考慮されてないわけだからね。「⁠いやいや、最低限の設計をして出さないとダメですよ」って答えたら、「⁠最低限の設計って何ですか？」って言うから、いちからか？いちからせつめいしないとだめか？[2]っていうね。
――でも、「最低限」は何かと言われると、ちょっと答えに困りますね。: 羽生：それは確かにね。でも、エンプラ系だと大抵のケースは、だいたいDOA（データ中心アプローチ）にかぶれちゃってるか、それより前のメインフレームの頃の構造化の呪いにつかまってるか、どちらかなんですよ。
――なるほど。: 羽生：DOAにこだわる気持ちはわからんではないけど、ビジネスが急激に変化してるとか、デジタルトランスフォーメーションだ何だとか言ってね、SNSが定着してる時代に、いまさらビジネスの安定的な写像をデータモデルに求めるような古いやり方で、稼働後本当に時代に追従できるのかよっていう。ただ、彼らとしては、メインフレームからクラサバに切り替えることができたっていう成功体験があるんですよ。組織的な成功体験があるんで、やっぱそこに執着しちゃうんですよね。
――若者たちには辛い感じですね……。ぼくは、ずっとERDのモデリングツールのテクニカルサポートやってたんですよ。なので、DOA屋さんの相手ばかりしてたから、すごくよくわかります。: 羽生：えっ！その話は今はじめて知った。
――あれ？そうなんですか？羽生さんの『楽々ERDレッスン』のERDは、そのツールで描いてましたよね。ちょうどその頃にサポートやってましたよ。: 羽生：へええ。ガチで知らなかった。

モデルには基準点を置けないから、どうしても手が止まる

羽生：DOAじゃなかったら、数十億円のレガシーマイグレーションで業務のリバースもしてない状態で、httpもまったくわからず、オブジェクト指向な言語での開発経験もないようなところが、DDD[3]の麻疹にかかって突っ込んでいくとかもあったりしてね。
――無茶なDDDの話は、よく聞きますね……。DDDも「黒歴史」みたいなところはありますからね。歴史からモデル駆動を掘り起こせば、どうにかなるんじゃないかという。: 羽生：僕らみたいなビフォーUMLの世代からすると、一周回ってそこなのかよみたいな。オブジェクト指向、方法論の歴史から見たときに、ぐるーっと一周回ってDDDって、あれ？お前らはデータベース主義を否定していたところに、結局戻ってきてねぇか？みたいな気分がある。僕からすると、RDBにおけるドメインの話の焼き直しにしか見えないので。このあたりは、酒匂寛さん[4]に見解も聞いてみたことがあるのよ。
――オブジェクト指向の達人的にどうなのかと。: 羽生：そうそう。ちょっと前に一緒に呑みながら聞いたら、関数型がマイブームだった時期だったようで、「⁠そんなことより関数型いいよ～」みたいな感じでね（笑⁠）⁠。まぁ、彼も僕も、問題意識が要件定義っていうか、彼は「期待・課題・仕様・設計」って表現してるけど、似たようなところにフォーカスしてるから、よく色んなお話をさせてもらってるんだけど。上手くはぐらかされてる（笑⁠）⁠。
――まあ、なかなか意見しづらい問題ではありますね。: 羽生：まぁねぇ。結局ね、エンタープライズにおけるほぼ唯一の選択肢がJavaになっている状況で、Javaという言語の不自由さをどうやって理想のオブジェクト指向に近づけるかっていうことをやってるうちに、手が止まっちゃうんですよ。
――モデルに取り込まれちゃった。: 羽生：モデルにはユーザーが評価できる基準点を置けないから、どうしても手が止まるんですよ。ユーザーにわかってもらえるもんって、画面しかねぇんだから。ユーザーにダメ出しされるのって、画面じゃないですか。ましてやこのご時世、使ってなんぼのユーザーエクスペリエンスの時代じゃん。そういう状況なのに、なぜか後ろ（論理構造のモデリング）側からやっちゃうんですよ。
――当たり前ですけど、モデルを描くだけではシステムはできませんしね。: 羽生：だけど、モデル描いて満足しちゃう人がいるんだよね。「⁠俺の世界を描ききった」みたいな。いや、俺もそういう麻疹にかかってたことあるから、言いたくなる気持ちはわかる（笑⁠）⁠。だけど、だけどなあ……。
――昔は「IDEF0とIDEF1X[5]さえあれば大丈夫」とか言われて、ハァ？ってのはよくありましたよ。で、プログラムはどうすんだっていう。: 羽生：確かにモデルは大事だし、それがないとあとで困ることはあるだろうけど、モデルさえあれば全部できる、ってのはねえよと。ユーザからしたら、業務の現場を舐めんなよだろうし、開発の現場からしたら、実装を舐めんなよと（笑⁠）⁠。
――ほんとそうですよ。

人は何度同じ過ちを繰り返すつもりなんだ？

羽生：大昔のユーザーインターフェイスはグリーンディスプレイくらいしかなくって、プログラムを作る作業がほとんど全体を占めていたから、当時のパラダイムの人はみんな「プログラムの設計が大事でしょ」って言うわけです。だけど、90年代以降にRDBをやってた人たちは「DB設計が大事でしょ」って言うんですよ。
――自分たちが苦労したというか、教育を受けたところに影響されるんでしょうね。: 羽生：だけど、どっちも画面は蔑ろなんですよ。90年代ってVBのおかげでGUIが普及したはずなんだけど、グリーンディスプレイの焼き直しみたいな酷いUIが多くて。で、システムが使えないってダメ出しすんのは、画面しかわからない人たちなんですよ。そういう力関係を考えたときに、何をやるべきかは、もうわかってんでしょ？と。やっぱり今は、UIなんですよ。
――『はじめよう！システム設計』には、UIに関する記述が多いですよね。: 羽生：特にエンプラの人たちは、UIに関する知見がまったくない。びっくりするぐらいない。しかも現場にモバイル端末の持ち込み禁止とか、よくあるじゃないですか。iPhoneが出てからもう10年以上経つのに、今どきのUIに対する知見のなさが半端ない。だから、最低限に絞り込んで、UIの話をしてます。
――やっぱり、UIは重要ですよ。: 羽生：プロジェクトがでかいと、リリース予定が今から3年後とかになるわけです。今からやっても東京オリンピックよりまだ先の未来。そんなときに90年代くらいのパラダイムを引きずってて、30年前の古い知見ベースで、それで使い勝手とか、ITで業務生産性向上とか、本気かよと。
――UIに関することは、ウェブディレクターならわかってるでしょうけどね。: 羽生：逆にウェブディレクターなんかは、そのUIをどうやってプログラムやデータベースに落とすべきかをわかってない人が多いから。どうやると自分の実現したいことが作り手や開発者に伝わるか、みたいなところを読んでほしいんですよね。
――そこも重要ですね。: 羽生：アジャイルの人たちも割とUIから逃げるじゃないですか。ユニットテストというか、自動テストできるところばかり優先して、プログラムに逃げちゃう。逃げるってのは、言葉悪いけど。
――UIを扱うのが苦手なのは、エンジニア全体に言えるかもしれませんね。: 羽生：俺、いちおう15年くらいはUIスケッチを作ってきてるんだけど、自分としてはUIについて語る資格があるのか自信がなかったからさ、知り合いのウェブデザイナーにね、僕が現場で作ってるUIスケッチとかモックとか見てもらったの。そしたら「ここまでやってるウェブデザイナーは少ないよ」って言ってもらえて。だから俺、UIデザインに関して多少は語ってもいいかなってね。小心者なので（笑⁠）⁠。
――なるほど。: 羽生：でね、そういうのを引っくるめて、人は何度同じ過ちを繰り返すつもりなんだ？ってことで、『⁠はじめよう！システム設計』の裏表紙は「リング・オブ・ガンダム」（⁠※6）なんですよ。5分くらいのオリジナルムービーなんですけど、ここで何をやってるのかというと、アムロの遺産を掘り起こして、またリングコロニーを壊しちゃうんですよ。で、「⁠ああ、また起こった、また起こった」って印象的なセリフがあって。
――それだけ聞いてもよくわからないですけども（笑）。: 羽生：あはは（笑⁠）⁠。要するに、再びデスマーチが起こってしまったなかで、人類はちゃんとしたノウハウという遺産をですね、正しくちゃんと引き継ぐことができれば、間違いのリングが繰り返されるのを突破できるっていうことですよ。で、遺産というのは、構造化プログラミングによるモジュール論だったり、『⁠ノンデザイナーズ・デザインブック』の内容だったり、データの正規化ってことですよね。流行り廃りを超えて、時間を超えてブレない強度を持った原理原則。

おっちゃん、この話長くなるよ？

――データの正規化の話でいうと『はじめよう！システム設計』の16章にある「IDと主キーの話」もありますよね。今でこそ、IDを使うのは当たり前になってますけど、2006年に最初に『楽々ERDレッスン』で提唱されたときは、いろいろ言ってくる人がいたみたいですね。: 羽生：いや、今だにあれで「サロゲートキー主義の主犯格」扱いされて、ディスられるんだよ。あの本では「サロゲートキー」なんて、一言も言ってないのにだよ。
――個人的にはRuby on Railsがあったので、何の違和感なく取り入れることができましたけどね。: 羽生：年配のRDB経験の豊富な方々には、IDがあると冗長に見えるみたいね。だけど、その冗長さが拡張性を呼ぶんですよ。コード体系はこうだと決めつけてしまうのは、そのときは楽かもしれないけど、あとで融通が効かなくなるんですよ。つまり、ID論はシステムの寿命に対する戦略論なんですよね。
――ぼくはそこまで深く考えてなかったですけど、単純にIDのほうが楽ですよ。: 羽生：うん、楽（笑⁠）⁠。あと、所詮データなんて現実の、事実の後追いでしかないじゃん、ってのを思い知らされることもあったりして、この辺の「⁠”事実が無かった⁠”という事実があった」みたいな話はNULL論とセットではいつかちゃんと整理して書き残せたらなぁとは思うんだけど。でね、コードはUIだって言ってるんだけど、コード体系にもユーザビリティってあるのよ。
――コード体系のユーザビリティ？: 羽生：俺、昔は伝票打ちのパンチャーだったからさ、腕にこういう黒いのつけてさ、伝票処理してたときの経験があってさ。毎日500枚くらい入力すんの。でさ、得意先コードとかコード体系が数字だけのやつは楽なんよ。右手だけで入力できるから。
――右手のテンキーだけで。: 羽生：そのときに何が腹立つって、アルファベットが入ってるコードなの。左手で伝票の束をめくってるんだけど、めくった束が戻ってこないように伝票を重石で押さえてから、左手でアルファベットを入力して、また伝票に左手を戻して……。だから、ナチュラルキーがどうのこうの言ってる人たちの設計したコード体系にアルファベットが入っていると、あのときの記憶が蘇って「バーカバーカ」って言いたくなるんですよ（笑⁠）⁠。入力とか運用とかまで考えてんのかって。
――伝票500枚を入力したことがあるのかと（笑）。: 羽生：伝票500枚打つってのはね……おっちゃん、この話長くなるよ？
――はい、どうぞ（笑）。: 羽生：伝票500枚打つってね、1回入力して終わりじゃないんですよ。今度はベリファイモードに切り替えて、もう1回同じのを打つんですよ。前回タイプしたのと同じじゃなかったら、入力を間違えてないか確認してくださいっていうメッセージが出るんですよ。あーごめんなさいごめんなさいって言いながら修正したら、今度はバッチでチェックプログラムに流すんですよ。10分くらいするとレポートが出てくるんですよ。そしたらレポートの横に「論理チェックが通りませんでした。入力を間違えてませんか」みたいなことが書いてあるんですよ。それをまた伝票を見ながら突き合わせて確認して、この場合の論理チェックはしなくてもOKですとか入力し直すんですよ。でも、たまに入力は全部あってんだけど、伝票が間違ってることもあるんですよ。この得意先コードないわな、とかね。そしたら得意先マスターを確認して、やっぱないわってなったら、お客さんに電話かけて「いただいた伝票◯◯番の得意先コードが未登録でして……えっ、先週ファックスで送った？申し訳ありません、確認させていただきます」ってなって、そのファックスを探しに行って、得意先マスターを更新して、伝票を入力し直して……それで、ようやく伝票入力が終わりました、なんですよ！（ちょっと息切れ気味⁠）⁠
――えっと、それ何の会社なんですか？: 羽生：受託電算業務。
――ジュタクデンサンギョウム。: 羽生：昔はコンピュータが高価で巨大だから、システムを自社に持てないからね。いろんな会社の業務のシステムの代行をしてたの。
――お客さんから手書きの伝票が来て、それをシステムに入力する？: 羽生：そう。製造業の伝票も打てば、飲み屋の伝票も打つ。もちろんそれだけじゃないよ。そのためのシステム開発とか運用や保守もするし。今風にいうと毎日がDevOpsバリバリ（笑⁠）⁠。自分が生まれた年に書かれたコードの保守とかメッチャやってたし。当然ドキュメントなんか皆無。当時ですでに20数年経ってるGOTOだらけのガチのスパゲティのメンテとかも。だから、単に開発しやすいだけじゃなくて、5年後10年後にメンテしやすいコードがどういうものかってことに対してすごく実感を持ってるから、そのへんは今どきの言語を前提とした上で『はじめよう！システム設計』にも書いてる。
――確かに実装に近いところまで書かれてありましたね。: 羽生：んで、システムに入力した伝票を集計処理とかしてね、いろんなレポートを各会社さんに送るために、カーボン紙に印刷するのもやるの。1000ページ単位のやつをいくつもね。そのときにカーボンをはがして、ダンボールに詰めて、みたいなこともやる。紙だからめちゃくちゃ手が切れるのよ。でも、軍手とかすると、修正分のパンチとかしないといけないときに面倒だから軍手はつけない。だから手が真っ黒になるの。あと、もうこれは完全に余談だけどさ、夏の暑いときにマシンが熱暴走するから、空調のためのクーリングタワーの掃除をしないといかんのよ。屋上に登って腕まくりして、ホースで水ぶっかけながらゴシゴシと。めっちゃ肉体労働よ。これが、当時のコンピュータの仕事。めっちゃ物理（笑⁠）⁠。
――はい、よくわかりました（笑）。

仕様書を日本人の僕が読んでも、こりゃ実装できないわ

――あと、『はじめよう！システム設計』で気になったのは、11章の「オフショアで炎上する理由」です。仕様書の日本語がそもそも変だと。: 羽生：日本語って不明瞭なんですよ。なんでも名詞化するのが好きで、「⁠何をどうする」のかっていうことを明示しないことが多いんです。だから、オフショアの仕様書を日本人の僕が読んでも、こりゃ実装できないわってなるんですよ。できるだけ言葉に頼らずに済むように、定量的な表現になるように、マジカなりIFDAMなりを考えてはいるんだけど、言葉での表現をゼロにはできないですね。
――『はじめよう！システム設計』では、必ず「VO形式」にして、動詞を明確にしろと書いてありますね。: 羽生：これは、日本語自体の善し悪しじゃないんだけど、日本語はいろいろ省略しても通じるんですよ。「⁠きれいやん」「⁠せやな」でコミュニケーションとれるんですよ。でも、仕様書はちゃんと省略せずに書かないと、通じないですよ。
――翻訳の場合は、逆にできるだけ省略するようにしてますね。そのほうが自然な日本語になるので。たとえば「私は～」とか、普段の会話ではいちいちつけないですからね。: 羽生：角さんの『リーダブルコード』とか『カンバン仕事術』とかを読むと、翻訳を読んでいる感じはしないよね。
――日本語はデフォルトであいまいなので、余計な修飾表現をつけないように気を付けてますよ。何も考えずに翻訳するとページ数が1.5倍くらいになるんですけど、そうやって余計なところを削って削って、だいたい原書と同じページ数くらいになるようにしてますね。: 羽生：そこらへんの気持ちのよさなんだろうな。
――でも、『はじめよう！システム設計』に書いてある「能動態」や「肯定表現」なんかは、翻訳でも同じですよ。表現を少し変えるだけで、読みやすくなることは多いですね。

課題を課題にしないアプローチだってある

羽生：オフショア向けの仕様書が書けないのは、日本企業は「現場」って言葉がものすごく好きだからと思うんだよ。エンジニアやプログラマも開発の現場にいることに対して変にプライド持ってるじゃないですか。それで、現場にいない人たちを、逆にね、見下しちゃって。「⁠現場語」が通じないのは現場をわかってない証拠だ、みたいな感じでね。その結果、近視眼的な意思決定をしがちに思うの。
――確かにそういうのはありますね。: 羽生：僕にとっての「現場」は「利用の現場」だから。ユーザーって利用者だから。開発の現場の外側にある、利用のエクスペリエンスをデザインしなきゃいけないっていう意識がすごくでかいんですよ。開発の現場ももちろん大事よ。でも、開発の現場を重視しすぎると、悪いものを改善することにしか目が向かないんですよ。目の前のココを直しさえすれば、きっとよくなるはずだっていう。
――もっと根本的な解決策があるはずなのに。: 羽生：エンジニアはユーザーに対して「課題は何ですか？」って言うんだけど、課題を課題にしないアプローチだってあるじゃない。たとえば、Twitterが落ちても、それを問題視せずに、落ちたことを祭りにして楽しむことだってできるわけ。
――GitHubとかSlackが落ちたら家に帰る、ってのもありますね（笑）。: 羽生：そうなんだよ。落ちたら早く帰れるんだぜって（笑⁠）⁠。たぶん、そういうふうに思える力がないと、自分たちの外側にあるエクスペリエンスをデザインすることはできないんじゃないかと思うんだよ。そういうのができる人が育っていかないと、本当の意味でのシステム設計もできないと思うのね。でもそれって、逆説的にね、この設計なら実装に落とせるっていう裏付け感を持ってないと、視野が実装や設計の外に広がらないと思うんですよ。だからやっぱり、設計の原理原則をわかってるってのは大事よね。
――では、詳しくは『はじめよう！システム設計』をお読みください、ということで。: 羽生：無理矢理まとめましたね（笑⁠）⁠。ですね。ぜひ！まずは買って読んでみてください（笑⁠）⁠。