設計書に記載がなければ不良じゃない？

「いきなり何を言い出すのか」
「頭がおかしくなったんじゃないか」

と思われた方もいらっしゃるかもしれません。
えぇ頭のおかしい理屈ですしね。気持ちはよーくわかります。

あ、お久しぶりです(:3_ヽ)_

色々書きたいことを書ききったのと、引っ越し後やることが多すぎて日々体力の限界を迎えていたことでnoteを更新する余力もなかったため、しばらく充電期間を設けていました。

いやまぁ、完全復活するほどの余裕はまだまだ全然ないんですけど、またこれから細々と更新していきたいと思います。

さて。

タイトルにもありますが、あるＩＴエンジニアが顧客に対してこのような回答、態度をとった…というお話です。みなさんはどう思いますか？

「設計書に記載がないことは、不良じゃない」

これはあるテスト工程のお話です。そのテスト…すなわち作ったモノに対する検査・検証の過程で、お客さまから「この挙動は不良だ」「これでは業務が成立しない」と言われた際に、頑として拒否したエンジニアの回答になります。

いえね。過渡期ともなると色々と忙しくて、可能であれば対応したくないのは気持ちとしてよーくわかります。もちろん十分納得させられるだけの根拠があれば、そのことで多少お客さまが困るとしても、まずは「不良じゃない」という事実に対して合意する意味でも説明するのはアリでしょう。

でも、これは違うんじゃないかと。

お客さまが設計書に記載しないよう指示したのならまだ百歩譲って理解もできますが、通常、ＩＴ関係の開発だけでなく専門性の高い分野においてはお客さまが設計書への記載に対して情報を「増やす」ことを要求することはあっても、「減らす」要求をすることはまずありません。

今回の事例でも「顧客が知るべき部分はもっときちんと記載するよう」幾度となく指摘されていました。それでものらりくらりと躱して、設計書にかたくなに記載しようとしなかったのは開発側の陣営です。

合意形成を図るために必要十分な記載を『行わない』と決めるのはいつでもエンジニアの方です。十中八九、お客さまということはありません。もしもあったとしたらそのことでお客さまが損失を被るのは、ある種の自業自得というものです。

とはいえ、完璧な設計書というのもなかなか存在しませんから、抜け漏れというのは往々にしてよく起こります。それはお客さまがレビューをしても同様です。専門性の高い設計書なんて、よほど懇切丁寧に説明を受けなければお客さま側がすべてを理解し、すべてに対して指摘し、すべての品質を開発側の代わりに保証してあげるなんてことは絶対にありえませんし、契約的にもするわけがありません。

設計書に、後々問題の火種となるような記述をしないようにするのも、必要十分な情報を記載しておくのも開発側の責任ですし、その内容や品質に責任を持つのもすべて開発側のすべきことです。

それはウォーターフォールのような開発の進め方であっても、アジャイルのような開発の進め方であっても、PoCのような進め方であっても、派遣契約にでもしない限り「絶対」です。

顧客の要求事項を満たすための管理監督責任がどちらにあるのか、リーガルについてちょっと調べればわかります（まぁリーガルに強いエンジニアってそうそういないでしょうけど）。

もちろん顧客側の責任が皆無ということにはなりませんが、少なくとも顧客は要求事項を提示するのみで、主体的に仕様、設計を検討、提案するのは開発側でなくてはなりません。そこまでくれば顧客が行うのは

　「提示、提案された仕様／設計部分に対する合否判定」

だけです。

いいですか？
重要なことなのでもう一回言いますね。

　「提示、提案された仕様／設計部分に対する合否判定」

だけです。
提示、提案されていない部分に対して…すなわち、隠匿された内容に対してお客さまは合意ができませんし、承認もできません。する責任もありません。契約書と同じです。書かれていない内容に対して何もできない契約相手へ「空気を読まないヤツが悪い」といって責められますか？

しかし、それを平然と言ってのけるエンジニアが顧客の前に立っていたわけです。

さすがに呆れました。
と同時に滅多にわかない怒りもこみ上げてきました。

まだビジネスというものを理解していない若手エンジニアであればそういうイキった考え方をすることもあるかもしれません。そういう人には上司や先輩たちが優しくたしなめてあげて、徐々に改善・成長させていけばいいと思います。

しかし、マネージャーやリーダーといった立場の30代後半～40代半ばくらいの人たちが実際にそのような回答をしたり、実際にする人たちを起用し、認め、目の前で行っていても咎めもせずその場にいるだけ…という状況を目の当たりにしたんです。

普通…とか、常識的に考えて…とか、あまり語気の強い言葉を使いたくはないのであえて「個人的には」と言いますが、個人的には設計書に記載されていない部分があって、設計書に記載されていないからこそ、どのように作れば（実装すれば）いいかわからなければ、勝手に行間を読んだり、脳内保管を行って悦に浸るのではなく、まず

　お客さまに確認すべきではないか？

と思います。

勝手な思い込みで、誰に了解をもらったものでもないモノを「仕様」とは呼びません。自己満足にもほどがあります。あえてこの事象に分類名をつけるなら、私なら

　『仕様検討漏れ（or誤り）』
　『設計誤り』

と名付けます。
決して「仕様通り」とするようなものではありません。

そうでなくてもお客さまは辟易するはずです。
自らの望む要求仕様ではない結果を良しとするお客さまなんて存在しませんし、その結果お客様の業務やビジネスに支障が出たら本末転倒です。契約次第ではこの態度や思想自体が「債務不履行」となりかねません。

エンジニアリングが何のためにあって、誰のお金でディベロップメントさせていただいていて、どうすることでそのお金に見合った価値提供となるのか、まずはこのビジネスの基本をきちんと意識したうえで「技術」を駆使していただければと思います。自らの活動、その活動による報酬が「何を実現する」ことであるのか正しく理解しましょう。

「技術」はただの道具でそれ自体に良し悪しはありません。

良し悪しはいつの時代も「人」の考え方や思想によって付け加えられるものだからです。だからこそ、「技術」だけではビジネスにならないこともあるということは知っておいていただきたいと思います。

そしてこれを読んだエンジニアのみなさんのなかでおかしな発想、考え方へと進まないための一助となれば幸甚です。