作る人と使う人の間に誰かを挟んではいけない
こんにちは。DeployGateの藤﨑です。
昨年の1月に思い立ってから、12ヶ月続けて毎月noteを書いてきました。
ここまで、概ね直近の出来事やチームについて書いてきたのですが、今回はちょっと趣向を変えて、DeployGateに繋がる自分自身の原体験的な話を共有してみたいと思います。
学生生活も終わりの頃の話です。
知り合いのツテで、携帯向けWebサイト開発の仕事をもらうことになりました。
ソフトウェア開発の下請けのお仕事です。
内容は小規模ながらちょっと変わった仕様の、3キャリア対応のECサイトのシステムを作るという感じでした。
開発業務の委託を受けるのは、これが初めての経験でした。
顧客の要求をもとに、元請けの担当者によって画面遷移と仕様がつくられ、それが自分のところに降ってきて、開発をする。
仕様も大枠と遷移以外の本当に細かいところは任されており、最終的な確認は顧客側で行う形でした。
当時、私は滋賀県に住んでいて、元請けと顧客は東京の会社です。
完全にリモートでの仕事で、顧客への確認もすべて元請けの担当者を通じて行われていました。仕事においてはまだSlackのようなチャットツールは一般的ではなく、最初の電話以外はメールでのやり取りで、大体1営業日ほどで返事が返ってくるような、のんびりとした進行をしていました。
仕様として決まっていない部分をいくつか残しながら開発をスタート。実装自体は大きな障害もなく2週間ほどで終わりました。その後、先方が一通り納品物のチェックをし、指摘をもらって、修正して確認を依頼し…1ヶ月ほど経って大きめの仕様変更が入り、また2週間ほどで修正して、確認して、指摘をうけて修正して…
そんな開発も終盤に差し掛かった頃の出来事でした。
顧客がテストで送信したデータの中に、システムの不具合について書かれたと思われる内容がありました。
気になって確認してみると、それは実際には顧客の入力した値の誤りによるもので、不具合ではありませんでした。
しかし、利用者から見たときに「値が正しくない」ということが分からず、不具合だと勘違いしてしまっても不思議ではない状態でした。
元々の仕様には含まれていない内容ではありましたが、実際のユーザーが同じ問題を踏んでしまうことは容易に考えられるため、修正をかけた方がよさそうです。
このようなとき、普通は元請けの担当者に修正の提案をします。
しかし、その時の私はどういうわけか、データに入っていた顧客のメールアドレスに対して「こういう現象でした、分かりづらいので修正を検討しますね」という旨を返信していました。
すると、10分もしないうちに、その顧客から返事が送られてきました。
顧客からの返事のメールにあったのは、まず
「自分用のメモに書いたつもりが返事が来て驚いた」
という一文。
そりゃそうです。これまでやり取りもしてない下請けの開発者から突然メールが来たらそりゃ驚きます。自分でも、なんでそんなことをしたんだ、と思いました。驚かせてしまって申し訳ない気持ちです。
その後には、
「どうも色々ありがとう、仕様変更を何度もして本当に申し訳ない」
「自分が妄想したプログラムがこうして自分や友達の端末で動いているのを見て本当に興奮しています」
「できあがるのを本当に楽しみにしています」
という感謝と期待の言葉が続いていました。
びっくりしました。
ここに至るまでの担当者とのやり取りの中には、顧客がどのような反応をしていた、という話はありませんでした。
ここまで大きな指摘なども受けていないし、作ったシステムはそれなりに顧客の要望を満たすものができているのだろう、ぐらいに思っていました。
しかし、実際の顧客は、わざわざ感謝を伝えてくれるほどに喜んでくれていました。
また、このメッセージを通じて、このプロジェクトが実は顧客にとっても初めてのソフトウェア開発であったことを知り、開発途中にあったいくつかの小さな疑問に合点がいきました。
このメッセージは私を本当に嬉しくさせてくれました。
もう開発はほぼ完了しているのに、なにか、もっと協力できることがあれば協力したい、という気持ちになりました。
自分の力で誰かの思いを形にすることができている、という実感が得られた瞬間でした。
そんな喜びの気持ちの一方で、気付いたこともありました。
作る人と使う人の間に誰かが挟まることで、こんなにも伝わらないことがある。
思い返すと、この開発の仕様を読み解く最中、本来そこにあるはずの意図や感情は推測で見いだすしかありませんでした。
それについて何か一つ確認するのも担当者を挟むことで時間が必要がかかり、そもそも聞けるのかどうかも分からない状態でした。
ここには、書かれているとおりに作って、確認してもらって、指摘をもらって、直す、以外の選択が難しい状態が構造的に生まれてしまっています。
もちろん、間に挟まっている担当者は、何も悪くありません。
顧客の要求を適切にヒアリングして仕様に落とし、開発ができるように情報を整理し、完成したシステムの受け入れ確認を行い、その間の情報の伝達を責任を持って進め、もし何か問題が起きていたとしたら、吸収して整理に動く…という責任をしっかり全うしています。
なにより、自分に仕事をもたらしてくれました。
でも、自分がもらったこの喜びは、そのフローの外側に起きてしまった「直接のやりとり」がなければ得られなかったものでした。
顧客の想いの乗ったプロダクトを開発するには、担当者によるファシリテーションに加えて、開発者と顧客の直接のコミュニケーションが必要なのだと思いました。
どんなプロダクトも、突き詰めると、人と人とのやり取りで生まれるものです。
その二者の間に、できるだけ何も挟まないようにすること。
誰かのフィルタを通さず、直接自分が話して見て聞くこと。
その大事さに気づかせてもらえたいい機会でした。
最近、すっかり忘れていたこの体験。
久々に思い出したので、今回書き残しておこうと思いました。
そして、この体験を誰もができるように、DeployGateも少しずつ「開発中の生の声」を得やすい仕組みとして整えて行きたいと思いました。
これからの道中、そのためにやらなければならないことが果てしなくあるけど、とにかく、直接自分で見て聞くことを忘れずに進めていこう。
そう改めて思った1月でした。
P.S.
なお、最終的にシステムはリリースされ無事に稼働しました。
いただいた報酬は、就職先の東京に引っ越すための資金となりました。
そして、ここで生まれた「協力したい」という気持ちは、次のお仕事に繋がりましたとさ。
めでたしめでたし。
追記: そういえば1年ぐらい前に広木さんも「WHATよりWHYを伝えよう」言うてたなというのを思い出しました。誰かが間に入って情報をまとめるときも、できるだけその背景が見える形で共有することで生産性向上に大きく寄与しますね。ちょっと通じるところあるので貼っておきます。
この記事が気に入ったらサポートをしてみませんか？