読み込みが終了しない場合は、しばらく待つか、リロードを行なってください。
If loading does not finish, wait for a while or reload.
Beginner Engineer Blog
エンジニア向けの情報を発信するブログです。
どなたでも発信できます。
お好きに利用していただれば幸いです。
Article
Content
中の人
【The Tree Swing】顧客が本当に必要だったもの
公開: 2024-03-29 03:54
更新: 2024-05-16 00:39
更新: 2024-05-16 00:39
205
考察
設計
コミュニケーション
好きな画像を紹介します
【広告】
こんにちは！
中の人です！
私はQuoraというサイトが好きでよく見ているのですが、そこでたびたびプログラム関連の回答などに登場するこのサムネイルの画像、みなさんご存知でしょうか？
プログラマ、エンジニア、何らかの技術者なら「わかるー!!」と感じるのではないでしょうか
私はこの画像、というか図？を見たとき、すごく共感して、画像の間抜けさもあって笑ってしまいました
そんで調べてみるとあまりにも有名な図でしたのでみなさんと共有したいと思います
何これ？
この図は「the tree swing」や「Tree Swing Cartoons」と呼ばれるいわゆる風刺画です
タイトルのとおり、「顧客が本当に欲しいものはこれだ」を理解するのが、開発者にとってどれだけ難しいか
さらに、それを形にするのがどれだけ難しいかを表す図となっています
この図は何通りもパターンが存在し、サムネイルで示されている図よりも多い図が描かれた図もあったり、少ない図もあったり、カラーではないものであったりと複数存在し、みなさんの好きが伝わってくるものとなっています
サムネイルで使用させていただいた図も、誰かが作成したオマージュだと思います
私もこの図はとても好きです
多分この業界にいる限り最高のバイブルだと感じています
しかしながら驚くのは、この図の元ネタははっきりとわかっていないらしく、場所はアメリカみたいですが、誕生した時代が1960年代だったり、1970年代だったりと参照する記事で変わりますが、いずれにせよ半世紀くらい前から存在した図みたいです
作者も不明
なんともロマン溢れる図を私たちは目の当たりにしています
ひとまず見て考察してみます
前述したように私もこの図が好きで、ファンとして一つ一つ見て何を言いたいか考察していこうと思います
※ 風刺画なので私個人が思ったままの考察をしていこうと思います！(と言っても私自身いろんな方の考察を見てしまっているので、多少は影響受けてます(ﾟ∀ﾟ )ｽﾏﾝﾉ)
※ 別の考察が得たい方は色々と調べ回ってみるのだ！！
顧客がどう説明したか
How the customer explained it
google翻訳だと「顧客がどう説明したか」です
アメリカで誕生した図であろうから、せっかくなので英語で見ていこうと思います
日本語に訳された画像は以下参考記事を参照してください
私たちプログラマーなどのエンジニアは「実現したい」を叶える素晴らしい職業についています
顧客が欲しいものを作り上げることは命題です
さぁ、顧客が欲しいものがあると訪ねてきました
彼は必死にこの図のようなシステムを説明します
ふむふむ、一見ブランコですが、ブランコとするなら
一番上の板に腰掛ければ、下の二つの板が邪魔をして足を振ってブランコを揺らすことができない
一番下は座れない
真ん中は足も振れない、座れない
でも顧客はこれを想像しながらこれが欲しいと訴えています
この時、顧客、そして開発サイドも
「顧客自身がこのシステムを、どのように使って目的を達成したいかがリアルにイメージできていない」
ということに気づきませんでした
さぁプロジェクトがスタートします！！
プロジェクトリーダーはそれをどう理解したか
How the project leader understood it
google翻訳だと「プロジェクトリーダーはそれをどう理解したか」です
私はもうここで笑ってしまいました笑
わかりみが深い
私たち人間は言葉を発することができます
なので意思の疎通は安易だと考えている方が多いと思います
ですが、少し考えてみてください
あなたは卵焼きが好きだとします
フラっと入った定食屋で卵焼きがありました
あなたは卵焼きが大好きなので、迷わず注文します
「卵焼きください」
提供された卵焼きは、しょっぱいだし巻き卵でした
ここで「当然だ」と感じる方もいれば、「なんで砂糖が入った甘い卵焼きではないのか」と感じる方もいると思います
そうです
あなたの頭の中は誰にも覗くことはできません
あなたの常識は他人にとっては非常識かもしれません
顧客は「システム開発のプロだしこの説明で理解してくれるだろう」と、完成図を想像しながら説明しました
プロジェクトリーダーは、「木の枝に2本ロープ張って両端のロープを木の板で繋げたものが欲しいんだな」と理解しました
さぁ、システムの仕様の打ち合わせは無事終了です！
神にしかこの後始まる炎上を予想できないでしょう
アナリストがどのように設計したか
How the analyst designed it
google翻訳だと「アナリストがどのように設計したか」です
アナリストとは「分析者」という意味がありますが、私はよくわからなかったので「設計者」として理解することにします
まだ3つ目の図ですが、私たちはカオスな空気を共有することができます
おそらく、顧客から仕様を聞き取ったプロジェクトリーダーが、「こんなの設計して」とお願いした設計者が設計したものでしょう
設計者は自分の解釈も盛り込んだに違いありません
システム開発の現場においては、実際に実装を始めて、より成果物を現実的に想像する段階にくると、「いや、この仕様だときついぞ。。」となることがよくあります
プロジェクトリーダーが解釈したブランコは、木の幹がブランコのすぐ後ろにあって、ブランコを振ることができません
設計者は、「ブランコは振ることができないとブランコではないから、幹をくり抜いて振れるようにしよう」と考えたのではないでしょうか？
そして、くり抜いてしまうと木は倒れてしまうから、「枝を支えなければならない」と考え、支えの木を追加したのでしょう
うーん、顧客が説明した内容からすでに大きく外れていきますが、俯瞰している我々からすると、当たり前だと感じるでしょう
プログラマーがどのように書いたか
How the programmer wrote it
google翻訳だと「プログラマーがどのように書いたか」です
あぁ、ブランコとは一体なんなのでしょうか爆笑🤣
設計者が描いた独創的な図とは似ても似つかない、とても簡単な実装、そして機能を果たさない、とてもユニークな成果物が完成されました
面白すぎます笑🤣
ですが、開発の現場では往々にしてよくあることです
正直、「完璧な設計書」を作ることは非常に難しいです
例えば、
・このボタンは、こんな条件に合うユーザーの場合、表示してください
という仕様があるとします
しかし、実際「こんな条件に合うユーザー」の条件が、「設計書どおり実装していくと、誰一人その条件に合うユーザーが生まれない」という状況が発生する
ということは、往々にしてよくあることです
設計書を見たプログラマは、設計書の欠陥を知ってか知らずか不明ですが、設計書のとおり実装しました
なるほど、もはやブランコが宙に浮いている時代は終わりました
よく現場では、設計者、いわゆる「上流」から、「開発してくれたここの機能ですが、なぜこのような実装をしたのでしょうか？」などの問い合わせがあります
私たちプログラマは、「設計書のNo.⚪︎に書かれたとおりに実装しました」と答えると、「あぁーなるほど確かにそうですね。。じゃあそここうしてもらうことは可能ですか？」というやりとりがよくあります
「設計書の欠陥を知ってか知らずか不明」と前述しましたが、ほとんどの場合設計者やプロジェクトリーダー等に指摘すると思います
が、まぁ、ほら、そのー、ご自身の現場を想像してみてください
あぁ、これ指摘したらまたうるさいこと言われそうだな。。なスタッフやビジネスパートナーはいないでしょうか？
良かれと思って発言したことで、いらない炎上が発生するかもしれません
さらに責任をなすりつけられるかもしれません。。
面倒が嫌いな人はどうするか
「設計書のとおり実装する」
これが自分に責任が降ってこない最良です
コミュケーションをとってください！！
ベータテスターが受け取ったもの
What the beta testers received
google翻訳だと「ベータテスターが受け取ったもの」です
おっと、板がどこかに行ってしまい、きな臭い形をしたロープが枝から下がっています(ﾟ∀ﾟ )ｺﾉｶﾀﾁﾊ...!
おそらくプログラマと設計者があれこれ話し合っているうちに、「あれ、これ板必要ないんじゃないか？」「人が乗れる形にロープを縛れば、機能として用を足すんじゃないか？」「ロープ一本でよくない？」となったに違いありません
人が乗れる形は必要最低限を満たせば、どこにひっかけて乗るかは問題ではありません
足をひっかけて振ることができます
えぇ、引っかかる場所なら足でなくても問題ありません
テスターは「人が乗ってロープを振ることができる」ことのテストを行なったはずです
当然テストは成功でしょう
ビジネスコンサルタントはそれをどう説明したか
How the business consultant described it
google翻訳だと「ビジネスコンサルタントはそれをどう説明したか」です
厄介な方が出てきました
ビジネスコンサルタントとは、お客様のお仕事を高度な専門的知識を駆使して発展させるアドバイスをする方々を言います
彼らは言うでしょう
我々はお客様のビジネスを成功させるため、弊社が開発するブランコは、他社のブランコとは違い、非常に座り心地の良い椅子となっております！！
誰か彼らの誇大広告を指摘する必要があります
。。でもビジネスです。仕事を得るには彼らも必要です
ですが大体開発者と一悶着あるでしょう
ちょっと待ってください。そんな仕様は聞いてませんし、設計書にも書いてありません。間に合いません。..え？もうクライアントさんに言っちゃった？？
明日からデスマーチが確定した記念すべき瞬間です
我々は死して尚、彼の前に怨霊として現れ、彼を苦しめるでしょう
いや、彼みたいな方も必要ですよ
天龍さぁぁぁん！！
プロジェクトがどのように文書化されたか
How the project was documented
google翻訳だと「プロジェクトがどのように文書化されたか」です
だって仕様がコロコロ変わるんだもん
納期になんとか成果物を用意できたことを褒めてください
ドキュメントなんて作成する暇なんてありませんし、明日から別のプロジェクトが開始します
結局結局結局のところ、メールやチャットで仕様が変化、確定していきます
結局結局結局そうなります
初めの設計書はいつしかどこに行ったかさえもわからなくなります(ﾟ∀ﾟ )ｵｲ
どのようなオペレーションがインストールされているか
What operations installed
google翻訳だと「どのようなオペレーションがインストールされているか」です
おそらく、出来上がった成果物の中身はどのような振る舞いをするかという意味だと解釈します
晴れてプロジェクトが終了し、お客様にリリースしました
最終的に出来上がったものは、「木の枝にロープが一本括り付けられているもの」でした
確かに、ロープにつかまって体を振れば「ブランコ」とも言えるでしょう
ちなみにブランコの用を足すのに板は不要でしたのでこちらで捨てておきました
ひとまず打ち上げに行ってチームと苦労を分かち合います！
引き続きよろしくお願いいたします
。。。当然、お客様は「なにこれ？」となるでしょう笑😂
顧客が欲しいものはこれじゃなかった！！
これを作るために膨大な時間をかけたのに！！
顧客への請求方法
How the customer was billed
google翻訳だと「顧客への請求方法」です
請求方法というか、実装費用の請求を表していると思います
まぁまぁ、まぁーね！
そうだよね
高っいよね笑🤣
でも考えてください
あなたが依頼したプロジェクトは、一体どれだけの時間をかけて成果物が提供されたでしょうか？
そしてそのプロジェクトに何人関わったでしょうか？
私たちはお金がないと生きていけません
生きられなければ、先ほど納品した「これじゃない」成果物を直すことができません。。
何ヶ月も時間を要したなら、その何ヶ月分、関わった方の生活を保証する金額が報酬として必要です
まぁ、プロジェクト開始前にお見積書を作成して納得していただいてからスタートするんですけどね
でも往々にして仕様が追加、変更があります
仕様の追加や変更に耐えられない場合、追加の金額が発生するでしょう
ここでよくあるのが、
「説明した内容を歪曲したのはあなた方だ！追加で費用を請求するなんてあり得ない！そもそも板はどこにいった！！」
「あなたの説明どおりのシステムを作ったんだ！ほら、あなたに提出した設計書がエビデンスだ！仕様変更だ！！板は捨てた！！」
お金が絡むと人間という生き物の本質が垣間見れます(ﾟ∀ﾟ )ｿｳﾀﾞﾅ
どのようにサポートされたのか
How it was supported
google翻訳だと「どのようにサポートされたのか」です
運用を開始して月日が流れ、もう「木」がどこかに吹き飛ばされ、切り株だけ残っています
形はどうあれ、「人が乗ってロープを振ることができる」という機能も無くなっています
おそらく致命的な不具合が発生してしまったのでしょう。。
バグはどのシステムにも潜んでいます
サポートがあればこんなことになるはずありません。。。。いや、あります！
そのプロジェクトに関わったエンジニアが別の会社に転職してしまった
月日が経ちすぎて詳細な仕様を覚えている人が開発者、クライアント共に誰もいない
そもそもエンジニアが逃亡した
状態になると、満足なサポートは受けられないでしょう
既に当初の目的のブランコの機能は失われました
ですが当時を知らないスタッフのサポートを受けて切り株だけは残すことができたみたいです
私はね、この切り株に座ってお茶を飲むのが好きなんですよ。もう数年前から欲しかった機能は動作しないんですがね。不思議と心が落ち着くのですよ
見上げた空は綺麗な青色でした
どのようなマーケティングが宣伝したか
What marketing advertised
google翻訳だと「どのようなマーケティングが宣伝したか」です
これはなんでしょうね？
chatGPTにも翻訳お願いしてみましたが、
"What marketing advertised"という文は、「どのようなマーケティングが広告されたか」という意味です。つまり、何が宣伝されたのか、どのような広告が行われたのかについて尋ねています。
うーんどういうことでしょう？？
多分ですが、顧客は出来上がったものがロープ一本だということを理解できず、自分の頭の中の創造物を宣伝して回ってしまったということでしょうか？
ご自身が宣伝する内容に責任を持ってください！
顧客が本当に必要としていたもの
What the customer really needed
google翻訳だと「顧客が本当に必要としていたもの」です
ついに最後の図にしてタイトル回収です
おそらく、リリース後も何度も何度も
「いやー。。作ってもらって、とりあえずはやれることはできるんですけど。。なんていうか。。正直こうじゃなくて。。こうしたいというか。。いや。。最初に説明したことと矛盾する箇所があるんですけど。。使い始めて違うなぁ。。なんて。。あ、もちろんです。お見積もりください」
なやりとりの末、ついに手に入れた「理想のシステム」がこの図が表すものでしょう！！！
本当に欲しかったものは、これでした！！
発注者も、開発者も打ち上げに出かけましょう！！
開発段階で途中から捨てられた板は、捨てて正解だったみたいです笑🤣
さらにロープを輪っかにして縛るのも惜しかった！
ひっかけるのはネックではなくタイヤでした！
こちらに完成品が見つかったと報告？されています
調べてみると世界各地で発見されているみたいですww
好きな方多いですねー友達になれそうです！
ということで、すれ違いはいつどの時代も発生するものですね＼(^o^)／ﾔｯﾄｵﾜｯﾀ!!
つまり
・自分の頭の中を自分で理解するのも、まして、それを他人に理解させることって、めちゃくちゃ難しい
・関わる人が多くなればなるほど、顧客が何をしてほしいのかわからなくなる
・そもそも顧客はシステムについて詳しくないから依頼するわけなので、積極的に開発者がアプローチして正解を引き出す努力が大事だ
ということが言いたいのかなと感じました
終わりに
あぁ、楽しかった笑
みなさんも楽しんでくれていたら幸いです
しかし、自分がこの炎上の中の一員だと、楽しいなんて言ってられません
俯瞰してみるから楽しいのです
だからこそ、こういった風刺画て好きなんですよね
皮肉が混ざっているのが当たり前で最高です
ちょっとぼやかせてください
ちょっとぼやきます
ウォータフォールで起きやすい
この図で表すようなことって、ITの業界だと「ウォータフォール」と呼ばれる開発方式？の時によく発生します
ウォーターフォールとは、まさにこの「The Tree Swing」で紹介した流れでシステムを開発していくやり方です
ウォーターフォールのデメリットは、一度全体を設計してから開発を開始することで、この「The Tree Swing」のようにどんどん顧客の意思から離れていってしまうことです
そもそも、この「The Tree Swing」の一発目の図で、「顧客自身がこのシステムを、どのように使って目的を達成したいかがリアルにイメージできていない」ものを初っ端に全て設計するのですから、高い確率で「顧客が本当に必要だったもの」が生まれないのは想像に難くないでしょう
顧客を置き去りにすると、結局は、開発者と設計者のプライドのぶつかり合いのような開発環境が生まれて、出来上がる成果物は、「何これ？」となることが多く、顧客は追加の費用を支払って必要なものに近づけていく必要があります
アジャイルが好きです
では今推奨されているのは「アジャイル」という方式です
この方式は常に顧客に寄り添って、というか、顧客も開発に巻き込んでいくスタイルです
私もアジャイルが好きで、よしなにしていただいているお客さん(エンドのクライアントさん)とはプロジェクトによってはアジャイルで開発をしています
私はお客さんから「こういうの作って欲しいのだけれど」とぼんやりした内容を受け付けます
で、大まかな機能の概要を聞いたら「そしたら一旦簡単に作ってテストサイトに上げるので、それを動かしてみて期待する動作と違う箇所があれば教えてください」と、これまたぼんやりした回答をして、そんで、もう開発を始めてしまいます
(必要であれば簡単な設計書は作ります)
そして「ある程度」できたら、「こんな感じでどうでしょう？」とお客さんに確認してもらいます
すると、早期にお客さんとの意識のズレがわかるので、一つ一つの機能が脱線するリスクがかなりなくなります
一つ一つお客さんと確認しながら進めることで、当然、「完成品」が顧客の意思と大きく外れることはありません
しかも、お客さんが同時に「実務的な」テストをしているようなものですから、我々が気づかなかった不具合も早期に発見できます
このことから、アジャイルは非常に優れていると、というか、合理的であると、私自身も感じています
そして今
アジャイルが推奨されているというのは、私がプログラマになった4,5年前には言われていましたので、プログラムを勉強していた頃の私は、「当然実務はアジャイルが中心なんだろう」と考えていました
ですが、受注開発というのもあるからか、まだまだウォータフォール方式をとっている会社さん、結構あります
というのも、私の経験上、やっぱお客さんとしては、「こういうシステムをいついつまでに欲しい」って要望が大半だと思います。ドーンと完成品が出来上がるイメージだと思います
車で例えると
新車が欲しいっすってディーラーに行くとします
ウォーターフォールの場合、工程がほぼほぼ確立された生産ラインが整っているので、新車を納車できる期日については、大体はわかると思うのですよね
ただし、アジャイルの場合、「タイヤできましたー」「ドアできましたー」「ハンドルつけましたー」を一つ一つ購入者に見てもらって、フィードバックを受ける必要があります
タイヤもうちょっと大きくならない？ドアもうちょっとこうならない？ハンドルのデザインこうならない？と。。。
当然、納期はあやふやになります
もう一つ例えるなら、初めて城下町の洋服屋にお忍びで訪れたお姫様が試着して、執事に「どう？」「どう？」と感想を求めるような感じです
大体、買い物終える頃には日が落ちているのが相場ですね(個人的なイメージです)
なので、システムを上記の新車のようなイメージで発注するお客さんの場合だと、まだちょっとアジャイルは難しいのかもしれません
ただし、「シート取り替えたいんだけど」のような、「部分的な改修」だったり、「カーナビつけたいんだけど」のような「小さな追加機能」なんかは、アジャイルでささっと作ってしまった方が、コストもかからないのかなと感じます
ただ、なんとなく近い将来、「効率性」とか「合理的」な意識が徐々に広まって(いやもう広まってはいるんだろうけど)、アジャイルがメイン。。。になっていくんじゃないかな。。と個人的な希望を込めて期待しています(ﾟ∀ﾟ )ﾄﾞｳﾅﾙｶﾈ?
終わりに終わりに
ちなみに冒頭で紹介したQuoraというサイト、風刺画だらけで面白いですよ
よくこんな画像見つけたなって画像がてんこ盛りです
この風刺画が面白いと感じたら、このサイトも楽しめるかも
ということで
長くなりましたが
おやすみなさい
【広告】
