「設計」という言葉が社内で通じないという恐怖 (1)

皆さん、上司や大先輩とのコミュニケーションで困っていませんか？
**同じ言葉**を使って話をしているのに、なぜか**話が通じない**ということはないですか？

その原因と背景の例を、実体験を元にした架空のストーリーで紹介したいと思います。
もし思い当たることがあってもそれは偶然の一致です。これはフィクションです。

# 第1章 長すぎた設計期間

## あなたの番よ

某社システム部にて

上司「ねぇ開発くん、ちょっとちょっと」
開発「はい」

上司「知ってのとおり、1 年がかりで開発中のプロジェクト」
上司「Ｘシステムのリリースまであと 3 か月よ」

開発「はい（去年聞いたけど、**周りで誰もやっていない**ような … ）」
開発「（悪い予感しかしない … ）」

上司「安心して、**私の人脈**で超優秀な**ＳＥ**が設計書を作ってくれてるわ」

開発「はい …（『エスイー』って、コンサルのことかな？）」
開発「（でもリリース 3 か月前で外注が設計書を作成中？）」

上司「明日が設計書の納品日だから」
上司「開発くん、明日からＸシステムの**製造担当**ね」

開発「え」
開発「あの … すでに 9 か月が過ぎてるんですよね」
開発「僕はまだＸシステムが**どんなシステムか知らない**のに」
開発「**残りの 3 か月で製造** …（実装のことかな？）はちょっと」
開発「しかもＸシステムは**複雑なシステム**と聞いています」

上司「だから、安心してって言ったでしょ」
上司「設計書は私が月イチでレビューしてるから」
上司「開発くんは、**設計書に書いてあるとおりに製造するだけ**よ」
上司「（まったく、これだからゆとりは … ）」

開発「わかりました … じゃあ、設計書が来たら転送してください」

上司「転送？」
上司「届いたら渡すから、とりあえず 10 部コピーして」

開発「（紙かよ！）」

## 川の流れのように

SNS にて

ベテラン「それはまあ、いわゆるウォーターフォール型の計画ですね」
ベテラン「後工程が厳しい気がしますが」

開発「そうなんですよ。何か問題が見つかって設計にフィードバックしたら」
開発「3 か月はあっという間に終わっちゃいます」

ベテラン「いや、設計は変えないでしょう」
ベテラン「要件定義 → 設計 → 実装と一方通行で進行するのがウォーターフォール型なので」
ベテラン「設計に手戻りがあると計画が破綻します」
ベテラン「だから上流工程にそれだけの期間を割り当てたんでしょうね」

開発「それじゃあ、設計に問題が見つかったら … 」

ベテラン「**上流の問題は下流にカバーさせる**計画だと思いますよ」

開発「それはひどい」
開発「なんでウォーターフォール型なんかがあるんですか」

ベテラン「例えば各工程の内容を何も理解できない人でも」
ベテラン「『要件定義 → 設計 → 実装』という文字列を読めば」
ベテラン「**計画全体を把握したような気になれる**というメリットがありますね」

開発「それ、錯覚ですよね」

ベテラン「あと、ウォーターフォール型で書かれた計画表には」
ベテラン「**不確実な要素がないように見える**ので」
ベテラン「各工程が予定の日に終わって、予定どおりにリリースできそうに見えます」
ベテラン「経営層に説明して承認をもらうには適していますね」

開発「それは、**問題が発生する可能性を見えなくしている**だけですよね」
開発「そのリスクを小さくするためにアジャイルがあるのに」

ベテラン「じゃあ開発さんは」
ベテラン「アジャイルで小さな単位の開発と改良を繰り返して … 」
ベテラン「みたいな説明で、技術オンチの経営層を説得できる自信がありますか？」
ベテラン「それじゃいつ終わるかわからないだろっ！」
ベテラン「って言われるかもしれませんよ」

開発「えー … じゃあウォーターフォール型というのは」
開発「技術オンチの人をだますためにあるんですか？」

ベテラン「もちろんそれだけじゃありません」
ベテラン「例えば枯れた技術だけで作る」
ベテラン「不確実な要素がほとんどないプロジェクトならどうですか？」

開発「確かにそういうプロジェクトなら」
開発「作り始める前に仕様や設計が全部できていた方がいいですね」

ベテラン「だから開発さんのプロジェクトの計画が」
ベテラン「**想定されるリスクを総合的に考えて作られた**のなら問題ないのですが」
ベテラン「そこが心配ですね」

開発「と言うと？」

ベテラン「リスクを事前に想定するには」
ベテラン「使用する技術や製品について相当な知識や経験が必要になりますが」
ベテラン「上司さんは古い用語をよく使われているようなので」

## SE／エスイー　それを言ったら、終わり。

開発「そう言えばＳＥが設計書を作ってると言われたんですが」
開発「エスイーってコンサルのことですか？」

ベテラン「うーん、古い話になりますが」
ベテラン「日本は昔から**システム開発の外注比率が高かった**ので」
ベテラン「立場の強い一次〜二次受け業者が、自社と下請けの利益配分をコントロールする方法を考えたようです」

開発「そんなことができるんですか」

ベテラン「簡単に言えば、**自社が受ける工程を高単価に**、**下請けに丸投げする工程を低単価に**したんですが」
ベテラン「同じような工程で単価に差を付けすぎると、各方面への説得力がなくなってしまいます」

開発「確かに」

ベテラン「そこで開発工程を**『上級職にしかできない上流工程』**と**『誰にでもできる下流工程』**の二つに分けて」
ベテラン「この上級職のために**『システムエンジニア』**という職種を発明したんです」
ベテラン「もちろん**和製英語**なので」
ベテラン「英語圏の人にそれを言っても通じませんよ」

開発「下流工程が誰にでもできるかはともかく」
開発「その上級職はすごいスキルを持った人たちだったんですか？」

ベテラン「まあ、とにかく上流工程を独占することが目的なので」
ベテラン「短期間の社内教育を受講させて、即席ＳＥを量産した会社もあったようです」

開発「いや、それじゃあ失敗は目に見えているでしょう」

ベテラン「ところが、そこそこ成功しちゃったんですよ」
ベテラン「たぶんＳＥが愛社精神と深夜休日を使って取引先との関係を築いて」
ベテラン「下請けが愛社精神と深夜休日を使ってＳＥの尻ぬぐいをしたんでしょうね」

ベテラン「まあそれとは別に」
ベテラン「**特別なスキルのないＳＥに上流工程ができた理由**があったりしますが」
ベテラン「話が長くなるので、その件はまたいずれ」

ベテラン「ただその時代の成功体験を持った人たちが」
ベテラン「いまだに**ＳＥの言いなり**になったり」
ベテラン「**プログラマの仕事を軽視**したりすることがあるので」
ベテラン「上司さんがこういう歪んだ常識を持った人だとすると」
ベテラン「開発さんのプロジェクトの計画が心配ですね」

開発「なんか」
開発「丸ごと当てはまりそうな気がします … 」

ベテラン「今後の問題にどう対処するにせよ」
ベテラン「こういう**歪んだ常識が生み出された背景**を知っいて損はないでしょう」

# 第2章 これは仕様書ですか？

## はい、設計書です

翌日 システム部にて

開発「荷物が重いと思ったら、**ごついキングファイル**だなー」
開発「お、紙だけじゃなくて **CD-R** でデータも納品してくれたんだ、助かったー」
開発「 … CD ってどうやったらパソコンで読めるんだっけ？」

何とか読み込んだ！

開発「中身は**全部 Excel のファイル**なんだ」
開発「**設計書なのに Excel** … ？」

何とか全部に目を通した！

開発「上司、ちょっといいでしょうか」

上司「何？もうできたの？」

開発「（うわー … ）」
開発「納品された Excel ファイルに目を通したんですが」
開発「**設計書らしきものが見当たりません**」

上司「何を言ってるの？」
上司「画面設計書があるでしょ？80 画面全部」

開発「画面の見た目というか、イメージは分かるんですが」
開発「入力する項目どうしの関係とか」
開発「ユーザーの操作でどういう動作をするとか」
開発「どこにあるデータをどうやってフロントに持って来るとか」
開発「そういう設計内容が見当たらないんです」

上司「はーーーっ」
上司「ファイル設計書を見て」

開発「（ファイルって … データベースのテーブルのことかな？）」
開発「画面の表示項目と同じ言葉が定義されていますが」

上司「それじゃん」
上司「よーし、頑張ろー」

開発「いやこのテーブル … ファイル設計書（？）もですね」
開発「正規化も何もなしで項目を並べているだけですし」
開発「リレーションも考えられていないように見えます」

上司「（イライラ）」
上司「それで？」

開発「それに、サーバに関する設計資料が何もありません」
開発「まさか、ブラウザから直接データベースを操作するわけにも行きませんし」
開発「最低でも Web サーバが必要だと思うんですが」

上司「ふーん？」
上司「**で、どうしたいの？**」

開発「（どうしたいって … ）」
開発「最悪、僕が実装する部分は**これから僕が設計する**としても」
開発「他のチームと連携する部分は**インタフェースだけでも**、誰かに設計してもらわないと」

上司「あのさー、このドキュメントが設計書じゃなかったら、何だっていうの？」

開発「 … たぶんこれは、**仕様書**じゃないでしょうか？」

## そう、データベースはファイルに

SNS にて

ベテラン「うーん、厳密な定義で『仕様書』と『設計書』を区別するのは難しいですね」
ベテラン「実現するべき内容が『仕様』で」
ベテラン「仕様を実現する手段が『設計』だと思いますが」

開発「じゃあ、僕が受け取ったのは … 」

ベテラン「いや、設計書か仕様書かよりも」
ベテラン「開発さんは今日**実装を始めるために必要な情報を得られなかった**」
ベテラン「そこが大事ですね」

開発「ＳＥにだまされだんでしょうか？」

ベテラン「いえ、逆に」
ベテラン「そのＳＥさんは本気で、**実装に必要な情報はそれで全部と思った**のかもしれません」

開発「そんなバカな」
開発「データベースなんて、正規化もリレーションも無視ですよ」

ベテラン「ん？ ほかに何か気付いたことはありませんか？」

開発「そう言えば … 」

> 上司「ファイル設計書を見て」
> 
> 開発「（ファイルって … データベースのテーブルのことかな？）」

開発「『ファイル設計書』にデータベースの項目が定義されています」

ベテラン「ああ … 」
ベテラン「ほかには？」

> 開発「それに、サーバに関する設計資料が何もありません」
> 開発「まさか、Web ブラウザから直接データベースを操作するわけにも行きませんし」
> 開発「最低でも Web サーバが必要だと思うんですが」

開発「サーバに関する仕様も設計もありませんでした」
開発「最低でも、DB サーバと Web サーバが必要なのに … 」

ベテラン「これは推測なんですが … 」
ベテラン「そのＳＥさんは、オフコンでの開発経験しかないんだと思います」

開発「オフコン … オフィスコンピュータですか？」

ベテラン「そう、古いオフコンにはリレーショナルデータベースがなくて」
ベテラン「データはファイルで読み書きしていました」

開発「それって、CSV や JSON のようなファイルですか？」

ベテラン「いちおう、インデックスファイルとかシーケンシャルファイルという形式があったようですが」
ベテラン「リレーションがないから、正規化もありません」
ベテラン「テーブルもないから、ファイルがデータベースだったようです」

開発「でも、サーバはありますよね？」

ベテラン「オフコンで作られたシステムでは、オフコン自体がシステム内で唯一のコンピュータだったんです」
ベテラン「当然、コンピュータ間の通信がありません」
ベテラン「だから、サーバという概念自体がないんだと思います」

開発「つまり僕が受け取った設計書は」
開発「オフコンのシステムのための設計書としては、特に問題なかったということでしょうか？」

ベテラン「おそらく」

開発「ということは、僕とＳＥさんの間で」
開発「『設計書』に対する認識は一致していたけど」
開発「**『どんな情報が必要か』という認識が致命的に違ってた**のか … 」

開発「あれ？ でもやっぱりおかしいですよ」
開発「そんな古い知識しか持っていない人が」
開発「ＳＥとして仕事を受注できるなんて」

ベテラン「そこについても、心当たりがないですか？」

> 上司「安心して、**私の人脈**で超優秀な**ＳＥ**が設計書を作ってくれてるわ」

開発「あ」
開発「上司の人脈でした」

ベテラン「やはりそうですか」
ベテラン「もちろん実力で仕事をしているエンジニアなら、30 年前の知識で生き残れるはずがありません」

開発「上司め … 」

ベテラン「まあ相手のことがわかったから、今後の対処法を考える参考になるでしょう」

開発「確かに、意味不明だったことがスッキリしたので」
開発「明日からどうやって仕事を進めればいいか、よく考えてみます」

ベテラン「ちなみにこの時代のＳＥはユーザーへのヒアリングや業務的な調査をしっかりする人が多かったので」
ベテラン「設計書に書かれている要件定義と外部仕様は信用していいと思いますよ」
ベテラン「開発さん、そういう仕事は好きじゃないでしょ？」

開発「う … どちらかと言うと嫌いです」

ベテラン「問題ないですよ、次の工程で必要なのは技術的な設計力だから」
ベテラン「開発さんが**好きな分野で実力を発揮すればいい**と思いますよ」

開発「はい、がんばります！」
開発「遅くまでありがとうございました！」

ベテラン「（ … それにしても上司さんの知識が古いとはいえ）」
ベテラン「（このＳＥへの発注は不自然ですね）」
ベテラン「（これは調査が必要ですね … ）」

----
（続く）