「開発」タグアーカイブ

新・ギリシャ神話「ミダス王のシステム開発」

ビジネス界では有名?ミダスタッチ(マイダスタッチ)

つい先日、「ミダスタッチ(マイダスタッチ)」という言葉を初めて知った。

「ミダスタッチ」というのは有名なギリシャ神話の一つ。
「王様の耳はロバの耳」の中で出てくるロバの耳を持つ王様は「ミダス王」と呼ばれているが、この「ミダスタッチ(King Midas and Golden Touch)」という神話の主人公も「ミダス王」である。
つまり、ロバの耳の王様と同一人物である。

ミダスタッチは「ミダス王がタッチ(接触・触れる)する」ことに神話名は由来する。

そして、この「ミダスタッチ」という言葉は、海外でのビジネスの場や投資家などでは時折耳にする有名な言葉らしい。
錬金術」というような意味合いで。
(私は知らなかった。)

初めにこのミダスタッチ神話を読んだ感想は、
「ふーん、まぁよくある神話。昔話あるあるだよね。」くらいに思ったのだが、
もう一度読んでみると「システム開発」や「サービス開発」について重要な示唆があるのではないかと感じた。
特に、クライアント(もしくは社内の営業さん)など「非開発者」とやり取りする際に「考えてほしい逸話」もしくは「共有するとよい意識」として使えそうだと思った。

なので、是非共有したく。

ということで、このギリシャ神話がどういう神話なのかまずは原典をサラッと流してみる。
(端折ったり意訳もあり。)

ギリシャ神話「ミダスタッチ」

昔々、あるところに「ディオニュソス(バッカス)」という神様がいた。

ある日、ディオニュソスの「師匠」が困っていたところを、ミダス王が助ける。
ディオニュソスは、師匠を助けてくれたお礼にどんな願いも一つ叶えようと申し出る。

そこで、ミダス王は「触るものをすべて黄金に変える力が欲しい」と言う。

ディオニュソスは少し戸惑ったが、ミダス王の願いを叶えることにした。
そして、ミダス王は「ミダスタッチ」と呼ばれる「触れるものすべてを黄金に変える力」を手に入れる。

この素晴らしい力を手に入れたミダス王は早速この力を試してみたくなる。

まずは、目の前の木の枝を触ってみる。
すると、木の枝が黄金に変わった!
木にリンゴの実が成っていたので、リンゴをもぎ取ってみる。
すると、リンゴが黄金に変わった!
素晴らしい力を手に入れたミダス王。

強力な力を手に入れて大喜びな王様は、早速お城に帰り「今宵は大宴会だ!」と言い盛大な祝賀会を行う。

ミダス王は嬉々として、最高級の食事を用意させ、まずはパンを食べようとする。
しかし、パンに触れると・・・パンが黄金に変わった。
なるほど、手で触れてしまってはすべてが黄金に変わるので、今度はおいしそうなチキンを手を使わずに口だけで食べようとする。
すると、ミダス王の唇に触れたチキンは黄金に変わる。
ミダス王は、せめて喉を潤したいと思い、ワインを飲もうとする。
しかし、ワインも口に含んだとたんに黄金に変わる。

「触るものすべてを黄金に変える」という「すごい力」を手に入れたにもかかわらず、
文字通り「すべてのものが黄金に変わって」しまい、ミダス王は飲み食いすらできず衰弱していく。

飢餓に耐えかねたミダス王は、ディオニュソスにもう一度お願いをする。
「触るものすべてを黄金に変えるこの力を消してくれ」と。
ディオニュソスは、「分かった。ならば、ある川に行き身を清めよ。川の水が能力を洗い流してくれる。」と。

ミダス王はディオニュソスの指示通りの川に行き身を清め、ようやく黄金の力を取り去ることができた。

以上、ミダスタッチの物語。
その後、神話は「王様の耳はロバの耳」物語へとつながっていくのだけど、それは割愛。

ミダスタッチの意味するところ

この神話からどのような教訓を感じ取るか?

おそらく、一般的な教訓としては

人間の欲望には際限がなく、そして際限のない欲望は身を亡ぼす。

ということだろうと思う。(私の第一印象)

神話や昔話では、非常によくある教訓である。

ただ、よく読んでみると、IT技術者(エンジニア)の私はこの「ミダスタッチ」はシステム開発やサービス開発などにおいて非常に重要な示唆を含んでいるのではないかと思った。

そこで、ミダスタッチ神話をシステム開発あるあるにアレンジしてみた。

ミダスタッチ・システム開発あるあるver

ある日、クライアント(ミダス)が言った。
触るものすべてを黄金に変える機能(ミダスタッチ)が欲しい」と。

エンジニア「可能です。ですが、もっと時間をかけて丁寧に要件・仕様を詰める必要があります。」
クライアント「なんでそんなに細かいところまでいちいち詰めなきゃいけないんだ、私が欲しいのはミダスタッチだけ。」
エンジニア「できます。が、基本機能だけでは、きっと色々と困ること(例外など)も出てきます。」
クライアント「単にミダスタッチが欲しいだけ。例外のために丁寧に要件を詰めていくなんて煩わしい。一刻もはやくミダスタッチを。」

かくして、エンジニアはクライアントの意向に従い「触るものすべてを黄金に変える機能」を開発した。
エンジニアがシステムを納品すると、クライアントは大喜び。

そして、クライアントは早速機能を試す。

クライアント「すばらしい!木の枝が黄金に変わった。これだこれが欲しかったんだ!」
クライアントは、大喜びで次々とミダスタッチを試す。

しかし・・・。

クライアント「ちょっと待て、なんでパンが食べたいだけなのに、パンが黄金になるんだ!『食べ物』が黄金に変化するのは大問題だからすぐに修正して!」
エンジニア「いや、触るもの『すべて』を黄金に変える機能なので当然ですが・・・」
クライアント「ちょっと待て、なんでチキンが唇に触れただけで黄金になるんだ!?私が求めているのは『手で触れた場合だけ』。手以外に触れた場合は黄金にならないようにすぐに直して!」
エンジニア「いや、『触れる』という要件定義しかしていないので・・・。」
クライアント「ちょっと待て、なんでワインという『液体』まで黄金になるんだ!液体まで黄金にして欲しいとは頼んでいない!
エンジニア「いや、『触れるものすべて』という要件に沿って開発したので当然なのですが・・・。要望通りのものです。もし、細かい例外を設けたいのであれば、しっかりと仕様を詰める必要がありまして。」
クライアント「ええーい、煩わしい。そんなのはお前が自分で考えて『いい感じ』に決めて。」
エンジニア「その『いい感じ』にするために、丁寧に仕様を詰める必要がありまして。そのためには私の考えだけでなくクライアントさんの考えが必要で・・・」

クライアント「ミダスタッチ全然使えねー。せっかくコストかけて作ったのに!」

ミダスタッチが共有されたら

私個人的には、昔このような状況になることも多少経験しているが、今は幸いにして当たることがなくなって久しい。
(自分の身の回りの理解あるクライアントさんには感謝しかない。)
もしかすると、エンジニア側にもクライアント側にも「きちんと対話していくことの大切さ」「システム開発は一方的なオーダーではなく、一緒に作るもの」という感覚が徐々に広がってきているおかげかもしれない。
(個人的にも強く対話を求めるが・・・)

が、自分自身は経験しなくなったとはいえ、おそらく世の中にこういったやり取りはまだまだたくさん存在しているのではないかと思う。
(ですよね?)

そういった場合、このミダスタッチのギリシャ神話についてクライアントさん(もしくは自社の営業さん)に話してみてはどうだろうか。

パンは黄金に変えますか?
唇に触れたら黄金にしますか?
ワインも黄金にしますか?
「触るものすべてを黄金に変える」というだけの要件では、満足いくモノは得られないかもです。

またクライアントサイドも、この逸話を思い出すことで

「本当に自分が欲しいモノ」を作るためには、しっかりとエンジニアサイドと対話し協力していく必要がある

と思えるのではないだろうか。
パンはどうしよう?ワインはどうしよう?と考えることで、きっと経営のコアバリューやサービスのUXについて深く考える良い機会やきっかけにもなるんじゃないかなと思います。
(UXデザインってそういうことですよね。)

※他にもデザイナーさんなど対話が重要なクライアントワークでは活躍する逸話かも。
(自分もミダスタッチでオーダーしているかもしれない。自戒。)

どちらサイドにしろ、

あ、それはミダスタッチかもですねー。もう少し丁寧に考えましょうか!

とお互いに言えて理解し合えると、システム開発はもっと幸せなものになり、価値あるものを生み出せるようになるのではないかなと思ったり。

少なくとも、ミダスタッチが少し共有されることで、クライアントワークが少し幸せなものになったのなら不遇なミダス王もきっと喜ぶに違いない。

このエントリーをはてなブックマークに追加

エンジニアとしてどう立ち振る舞うことが正解だったのか

懐かしいクライアントさんから2年前に納品したシステムサービスに「バグ(不具合)がある」と連絡が入り、至急なおして欲しいと言われる。

厳密には瑕疵担保責任期間(6ヶ月)は終了しているけれど、
私が一人で開発したものだし、クライアントさんも困っているようだし、連絡を受けてからすぐにバグ修正をするための調査を始めた。

まずは「バグと思われる現象」について、Skypeとメールにて詳細に説明を受け、自ら再現などを試みつつ何度もソースコードを読み返すこと二日目。
よくよく調べていくと、バグだと言っていた内容は実は当時口頭で合意した「仕様」だったことがわかった。
(そもそも、2年も経っていて仕様を忘れてしまっていたが、ソースコードのコメントに仕様が書かれていたことで記憶が蘇った。)

そこで、急いで調べた結果について報告を行う。
「これはそもそも仕様なのでバグではありません。もしこの仕様を変更する場合は追加修正という形になります。」と。

しかし、どうもクライアントさんは納得ができない様子。
無理もない、クライアントさんには情シス部があるわけでもなく、社内に専門家もいない小企業さんである。
(プラス、これまで色んな開発会社に仕事を頼んでは失敗を繰り返している過去を聞いているだけに、開発者への妙な不信感も多少あるのかもしれない。)

ということで、クライアントさんからは、
「やはり、これはバグだと思うし、そんな大きな変更にも見えないし、大変困っているのでとりあえずすぐに直して欲しい。」と告げられる。
(通常は、そういうトラブル予防として「エビデンスの確保」や「ドキュメンテーション」をしっかりやるのだが、小さな案件だとそこに回せる予算がないケースって結構あったりする。2年前に受けた時はそのケースだった。)

ここで私は非常に悩み始める・・・。

実際問題として、この不具合(とクライアントさんが思っているが、実際は当初通りの仕様)の改修は、それ自体それほど大したことはない。
なんなら「1日もあればサクッと改修できる目算」である。

たった1日、私がサービス(無償奉仕)しさえすれば全て丸く収まる。

クライアントさんは希望通りの機能を手に入れて業務が円滑になってハッピー。
私の方もこれまでお付き合いしてきているし、1日程度のサービスくらい融通を効かせてもいいのではないかと思う。

しかし・・・・。
「クライアントさんが納得しない」「私がちょっとサービスすればいいだけ」という理由でそれをやっていいのだろうか?

やはり、ちゃんと納得行くまで説明して「バグではなく当時合意された仕様である、なのでこの改修は明らかに追加労働であり、追加費用をお支払いいただく事となります。」ときちんと理解していただくべきか・・・。

ちなみに、今までなら「サービス」や「善意」で、さっさと修正してしまう場合も結構あった。
理由は、それがもっとも「経済的視点でみて合理性が高い」から。

詳細な状況説明ドキュメントを丁寧に書き下ろして、素人にもわかるように解説資料も作成し、それらを持ってして「これは仕様なのです。」と説明し理解していただくコストを考えたら、1日でプログラムを修正する方が圧倒的に早い
さっさと後者で対応してしまった方が、私としても楽だし、クライアントもバグ(本当は仕様)が修正されるという、一番経済合理性のある道筋かと思う。

しかし、今回はかなり悩んだ挙句、後者ではなく前者を選択した。

つまり、プログラム修正する倍以上のコストをかけてでも理解してもらう作業を行おうと。
1日で修正できる程度のバグについて、二日かけて資料を作成し送付、その後資料に基づき何度も長文説明メールのやりとりをしてさらに数日かけ、「これは仕様となっており、修正には追加費用がかかります。(必要なら見積書は作成させていただきます)」ということを細部まで説明しきった(個人的には)。

結果、努力が実を結び、クライアントさんからは「なるほど。そういうことなのですね。よく理解できました。」と、きちんとした理解を得ることができた。

が、同時に「追加のコストがかかるならやめておきます。」とも回答を得た。
(それ自体は問題ない。クライアントさんはクライアントさんのふところ事情があるわけだし)

さて・・・。
それにしても、私の選択は正しかったのだろうか・・・。

自分の気持ちとか感情的な部分はどちらでもよく、「客観的・経済的に正しかったのか」という部分で未だ自己解決できずにいる。

私が、何も言わずにプログラムを修正していたら、クライアントさんも修正の恩恵を受けられた上に、私も丸二日以上ものコストを割かずに済んで(1日で終わって)一番楽だったはず。

しかし、今回の「正しい理解と納得を得る」という選択をしたため、私は丸二日以上の別稼働を失い、クライアントさんも修正を受けられなかった。
結果だけを見ると、誰も得をしない形である。
まさに”Lose-Lose”のようにしか見えない。

確かに、これを短期的に見るとまさに「不経済」。

ただ、長期的視点で見ると結構大切な行動なのではないかと思っている。
そもそもソフトウェア開発なんて外からみて「何やってるのか、どれだけ大変なのか、いくらが適正なのか、etc」なかなかクライアントさんにはわかりづらい。
だからこそ、こうやって、一つ一つ丁寧に理解を得ていくことでしか、信頼を積み重ねていくことができないのも事実であり、その信頼関係を築くことが長い目で見て”Win-Win(懐かしい響き)”に結びつくのだと信じている。

今回は、信頼関係を築く事にコストをかけたと。

とても些細で小さなことだけど、信頼関係に大きな仕事も小さな仕事も関係ない。
どんな仕事や人間関係にしても、こうやってコツコツと積み上げることで信頼関係というものがようやく築けるわけだし。

P.S.
とかいいつつ、人間とは弱い者。
短期的に見て、非常に不経済だった自分の行動を自己正当化したいがために文章を書いた弱いエンジニアがこちら。
(1日でサクッと実装しちゃった方が楽だったな〜、笑)

このエントリーをはてなブックマークに追加