大企業の開発者がこんな酷いレベルだという恐怖 #4

この話は、以下のエントリからの続きのストーリーです。
最初から読んでいただけると、より理解しやすいかと思います。

まさかの現実、そして幻滅

もうねぇ……。呆れた。そして悲しい。
ただただ、軽蔑と、悲しみだけが残ったよ。
この世には「開発がうまくいく事よりも、他者にマウント取る事の方が大事」と思っている人間が実在する。この現実に僕は打ちのめされた格好になった。

「口出しするな」と言う開発に困る我々

前回の最後の方に書いたのだが、とにかく
「当たり前の事を、当たり前にやってますよね？」
と聞くと開発は
「口出しするな」
というリアクションだったのね。

でも「はぁ、すいません」ってワケにゃいかないのよ。品質が悪くて被害を被るのはこっちなんだからさ。

そこで私は考えたのです。
自分と同じ会社の社員が、開発の中にも入っているのね。

うちの会社から、開発の方にも社員が派遣されている

この人（図中 A さん）をアンカーとして活用して、中から運用ルールの改善提案をしてもらえばいいのではないかと。
要は部外者がぐちゃぐちゃ言うから腹が立つんでしょう。「中身も知らないくせに！」とかなるんでしょう。
だったら内部からジワジワやってもらったらいいかなっていう単純な話。
名を捨て実を取る作戦ね。

そこで自社の営業と A さんとでお話したんですわ。

とにかく今の開発はクソすぎるから、中から変える努力をして欲しい事を伝えて。
都度つど現状を情報共有して欲しい旨を伝えて。
政治的にハードルが高いならこっちの営業会社からもできる限り支援するよと伝えて。
自社の人間の提案で品質が向上すれば、それは自社の企業価値向上でもあるわけだから営業と開発も一丸でやって行きましょうなんて確認までして。

ね。偉いよ俺は。

A さんも「分かりました、できる限りやってみます」なんて答えてくれて。

その時は「自社の人間はまだマトモ」と思っていたからさ。
まさか目の前で「分かりました」って答えてる人間が、どうにかして俺を排除したがっているなんてね。その時の俺には知りようがない話。
おっそろしい話だろぉ？

社内の進め方は内部で連絡取り合って

その打ち合わせで「今後、 A さんと現場のメールで連絡取り合って、今の話進めて行きましょ」ってな感じで打ち合わせは終了。

よーし、なら改善ポイントはどんどん指摘してあげなくちゃ！ 今まで中にいた人は、どこから手を付ければいいか分からないだろうしな！

1 週間に 1～2 通ペース、 3 週間で 4 通の「改善ポイントメール」を出したんだよね。
ちょっと A さんの忙しい時期だったので、ちょっと落ち着くまでアクション取れないらしいの。
うんうん、いいよ全然。急速に変えられないのは分かってるからね。ゆっくりやりましょう。手隙の時にやってください、なんてメールで伝えてたんだよね。

全く文面に攻撃的な要素なんて無いのね。
まぁ「俺からの指摘メール」って時点で多少の圧はあるかもしれんけども。
いつまでにやるんだとか、なぜやらないんだとかは言わず、他の人がこうしてるからこれを統一ルールにしてみんなでやるようにした方がいいですよ、とかそういう優しい～書き方してんのね。
俺の「やさし～」を意味深に受け取らないでね。他の人にも読んでもらったけど、その人も問題ある文面じゃなかったって感想なのさ。

つまり、俺は事前の自社打ち合わせの通りに着実に仕事してたの。

敵は社内にいた

一向に A さんはアクションを起こさないまま日付だけ過ぎて……。
自社打ち合わせから 1 ヶ月、今度は営業が俺だけを呼び出してきた。
何の話だろうか？

営業「いや、実は……ま、ちょっと変な話だと思うだろうけども……」

ちょっと切り出しにくそうにしながらも、すぐに二の句を継いでくれた。

営業「 A さんが、君からの指摘メールで業務が滞るから止めさせてくれと言われたんだよね」

ぐにゃあっ……

それを言われた時の俺の悲しみたるや、想像に難くないでしょう？

なんてことだ……なんてことだ！

俺の指摘が正論だもんだから、言い返せなくて、だからメールの返信も打ち合わせもしなかったのか……。
言い返せないのは負けだと思いこんでる、よくいるネットイナゴと同じ精神構造……。
反論できないから、立場をつかって営業経由で黙らせようとする、そのクソマインド……。
業務改善するよりも「俺はここのボスだ」と威張り散らす方が大事だと思っている人間が、確実にこの世に存在してしまうことが分かった……。

敵は、社内にいた。

A さんは開発を改善しようと思っているワケじゃなかった……。
クソ開発をクソ開発たらしめているのは、 A だった……。

「改善策」よりも「自分のポジション」

改善していって業務を滞りなく実行する。コレは言うまでもなく大事なことだよね。
だけど改善策を提案されるのは困ると A は言うんだよ。


それは、なぜ？

改善提案してくれるありがたい社員なんて、そうそういないよ。だけど、わざわざ営業使って黙らせる。


それは、なんのため？

答えは、1つしかない。
「うまく仕事進めるよりも、自分のポジションが大事」
だから。
そんな技術者、いるわけないと思ってたけどいたんだよね。目の前に。

改善策を実行しないのは、私に指図されている構図になるから。
私のメールに直接回答しないのは、私の案が正論で言い返せない、言い負ける事が分かっているから。

見せかけでボスづらするの、そんなに大事かね？
技術力無いの会話してすぐ分かるんだから、そんなに見せかけにこだわらなくていいよ。

マルチスレッドで各スレッドがフォルダ作っちゃって、後で実行する方がエラーになるっていうアホみたいなバグに対して、君が言ってた対処法は忘れないよ。
「失敗したらリトライして、それでも失敗ならエラーにすればよかったですね」
だってさ。
うーん…… synchronized でやるんじゃないの？ ってその場で聞いたら、鳩が豆鉄砲撃たれたような顔してたね。

技術力ないからこそ、人一倍マウント取りたがるのかねぇ。
わからん。
ギリギリ人類に分類されてるこういった類いの思考回路は、わからんわ。

要求と要件

話は前後するが、私は営業会社側の「ソフトウェア改修要望」をまとめる係りの一員としてしばらく作業していたのね。
実際に使っている顧客要望を取りまとめて、優先度つけながら開発に要求投げていくんだよね。

「営業経由で黙らせ事件」より 1 ヶ月ほど前から開発とは打ち合わせを重ねていたんだけど、まーーーこれがお粗末。
全然開発が「自分たちが何をすべきなのか」が分かってない。
たぶん知らないんだろうね、本当に。今までやったこと無い人達ばかりなんでしょう。

そうなるとマネージャーの責任なんだけど、そのマネージャーも全然「マネージャーが何をすべきか」が分かってないから、もう八方塞がりなの。

要求とは、要件とは

ちょっと詳しい話わかんねぇっす、って人向けに軽く「要求」と「要件」を説明するね。
別に聞いても分かんねぇからいいやって人はこの項軽く読み飛ばしてくださいな。

「要求」は、顧客が望む大雑把な事柄。
「要件」は、その「要求」を叶えるためにソフトウェアのどこをどう修正しなきゃいけないかリストアップしたもの。

たとえば
「新東名を作って欲しい」
が要求。

技術者は、それを聞いて「要求分析」をするんだよね。
「なんで新東名欲しいんですか？」
「今の東名は渋滞がひどすぎるし、台風くると静岡で通行止めになるから」
「一応中央道あるから名古屋からなら中央道経由でも東京付きますよね？」
「そうだけど、遠回りだし、山だらけでアップダウン激しくて速度落ちるし嫌なんだ」

なるほど、顧客が求めている物は大体以下なんだな、みたいに整理つけて行くのよ。

• 渋滞解消
• 距離短縮
• 天候で通行止めになりにくい
• アップダウンは激しくないのがいい

で、この分析した要求を「要件」にしていくのね。専門家だからこそ「どのように対処すれば要求を満たせるのか」ってのは判断できるわけだからね。

• 渋滞の原因となるサグをなるべく作らない
• トンネルを多用して距離は短くなるように
• 通行止めになりやすい海沿いルートは避ける
• アップダウンは最大2‰に留める

ソフトウェア開発者は、この「要件」を作っていく必要があるんだよって話。

要件化の打ち合わせ

というわけで、要件を作るには、そもそも「なんでその要求がでたんだっけ？」ってのを開発者が聞き出さないといけないんだよね。
で、一旦うちら営業会社は開発に対して要求資料を出すワケ。
○○がしたいですよー、なぜなら△△だから〜、みたいなのを並べてるだけなんだけど。

本来開発が最初に気にするのは「なぜなら△△だから」の部分。
もし客の要求よりももっと適切な（もしくはもっと工数的に安く）できる方法があれば、提案する必要があるから。

それはこっちも分かってるから、なるべく開発がやりやすいように簡潔に整理して資料を作って渡したの。
で、それから 1 ヶ月の間、 1 度たりとも質問してこない。
おかしいでしょ？　要件の細かいところ、絶対すり合わせが必要な箇所あるでしょ、普通なら。
大丈夫なのかなぁ……と思いつつ、開発との最初の打ち合わせに。

開発から発せられた第一声は、信じられない物だった。

「じゃ、まずこの資料について説明して」

この 1 ヶ月、 1 回も要件のすり合わせをしに来なかった事が問題だと思っていたよ、さっきまで。
でもそれ以前の問題。要求が何なのか考える事すらしていなかったんだなぁ……。

要求を要件化するのは開発の仕事だろ

さらに我々を困惑させたのは、開発が「要件化」ということを良くわかっていないという事だった……。

たとえば以下のような要求をしたとしよう。
「ここの文字色を白にして欲しい」

となるとソフトウェアの修正箇所としては
「フォント設定を白にする」
となるよね。

でもさ、たとえば元々の背景色が白だったら、文字色もそのまま白にしちゃったら文字読めなくなっちゃうじゃん？
だからこの「文字色を白にする」という要求には「背景色を濃い色にする」という要件も含まれているワケ。
これは本来開発者が「背景色は濃い色にしますよね？」って要求元とすり合わせるべきなのね。なんでかって言うと「その変更を入れたときに画面や動きはどうなるか」を考えるのが開発だから。素人が考えてもしょうがないでしょ？ソコをさ。

システム的観点、仕様的観点から実装しなきゃいけないものを洗い出す。
要求元が気付かないポイントを修正箇所としてリストアップし、理由を説明する。そしてその修正に納得してもらって、お金を払ってもらう。
「要件化」の目的って、つまり「何に対価を払ってるのかを明確にする」ってことなんだよね。折り目正して、真っ当なビジネスをするために必要な過程なんだよね。

でもね、この開発は「要件化」の役割を誰が担うのか良く分かってないのさ。
だから例えば我々が「文字色を白にして」って言ったら、そのまんま「ここを白にします」みたいな資料を作ってくるんだよね。
でもこっちがそれ見て「背景色白っぽいから読みづらくなるので、背景色も変えてください」って言うじゃん。
すると、信じられないことに「新しい要求ですね」とかブッこくワケよ。

はあぁぁぁ？？？
要求と要件の違いも分からねぇクセに、なぁーに偉そうに受け答えしてんだよボケがぁ！
って気分になるじゃん、必然的にさ。

その後
「どの背景の色変えたらいいか分からないから、変える場所の資料ください」
とか畳み掛けてくるわけ！

はあぁぁぁぁぁ？？？？

どの背景の色変えるか考えるのは、お前ら開発だろうが！

いやホントに。
仕事わかってないくせに、なんかやたら偉そうにするんだよね。なんでそんななのか意味不明だけどさ。せめて自信を無くしてくれ！ お前らは仕事ができてないんだぞ！ わかってるか！？

出てくる要件定義に頭を抱える

まぁそんなこんなでストレスを感じる打ち合わせをしつつですよ。
その打ち合わせから 2 週間経って、ようやく「要件定義書」と称するドキュメントが開発から出てきたの。

その中身を見て、頭を抱えるしかなかった。いや、正確には笑ってしまった。あんまりにも要求を分かっていない。そのくせドキュメントを作るもんだから、まるごとドキュメント作成時間が無駄。
何考えてるんだ、コイツら……。

まぁ何も考えてないんだろうけど。

結局要件分析できてない

こちらの要求の 1 つに「 UI の改善」があった。
モバイル側の機能の 1 つとして「イベント編集」ができるんだけど、この導線がとんでもなくクソだったの。

編集に至るまでに

• イベント一覧
  ＞イベント選択
  ＞メニューから「詳細」
  ＞イベント編集
  ＞テキストボックスがズラっと並ぶので、編集したいところまでスクロール
  ＞テキストボックスをタップ

っていう工程を踏まないといけない。
コレ、使いづらくて仕方がない。実際、使いづらいせいでお客さんは使ってない。これ直してよって要求をしたわけ。
具体的に、イベント一覧の画面から編集したい項目をタップしたら、その画面内で直接編集できるようにして、とまで補足として言ったのね。

UI の設計方針すり合わせなし

ね、普通これ言われたらさ、 UI の良し悪しなんて人それぞれなんだからどういう方針で作りますかとか、画面戻るのボタン配置ここでいいですかとかさ、大枠から細かい話まで詰めてくもんじゃん。いや、そういうもんなのね。

だけど開発からの確認や質問はゼロ。
どうやってこちらと意思疎通するつもりなのか知らんけども、まぁ出てくるものがマトモなら別にいいんだ。

だけど、結局最初出てきた案はゴミみたいな案。
「既存の編集画面にサムネイルをつけて、編集箇所が分かりやすくなるようにします」
いや待てよと。
確かに編集箇所が分かりづらかったかもしれん。でもそこじゃなくて画面遷移がクソだって話したじゃん。だから一覧から直接編集する話もしたじゃん。なんでそれが抜け落ちるのよ。

「それやると工数がかかるので、別案を持ってきました」
はぁぁ？？？
バカかよ。工数がかかるからやるやらない決めるのは要求元なの！！ おまえらじゃないの！！

代案出すなら要求を理解しないと

ていうか、普通は工数がかかるなら「言われたとおりのだとコレぐらいかかって、こっちだとコレぐらいで、効果は同等ですよ」みたいなね、話の運び方があるでしょうよ。
元の要求との効果比較とか全くして無いし、もう話にならないレベル。
要するに要求を理解してないんだよね。

代案をこっちが出してあげる

代案出してこれないんじゃ仕方がないから、営業会社のこっちが代案いくつか出してあげた。まぁ俺が考えた案だけど。
普通そんな協力的な会社ねぇぞ！？

それを受けて開発が要求に近い案を出してきた。けどまだ使いにくい部分があったので、今度はこっちが画面遷移図まで作ってあげた。まぁ俺が書いた図だけど。
普通そんな協力的な会社ないからね！？重ねて言うけども！

それでようやく開発の実装方針が正しくなった。要件化にはここから色々調査が必要だと思うけど、要件のすり合わせ部分はめちゃくちゃ協力したんだから頑張ってくれ。

意図的に捻じ曲げてくる

実はモバイル側の要件はまだカワイイ方なんだよね……。
問題は Web サービス側。こっちは本当に、ビジネスパーソンとして最低な振る舞いしてくるんだよ。

散々説明したのに無視した資料が来る

こちらの要求の 1 つに「検索機能の追加」があったのね。
イベントがたくさん溜まってくると、もういつどこへ行ったかなんて覚えてないワケ。しかもイベントずらーっと並んで見つけにくいし。
と言うわけで「 Google 検索みたいにイベント検索できるようにして欲しい」って要求投げたの。

イベントはツリー構造になっていて、何かのイベントの子イベントみたいなのが作れるのね。最大6階層。
だから 1 つのテキストボックスに入力したい文字列で、階層のどこにいてもヒットして欲しいよね。

最初に資料を渡してから 2 ヶ月、打ち合わせを 4 回実施して、出てきた要件定義書見てブッたまげた。

「 1 つの検索ボックスで横断検索すると、短い検索ワードの時にたくさんヒットしてしまいます。逆に使いにくくなると考えましたので、各階層ごとの検索ボックスを置くようにしてはどうでしょうか」

もう、お口あんぐり。バカと会話するのは、本当に疲れる。
打ち合わせで何度も何度も「検索ボックスは階層ごとに分かれていると不便だから 1 つで横断検索できる事」って言ってんだよね。言っててなお無視してくるんだよ。頭おかしいでしょ？

つまり、意図的にこちらの要求を無視してんだよね。自分たちが楽になるように、こうやってゴリ押しすればいずれ要求なんて無かったことになると画策してんだよ。
そしてこの、意図的に要求を無視しているのは誰あろう A その人なんだよね。
マジクソ野郎。ここまで下劣な人間と仕事で関わるのは初めて。それがまさか自社の社員だなんてね。

A は本当に人間のクズだと思うわ

当然、要求満たせないのでNGを出すと信じられない結果に

開発の代案は、当然要求を満たせないので NG ですわ。
だって、なんでお客が「あれ、このイベント第 1 階層だったっけ？ 第 2 階層だったっけ？」とか考えながら検索しなきゃいけないワケ？ 少し考えれば使えないって分かるやん。つまりちっとも考えてないってことやん。

よく分からない確認をされる

NG って言うと「でもたくさんヒットしてしまいますよ？ いいんですか？ 本当にいいんですね？」って聞いてくるの。
誰も、何を心配しているのかまったくわからない。営業側は「いいよいいよ、別に」って答えてたんだけど、そこをグッと押しとどめて私が念押しの確認。
「開発側が何を心配して言ってくれているのか分からないんですけど、どういうケースを心配されていますか？」

後で言い逃れの材料にするために決まっとる

ま、俺が念押しで聞いたのは、このままOKだけ伝えると「白紙委任状」みたいに使われて揚げ足取られると思ったからだけどね。
たとえばリリース後の不具合を「この打ち合わせで OK した」とか言われる材料になると困るから、何について言っているのかはハッキリさせておかないといけないなと。曖昧だと、後から何とでも言えるよね。
「この危険性は伝えていました」
とかさ。それを封じたいだけ。

もはや開発の言ってる事は、何も信用できないし、端々まで気をつけていないと揚げ足取られかねないので気をつけないといけない。
うーん、悲しいねぇ。

結局、特に心配する箇所は無かった

私の念押し確認に対しての回答は、なかなかイカしてた。
「いや、たくさんヒットしたら探しにくいかなと、それだけです」

ばーーーーーっか！ バカ！
同じ言葉を何度も繰り返すんじゃねぇ！
そら短い、使いがちな単語で検索したらたくさんヒットするに決まってんだろ！ そういうときのために AND 検索もできるようにしろって要求してんだよ。
結局、特に心配なポイントは無いんだな。でも「本当にいいんですね？」とか言っとかないと代案を出した事に対する格好がつかないから、さも大変な事かのように表現したかったのね。

まぁそういうワケで、あまりにバカげた理由で出てきた代案だったのでサクッと却下に至りましたとさ。

問題は、この後。
この打ち合わせの議事録を A が取っていたので、それがメールで展開された。その内容がトンデモなくひどかった。

「営業のせいで開発側が手戻りした」と言いたげな議事録

A の作った議事録が出てきて、私を含め営業側は全員イラっとした。

• 営業からの追加要求あり
• 開発は要求分析からやり直し
• 検索についてユースケースは整理しきれていないが営業側はOKの判断
• 顧客向けのデータ登録にも対応が必要

このような文面がちりばめられている。

これらは、すべて以下が正しい。

• 追加要求ではなくて、要件化のすり合わせ
• 要求は何も変わっていないから、分析し直す必要性なし
• ユースケースは整理されている。言ってないことを議事録に書くな
• 顧客向けのデータ登録には何も影響はない。言ってないことを議事録（ｒｙ

ついにブチ切れる営業さんサイド

事ここに至り、もはや我慢のならない私は議事録の事実歪曲ポイントすべてを洗い出し、赤を入れた。それを営業さんに渡し、多少マイルドな表現に姿を変えつつも、開発宛てに送信してもらった。
もう営業さんサイドとしても、我慢の限界が来ているんだよね。でも今までは専門知識がなくて、戦うに戦えなかったというのもあるんだよね。徒手空拳で、腕振り回しても相手がバカすぎて全然響かないの。マジで今までご苦労様でした。
あなた達が SE を雇ったおかげで、ようやく戦う武器が手元に来ましたね。

いやー、しかしやっぱり営業さんは精神力が違うよ。怒ってても、冷静だもん。
だってひどいんだぜ。開発の要件定義漏れも 1 つあったんだけど、それに対して「要求分析からはじめます。一週間後に分析結果の資料を出します」なんてナメたことぬかしてんだよ。
意味わかんねぇでしょ？ 開発側のミスで抜けてたんだよ？ なのに、なーに悠長に自分達のやりたいペースで仕事しようとしてんだよ。アホかよ。ミスを取り戻すリカバリー策を考えろよ。

その後、打ち合わせで決めた期日通りに宿題を提出する営業会社と、期日を全然守らない開発にもチクチクとメール攻撃をしてもらったりもした。

開発側は戸惑って「今後の仕事の進め方について打ち合わせしたい」なんて言い出して来て。しかし何のことはない、今までもやってきた「素人相手の脅し文句」を今回も使っただけだった。

「ここで要件定義が終わらないと、このスケジュールは遅れますよ」
「全体のスケジュールを見積るのに 1 週間かかりますよ。全体スケジュールがその分遅れますけどいいですか？」

開発としてはこれでこちらのトーンを少し鈍化させたかったのだろう。
しかし営業側のリアクションは、おそらく予想外のものとなる。

「そうですか。もともと要求していた日付までに何ができるのかだけまとめておいてください」

営業は開発を責めるでもなく、無感情な表情でその打ち合わせを去った。
おそらく、あの開発ではそこから不気味さを感じ取ることはできないだろう。
この後に控えている、異なる戦場での戦いに繋がっていくと想像できないだろう。

俺たちの戦いは、これからだ！……では終われない

営業の怒りは頂点に達し、表情から感情が消えた。
その顔は、いったい何を考えているのか。
決して闘志は失われていない。俺たちの戦いは、これからだ！

……いままでご愛読ありが……ってワケにはいかないんだって！
ここから営業サイドの逆襲劇が始まるんだってばよ。

ん？ 語尾に「だってばよ」って付けるのって、おもしろくね？
流行るんじゃね？ 俺の完全オリジナル語尾。だってばよ。

あー、もう余計な脱線はいいから。

ここからどう話が展開していくのか、続きに乞うご期待だってばよ！

↓続き

大企業の開発者がこんな酷いレベルだという恐怖 #5

私が超大企業で、現在進行系で体験している King of クソ開発の実情をあらん限りの言葉でグチり倒しています。第5弾では、年末年始で起きたありえねー事の数々および軽く人間関係について簡略化して書いています

↓私の一番好きな「ソフトウェア設計とは何か？」を考えるための入門書。
実に分かりやすくタメになる。今でもうちの本棚に置いてある。