LoginSignup
86
55

新規開発したらオーバースペックだった件、原因は意外なところにあった

Last updated at Posted at 2023-11-30

この記事で伝えること

・要件定義の大切さ
・運用不振でも、開発したことに自信を持つこと
・毒親やパワハラを引きずってないか自問する

注:この記事で伝えていないこと

・技術情報
・コピペして使えるコードサンプル
・要件定義書の具体的な書き方

出来事の経緯

開発したシステムは電子入場管理システム

システムの開発理由と目的は、社内スタッフと現場イベントスタッフの

  • コスト削減
  • 業務効率化
  • 紙チケットの転売防止

以上を目的としていた。しかし会社の業績が風前の灯火だったため、このシステムを作ったところで直接の売上につながらないことは明らかだった。

しかし「クライアントの言うことは絶対」という空気感も感じていたため、開発することに。

LAMP環境にLaravelとBreezeを使い、コスト削減・業務効率化・転売防止を実現するため仕様を策定した。

本来ならSMS認証を入れたかったが、クライアント側で稟議が通らず。

それでも入場チケットを転売や譲渡されづらいよう、現場スタッフが不正利用しないよう、私なりに懸命に取り組んだ。

クライアントに進捗報告もマメに行い、おおむねよい評価もいただいていた。

その結果は...

開発物は大きな納期遅れもなく納品。

クライアントとは業務委託契約を締結し、開発と開発物の最低限フォロー以外しないことにした。

会社を去って1ヶ月たった頃。クライアントから連絡があった。

「現場導入したが結果が思わしくない。この要件でシステム改修してほしい」

私は要件を確認し、その内容に私は怒りの感情が込み上げてきた。

課題解決どころか墓穴を広げるクライアント

具体的な内容は、

  • チケットのメール認証廃止
  • スクリーンショットを配布させないために実装した表示時間期限を10秒から60分に伸ばす
  • 同一チケットを再認証したらエラー表示するのではなく、メッセージつきで認証OK画面を出す

つまりクライアントの要件を満たすために頑張って実装した不正対策は無駄だったのだ。

それどころかクライアントは不正リスクを容認し、最悪売上が落ちる選択を取ろうとしているように見えた。

「ふざけるな!これじゃ転売譲渡し放題じゃないか」

このままでいいのか。

私は冷静になり、そして気づいた。

「開発者は言われたとおりに実装すればいいし、相手がシステムを使って生じた損害に負い目を感じることはない」と。

なぜ私がその境地に達することができたか?

この先の文章が社内SEされている方のお役に立てれば幸いです。

この出来事の本質的な原因は?

開発初期のドキュメント共有が不十分

当時この案件を進めていたときは要件定義書・外部設計・内部設計を作らずに進めていた。

まともなIT企業ではまず開発内容を文字とビジュアルで明確にして残る形にするのだが、

社内SEはいきなりカイハツしがちなので、いきなりステーキよろしく後々問題になりかねない。

クライアントとのパワーバランス

いかにクライアントと対等な立場、安全な距離間をとれるかが開発者として問われる。

クライアントのオフィスに常駐して働いていたときは「経営者視点を持て」「他部署のトラブルを自分ごとととらえよ」という社風があった。

これはマネジメント職を目指すなら関係あるが、開発のスペシャリストには必須ではないのでは。

開発で結果を出したことに自信を持っていいし、その後の運用で結果が出なかったことを過度に憂うのもどうかと思う。

しかしインハウスSEだと他部署の運用不振が給料やボーナスに響いたり自分の責任に感じてしまうこともあるのでは?

私は「要件どおりに作ったが稼働後の運用成果が上がらない」社内システムをいくつも担当し、閑古鳥が鳴く様子を見てきた。

私自身が毒親の毒を抱えながら仕事していた

私はかつて毒親のもとで育った毒親育ちで、他人との適切な距離のとりかたを学べないまま育った。

これが災いして過度にフレンドリー(かつDVな)上司や企業に当たることが多かった。

今回のクライアントも、実は過去トラウマになるような経験があった。

あるときクライアントの会社に所属していたとき社長本人から電話がかかってきて

「俺の指示は常に最優先だ!すぐやってすぐ報告しなきゃダメだろ!次から改めろ」

と激しい口調で言われ脅された経験がある。

この経験がもとで「社長の言うことは絶対」という不健康な信念をもつきっかけとなった。

当時、毒親育ちごっこの延長をやっているとは気づかずに。

この出来事から学んだ点は?

要件定義を残す、動画と音声も活用する

要件定義書を作って残したり会議を録画録音しておくことで、気まぐれ仕様変更されないように対処することが可能。

なぜなら開発者と営業(場合によっては現場)とでは、言った言わないトラブルが生じやすいからである。

また相手によっては文章やビジュアルだけでなく、口頭で伝えないと届かない場合があるので厄介。

この点についても今後は、AI動画生成ツールを使った音声入りドキュメントで営業系の人とのミスコミュニケーションが減らせると個人的には期待している。

技術を磨くだけでなくメンタルも磨く

メンタルを磨くことで仕様変更や人間関係のストレスや想定外を減らし、生産性を高められる効果も期待できる。

メンタルを磨かないと仕様変更のたびに心折れて「やってらんねー!」と暴飲暴食・衝動買いの原因になり給料日前にお金がない悩みを抱えやすくなる。

依存関係を手放す

「クライアントの言うことが絶対」かつ時間やお金の自由を奪う毒親のような存在になっていないか、定期的に関係を見直す。

また私含めITエンジニアは他人をあてにしない傾向があるが、もし同業者でメンタリング(カウンセリングやコーチング)できる人がいれば活用しないのはもったいない。

かくいう私も転職や人間関係を社外メンターに相談したりモデリングできる人を見つけてから状況が変化していったので参考になれば幸いです。

ここまで読んだあなたに

もし親や上司やクライアントとの人間関係に辛さを感じたり、なぜかブラック企業に当たりやすいと感じているなら、私が作った「毒親育ち診断プログラム」も活用してみてください。

診断はこちら(結果確認は会員登録要、すべて無料)

86
55
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
86
55