43
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

この記事は【マイスター・ギルド】本物のAdvent Calendar 2021、17日目の記事です。

はじめに

お客様は神様です。
私はそう教えられて、育ってきました。
そして、この教えは後世に伝えなければなりません。
私は慣れないキーボードと向かい合い、この物語を書き上げました。

この物語は、お客様がいかに神様であるかを世のエンジニアに伝え、神様のためのシステム開発を全うさせるために書きました。
この物語を読み終える頃には、

あなたはお客様の神様っぷりを理解し

神様の真理を理解し

どうすれば、その期待に応えられるかを理解できている

ことでしょう。

自己紹介

株式会社マイスター・ギルドの芝田と申します。CTOをやっています。
昭和51年生まれ。 小学校5年生からプログラミングを始め、現時点でのプログラム歴は現在35年。 根っからの開発好きです。 就職してからのシステム開発の経験としては24年ほどになります。 キーボードを叩くスピードは、かなり速い方と自負しておりますが、その半数くらいはバックスペースキーの連打です。

免責事項

物語が3つくらい出てきますが、どれもフィクションです。
登場人物は、架空であり、モデルすらいません。

お客様
大阪の商売人で、35歳。いわゆる神。
新米SE
この業界にきて約1年のSE。25歳。他の同期よりも僅かながら出世に遅れをとっている。
熟練SE
この道15年のベテランSE。過去に30個はシステム開発を経験してきている。所謂フルスタックエンジニアで、炎上案件も慣れたもの。

エピソード1 「神の要望」 〜 金のメッセージを手に入れろ 〜

ここは在庫管理システムの開発現場。
お客様には要望があるようです。


システム 「在庫がありません。」

お客様「なあ、新米!このメッセージ、金色で表示してくれへんか?」

新米SE(なに〜〜〜??金色やて〜!そんなんできるかいな。)
新米SE(まあええわ。黄色にしといたらそれっぽく見えるやろ。)

新米SE「ポチポチポチ・・・」
新米SE「・・・・・」
新米SE「できました!」

システム「在庫がありません。

お客様「いや、見にくすぎるやろ!こんなん読めるか!」

新米SE「え、でも金色って言いましたよね?一番近い黄色にしてみたのですが・・・」

お客様「でも読めんものは読めん!」
お客様「ワシが言ったのは金色じゃ〜〜〜!」

熟練SE「どうかしましたか?」

お客様「あ、これは熟練さん!このメッセージを金色にして欲しいんです!」

熟練SE「うーん。金色ですか〜。」
熟練SE(きっとこれは・・・・)

熟練SE「カタカタカタ」
熟練SE「・・・・・」
熟練SE「できました!」

システム「在庫がありません。

新米SE「え?あ、これ、え?ちょ、金色じゃなくて赤色じゃないですか!」

お客様「おお!これやこれ!これでええわ!」

熟練SE「でしょ?(えっへん)」

新米SE(いったい、どうして・・・・)

エピソード2 「神のみぞ知る」 〜暗号を解読せよ 〜

お客様「ここを、バー!っとやってやな!」
新米SE「なるほど。ここをバー!っと。」

お客様「それからここを、ガー!っとやってやな!」
新米SE「なるほど。ここをガー!っと。」

お客様「それからここで、ばーん!や!」
新米SE「なるほど。ばーん!と。」

新米SE「承知しました。では、そのように作りますので。」

新米SE(まずは、ここをバー!っと。)
新米SE(で、ガー!っとして、)
新米SE(最後に、ばーん!とすれば・・・)

新米SE「ポチポチポチ・・・」
新米SE「・・・・・」
新米SE「できました!見てください!」

お客様「どれどれ・・・・」
お客様「違うやないか、ここは、バー!っとや!」
お客様「それから、ガー!となって、ばーん!や!」

新米SE「え〜!バー!となってガー!となってばーん!ですよね?」

お客様「違う違う!」
お客様「バー!となってガー!となってばーん!や!」

新米SE「え〜!バー!となってガー!となってばーん!ですよね?」

お客様「ん?・・・いや、バー!となって、ガーン!となって、ボーン!・・・やな?」

新米SE「え〜!(さっきと言うてることが違うやないか!?)」
新米SE「バー!となって、ガーン!となって、ボーン!・・・ですか・・?」

お客様「ん?・・・いや、やっぱり、すー!ときて、ポーン!となって、バン!・・・かな?」

新米SE「え〜!(また、言うてることが変わってるやないか!?)」
新米SE「すー!ときて、ポーン!となって、バン!ですね?」
新米SE「間違いないですね?」

お客様「そや!すー!ときて、ポーン!となって、バン!」
お客様「これや!」

新米SE「間違いないですね?」
お客様「何回言わすんや!それでええんや!」

新米SE(まぁ、これだけ確認したら、大丈夫やろ。)
新米SE「ポチポチポチ・・・」
新米SE「・・・・・」
新米SE「できました!見てください!」

お客様「違うやないか〜〜!」

熟練SE「どうかしましたか?」

お客様「あ、熟練さん!ギュー!となってパー!となってジャーン!ってして欲しいんです。」

熟練SE「なるほど。ギュー!となってパー!となってジャーン!ですか・・・。」
熟練SE「それはつまり・・・」
お客様「・・・」
熟練SE「・・・」

熟練SE「よし!できた!」

新米SE「え?あ、これ、え?ちょ、これじゃあ、ズギャーン!じゃないですか!」

お客様「おお!これやこれ!これでええわ!」

熟練SE「でしょ?(えっへん)」

新米SE(いったい、どうして・・・・)

エピソード3 「絶対的神の力」 〜 力が欲しいか 〜

お客様「ここのボタンは、ドーナツ型にするんや!絶対や!」

新米SE(なに〜〜〜!ドーナツ型やて〜〜〜?)
新米SE「でもそれじゃあ・・・」

お客様「それがナウいんや!新しいんや!」

新米SE「え〜本気ですか〜〜?」

お客様「いける!いける!」
お客様「他にそんなボタンは見たことないからな!新しいんや!」
お客様「これは、当たるで〜!」

新米SE(まあ、お客様がそう言ってるから、しかたないなぁ)

新米SE「・・・・・」
新米SE「できました!見てください!」

お客様(なんか・・・このボタン、押しにくいな・・・)
お客様「このボタン!押しにくいやないか!」
お客様「なんでやねん!押しにくいやないか!」

新米SE「え、でも、ドーナツ型って言いましたよね?」

お客様「押しにくいなら、押しにくいって、言うてくれやんと!」

新米SE「え、でも本当にやるのか、確認しましたよね?」

お客様「でもこれはあかんやろ!ボタンの真ん中がクリックできんやないか〜〜!」

熟練SE「どうしましたか?」

お客様「あ、熟練さん!ドーナツの真ん中がクリックできないんです!」

熟練SE「なるほど。これは、ボタンとしては良くない形状ですね」
熟練SE「クリックしやすい中央部分に穴が空いていて、操作ミスに繋がりやすいです」

お客様「最初からそう言ってくれれば・・・」

解説

渾身のエピソードを3つ書かせていただきました。
慣れない会話形式とキーボードで、もはや私は腕が上がりません。

さて、どのエピソードも、新米SEがお客様の要望をうまく叶えられない、という内容になっています。

1つ目は、お客様は__金色の__という要望を出すのですが、新米SEは__黄色の__メッセージを実装してしまいます。
対して、熟練SEは__赤色__にして一件落着。
なぜでしょう?
実はお客様は、口では__金色__と言いながらも、本当はメッセージを__目立つように__して欲しかったのです。
目立つように金色にして欲しい、と言ったのに、新米SEは黄色にしてしまって、逆に見えにくくなってしまう、という失敗のエピソードでした。

2つ目は、擬音ばっかり言うお客様
東京の方は知りませんが、大阪ではこのようなお客様は一般的です(一部誇張表現あり)。
新米SEは、言われた通りに実装しますが、なかなかお客様のイメージに合いません。
いろいろ確認しているうちに、お客様の言うことがどんどん変わっていって・・・。
システム開発の現場ではよくある話だと思います。
これは、お客様は自分自身がどうやりたいか、というイメージが湧いていなかったということなのです。
熟練SEはどうしたでしょう。
ゆっくり話し合って、本当にやりたいことを実現して、最終的には__ズギャーン!__と実装しましたね。
話し合うことによって、お客様もSEも理解が深まり、良い実装ができた、というエピソードでした。

3つ目は、__変わった注文__をするお客様。
お客様はあまりよく考えずに、新しい形状のボタンを実装するように新米SEに依頼を出してしまいます。
新米SEは疑問を持ちながら実装することに・・・
結局、__使いにくいドーナツ型のボタン__ができてしまい。苦情になってしまいました。
システムとして良くないものはきちんと説明して、正しい方向に進めて行かなければなりません。
そのためには、知識や経験、お客様へ説明するための言語力が必要になってきます。
システム開発において、正しいものを提案してお客様を納得させる、ということが重要である、ということがわかるエピソードでした。

あとがき

3つの違うエピソードを考えてみましたが、いかがだったでしょう?
似たような経験の心当たりがある人もいるのではないでしょうか。

システム開発者にとって、お客様は、お金を払ってくれる神様です。
ですが、全知全能ではありません。

お金を支払い、やりたいことを伝える。それだけです。
お客様は、やりたいことを伝えることはできますが、自分が__本当に欲しいものは何なのか、は理解していない__ことが多いです。

システムを作りたいと言っても、それはシステムによって業務効率を高めたいということであって、どんなシステムが欲しいか、は解っていないことが多いです。

お客様が欲しいものを深く理解し、システムに表現するのが、我々システム開発者の仕事です。

システム開発者は、システム開発のプロです。

ですから、処理の方法も、表示の方法も、画面のレイアウトも、__お客様よりも詳しい__はずです。
いろいろな知識を持っているはずです。
自信を持ってより良いものを提案し、説明し、理解してもらうべきです。
そのためには、

システムについての知識を豊富に持ち、きちんとお客様の要望を深く理解し、より適切な方法でシステムを実現しなければ、なりません。

それが、__システム開発者の使命だから__です。

43
26
6

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
43
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?