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

クソ開発、霧散しろ！

 この話は以下のエントリの続きモノになってます。お時間が許すのならば、最初から読んでいただいた方がより楽しめるかと思います。

年末年始でまた俺のキチゲが溜まる一方

もうね、キッチリ解決するまでは更新しないでおこうかなと思ってたんだよ、このネタは。
だけど「営業の逆襲」は解決までに時間がかかるし、まだ筋道もたってないので俺のストレスのやり場がなくってさ。
グチを少しでも聞いてほしくなっちゃって、また更新することにしましたよ。えぇ。お付き合いください。

ところで営業の逆襲ってどうなった？

以前「営業サイドの逆襲劇が始まる」とは書いたんだけども。
まぁ結論を簡単に言っちゃうと、開発会社を変えるって話なのね。
だけど親会社子会社の関係があって、政治的に乗り越える壁が多いのでジワジワとしか話が進まないんだよね。
だからドラスティックな変化はいまだ訪れず。予定もまだはっきりしたことが言えるレベルにはなってないの。

要件化も開発も相変わらずグッダグダ

開発側は結局のところ何も変わっていないので、すべてが不誠実、すべてが不勉強、何もかもがグッダグダ。
今日は年末年始で起こったそのグダグダの数々を書き散らしていこうかと思う次第。

スケジュールを立てられない

以前のエントリで「要件化ができない」という話を書いたけど、それ以上にそもそも根本的にできてないのが「スケジューリング」。
年末年始の開発の動きは、もうそれはそれはアホすぎて逆にエンターテインメントだった。

結果的に、全体のスケジュールがゴミ

まず結論から書こう。
開発は以下のようなスケジュールで動くことになった。

11/01	要求受け取り
12/11	第1回要件化打ち合わせ ⇒要求元からNGを食らう
12/23	第2回要件化打ち合わせ ⇒要求元からNGを食らう
01/14	要件未決定のまま開発開始
01/16	要件の基本設計レビュー（開発内部レビュー） ★いまココ
01/17	コーディング完了 ⇒まさかの基本設計レビュー後 1 日で実装完了
01/20	IT（内部テスト）開始
01/31	IT（内部テスト）完了
02/01	ST（システム全体テスト）開始（外部委託）
02/28	ST（システム全体テスト）完了

「要件未決定のまま開発開始」というパワーワード。
それ以外にも、様々なイミフのオンパレード。
最後の 1 カ月は ST する風習だと知っているのに 12/11 まで要件化のアクションなし ← 意味不明
要求元から NG をもらっても、焦らず騒がずのんびり要件化 ← 意味不明
結果、要件が固まらないまま開発がスタート ← 最高に意味不明
要件の基本設計レビューを行った翌日にコーディング完了 ← 意味不明
ST を外部委託してるため、この時期に開発が終わってなければいけないことが一番最初に決まる ← 意味不明

もうすべてがグッダグダ。その日暮らしのアリエッティ。
そもそもスケジューリングができるなら、最初の 11/1 に要求受け取った時点で「あと 3 カ月しかないからさっさと要件を詰めよう」って思うハズなんだけどね。早く決まれば、それだけ開発期間が長くとれるんだけど、どうやらそういう当たり前の引き算ができない模様。

ちょっと細かく「ありえない」ポイントを振り返ってみたいと思う。

あまりのありえなさで、握りこぶしに血がにじむレベル

要求を受けても何もしない

11/1 に要求一覧を投げたのね。
ちゃんと優先度を 1 から連番で 13 まで振ってさ。2 月期限だから、間に合わないヤツがあれば教えてくださいね、って言って。

その後開発からのリアクションはゼロ。まぁそれは前に書いた通り「要件化」ができない話の繰り返しになるんで端折るけども。

最初の開発からのリアクションは 12/11、要件のミーティングしましょうって。要求投げてから 1 カ月以上、何も音沙汰がない。
まずこれがあり得ない。
要件化において「要求の詳細ヒアリング＆方向性すり合わせ」は絶対に発生するはず。だって要求してる側は、ソフトウェアがどういう作りしてるかなんて知らずに要求してんだからさ。
だから細かい確認とかが絶対入るハズなのね。だからそれが行われない事があり得ない。

工数見積もりしていないのに「工数オーバー」

さて、いざミーティングが開かれましたと。
事前に何も知らされず、ミーティングの場で「これは工数大だから収まりません。これは収まりますのでやれます」みたいな話をツラツラとするんだよね。
そもそもさ、工数が大きくて収まらないっていうなら、リストアップした要求に対して（精度はさておき）どれぐらいの工数を見積もったのかを回答すべきだろう？ なのにそれをしない。ミーティングで聞いても「個別に工数は出してない」との回答。
ありえねぇ。
個別に工数だしてなければ、間に合うかどうかの判断できるわけねぇだろ。
もしかして、お前ら適当に「うーん、大変そうだからやりたくない」ってレベルで無理って言ってんじゃねぇだろうな？？（まぁそうなんだろうけど）

大学の趣味サークルだってもう少しマトモな見積もり出すだろ。
「やりたくないからパス」って、さすがに通らないのは分かってて欲しかったわ。

要求の理解度も仕様の理解度も低すぎる

そのミーティングで開発が言ってる内容だと、メリットが削られすぎてあまりコストかける意味が感じられなかったんだよね。

たとえば「アップロードした領収書をダウンロードしたい時、 1 個 1 個クリックするの面倒くさすぎるから『まとめてダウンロード』できるようにして欲しい」という要求に対して「元々アップロードした領収書が jpeg の物のみ『まとめてダウンロード』可能。 PDF でアップロードしたものは管理方法が別なので不可能」という回答だったの。
そんなん、実装したって無駄じゃん。 PDF でアップロードしている客だって居るっての。それですでに運用されちゃってるんだからさ。 jpeg だけ落ちてきたとして、結局 PDF が混ざってないかいちいち確認して回るのは変わらない。結局労力ほとんど変わらないってことになる。

だから「顧客の利用シーン」を想像すると、その提案仕様じゃ意味ないって分かるわけ。

そもそもね、要求側だけが「うーん、それなら要らないな」ってミーティングで感じるってことがありえない。
だって、開発の出してきた仕様だと要求を満たせないって「要求元は分かった」けど「開発は分かってない」ってことだからね。
それは要するに「開発は要求が何なのか理解していない」って事と「開発よりも要求元の方が仕様理解度が高い」って事になってしまうんだよ。
なんで要求元の方が仕様理解度が高いんだよ、ありえねぇだろ。

優先度を組み換えたところ……

開発の言う通りに実装すると、本当に欲しいものが落とされて、どうでもいいものだけを実装することになるんだよね。
そんなんじゃ工数かける価値半減。だから、ある 1 つの機能（以降「機能甲」と呼ぶ）を落としていいから、代わりに本当に欲しい機能（以降「機能乙」と呼ぶ）をやる前提で検討しなおしてくれって開発に伝えたの。ミーティング終わった翌日にメールでね。こっちはちゃんと素早くメール連絡ですよ。

実は我々営業会社では
「これ機能甲を落としただけじゃ収まらないかもしれませんね」
って予想はしてて、元々 13 個あった要望のうち究極で言ったら 2 個だけ入ればいいというところまで絞って検討進めておいたのね。機能乙を含めて 2 個ね。プラン B を用意しておくのは普通だと思うわけ。ね。

だけど最初から「んじゃプラン B でやってください」ってのもおかしい話でしょ。もしかしたらプラン A で開発側が「できます」って言うかも分からないし。まぁどうせ出来ないだろうけどさ。
ちゃんと開発からの見解を待ってからプラン B を提案する方が話の筋通してる誠意ある対応だと思うんだよね。だって検討する前から「どうせお前らじゃできねぇだろ」って勝手に削るってのもね、相手がまともな開発者だとしたら少し失礼な話。
お互いが出すべき情報を出せばトントンとプラン B に逃げ込めるように準備しているんだから、開発のためにもなってるじゃん？

で、我々営業会社は待った。開発からの回答を。
回答がないまま、時間は過ぎて年末になる。
開発に口頭とメールで回答を催促すると回答が来た。

まずその姿勢があり得ない。なぜ催促しないと回答しないのか。期日を切ろうとすると嫌がるくせに、催促されないとやるべき事をやろうとしない。いや、そんな姿勢だから期日切られるんだろうが、と思うんだが本人たちは分かっていない模様。

しかも。
しかもだよ。
その回答がサラっとたった 2 行。
1 行目は
「再検討しましたが、機能甲を落としただけだと工数が収まりません」
ふむふむ、そうかそうか。まぁそうだろうね、予想はしてたよ。
で、 2 行目は
「ミーティングでお話した通り、機能乙はドロップさせて頂ければと思います」

は？？？？

結論、そっち？？？ こっちは「他を削ってでもやってくれ」って言ってる事に対して、その他との優先度や兼ね合いなんかも確認しないまま「ドロップしたいです」だと？？
ありえない。ありえなさすぎる。
要求の真意が分かってないのに勝手に間違った結論を出すその姿勢があり得ない。

しかも、どこがどうあふれるのかの説明も無しにだよ。
納得や理解してもらおうって気がゼロなんだな、コイツらは。
営業会社に納得や理解してもらおうって気が無いってことは、すなわち「コイツら、営業会社の事をナメきってるな」って感想になってしまうのは自明の理。
適当に「できません」って言っておいて無視しとけばいいって思ってるんだって見られても、致し方ない所業なんだぞ？ 分かってんのか？

「それは簡単には認められない」と回答すると……

まぁコイツらが無礼なのは今に始まったことじゃないので、怒りを噛み殺して
「それは簡単には認められない。機能甲の工数と機能乙の工数をまず教えてください」
と、営業会社側の SE リーダーから回答してもらう事にした。
まぁこの辺の王道的攻撃は私が言い出さなくても似たような回答を出すことになったと思うが、まぁ少なくとも私は「コレ聞かないとプラン B でいいですよ、って言うキッカケがないですよね」って押してた。

逆にちゃんと工数出してもらって積み上げてもらったら、それを理由としてプラン B に舵を切れるよ。
というか、逆に工数が出てこなければ、いかなる判断も営業会社が主体的に行えないよね。
たとえば「締め切りを延ばす」とか「似た機能は全部まとめてやるかやらないかのどっちか」とか、工数見積もり（つまりコスト）を見てみないと判断できないと思うんだよね。コストとパフォーマンスのバランスが分からんのだから。

なので、「間に合わない」と回答するんだから工数出しているハズで、それをまず教えてもらおうとしたワケだね。本来なら開発側が説明のために出してくるべき情報だけど、まぁアイツらは頭がおかしいから仕方がない。

再び、開発からの回答を待つ。
そして、とんでもない事になる。

メールに回答しない。
これが、開発が選択した方法だった……。

ありえねぇぇぇぇええええ！！
子供か！ 小学校高学年になりゃ「目先だけ逃げても、後で必ず追及される」ということは知ってるわ。お前ら、それでも社会人かよ。よく今まで生活してこれたな。
電車でキセルとかしてないか？
スーパーで万引きとかしてないか？？
それと同じぐらい、社会人のモラル・倫理・ルール・マナーとしてあったり前の話だぞ。

人のことを無視してはいけません。
仕事の質問には答えましょう。

回答しない表向きの理由と、本当のトコロ

実はこの年末年始、大きな不具合が立て続けに発見されたんだよね。で、開発は壊れてしまったユーザーのデータをちゃんと書き戻すのに忙しかったのは事実。

なので表向きは「不具合対応を優先しているため、要件化はペンディングしています」って事になってる。
これは、開発側のマネージャーが社内政治にしか興味がないアホ（以降「開発の政治屋」と呼ぶ）なためこうなってるんだよね。
どういうことかっていうと「開発ができない状態」という大義名分を得ておくことで、まず「いついつまでにコレコレを実装します」という約束をしなくて良くなる。そうなると、できなかった時の責任を問われることが無くなる。なのでできるだけ誰にも知られずに開発作業ができるんだったら、それに越したことがないワケ。開発の政治屋にとっては。
でもさ、それだと営業会社の要求（つまり顧客のニーズ）と噛み合わない物を作ってしまうことになるよね？
うん、そうなんだ。それでいいんだ。
「顧客のソリューション」を作る気はまったくなくって「誰の役に立つかは分からないけど、コーディング作業はしている」という開発のトップで偉そうにしたい。ただ、それだけの人なのだよ。
本当にいるんだね、そんな人が。この世には。世界は広い。

まぁそんな開発の政治屋のせいで、表向きは要件化作業がストップしていることになっているんだ。
しかし実際のところ、開発全員が不具合対応をしているワケではないから、不具合対応をしていない人間の工数が余ってしまう。
でも要件は固まっていないのに「ペンディングしている」ことになっているから話が進められない。
不具合対応は全員をつぎ込む程の作業ではない。
余っているから遊ばせておくというワケにもいかない。

結果、最高にイミフな行動、すなわち「要件未決定のまま開発開始」についに結実するのであった……。

ありえねぇぇぇぇぇ！ マジであり得ない。あり得なさ過ぎて、さすがに IT 業界あるあるトークでも聞いたことねぇわ。
だってさ、何つくるか決まってないのに作り始めるって言ってるんだよ？ 何回日本語で説明しても、どんなに言葉を変えても意味不明なことが揺るがないよね。それぐらい意味不明なんだって。

まぁなんでそれを知ったかっていうと、開発側に新しく自社社員（以降「土管くん」と呼ぶ）が増員されて、そこから俺が情報もらって知ったんだけどさ。

自社の開発サブリーダーにも伝えているのに何もしない

以前のエントリで書いたけど、自社の社員 A さん（a.k.a 人間のクズ）が開発のサブリーダーで入っているのね。コイツがクズなのは良く知っているので、俺から情報を入れても意味がない。聞く耳もたないからね、あのゴミは。
そこで営業会社にいる、もう一人の自社の人（以降「もっさん」と呼ぶ）から A さんに情報を流してもらったのね。

人間関係が複雑になってきたので整理

もっさん「今、要件化が止まってると思いますけど、前回の打ち合わせを受けて営業側の要求に変化があります。要件化が再開する時に、一旦要件化のミーティングをやって再度整理しましょう」

「土管くんから情報抜いてる」ってのが A さんに伝わると、土管くんがどんな嫌がらせされるか分からないし、今後情報を抜き取れなくなるかもしれない。だからそこは伏せながら「実は開発してる」は知らない体で。
それでいて「あ、結局要求は優先度が変わっているのか、ならば最新情報を仕入れないと無駄な開発作業をしてしまうな」と気付くに十分な情報を与えているんだよ。

いやー、やさしいと思わん？
実にやさしいよ。相手が自主的に気付いた、みたいな風に振舞える余地を残しつつ、開発側にダメージがないようにしてあげてるんだからさ。
一度 NG 出した要件で闇夜に走り出している開発に、大きくブレーキを踏んでもらういいキッカケを与えてるワケです、我々は。
せっかく手を動かすんだから最大の効果がでるようにしたいしさ。効果がでるプランを共有して、お互いに利益ある手を打ってくれよと。

しかしやはりクズはクズ。
A さんは「わかりました。明日か明後日にはミーティング開けるようにします」とメール返答して、そこから何もしないまま 4 日が経過した。
どんな障害があってミーティングが開けないのか知らないけれどさ。こちらが「今のままだと開発側が大きく手戻りするんだぞ」という意味の情報を伝えてあげても、それを有効に使えないって事だよね、結果的に。
そして、最低限、人としてさ、メールで情報くれた人に「明日か明後日には」って言ったんだから、ミーティングが開けないなら開けない理由を伝えるのが当たり前でしょうよ。

結局、我々がどんなに配慮して、どんなに情報を与えても、中にいるヤツがバカだと何にも意味がないってことだよ。

次回はついに自社内での争いについて

今回書いた年末年始のグッダグダと平行して、自社内での争い（俺 vs A さん）もスタートさせていたんですよ。
それについてはまた次回詳しく書きますけれども。

軽く触れておくと、人間のクズ A さんのさらに上の上司に直接 A の所業を報告した顛末の一部始終ってカタチになります。
うちの会社は小さいので、 A さんの上司は部長であり、会社の取締役なんだよね。だからココより上はアピールする先がない。
一応平行して営業部長（この人も取締役）も一緒に報告あげているし、一緒に話しているんだけども。

ココに響かなかった場合は、もう俺がこの会社のために頑張ってあげる理由も改善策をたくさん出してあげる理由もなくなる。だから辞めるだろうね。
これは現在進行形で、 4 月あたりに一応結論らしきものは出る予定ではあるのだが。

さてはて、俺が転職先を探し始めることになるのかどうか……。これは見ものだなと、我ながら思って過ごしております。

このエントリの続き

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