00:06
はい、みなさんこんにちは。keethことくわはらです。本日もやっていきましょう。
keethのエンジニア雑談チャンネル。この番組ではウェブ業界やエンジニアリング、いろんな技術についての情報を雑談形式で発信していきたいと思います。
で、今日はタイトルに挙げてます。体験を良くするためにどこまで痛みを受け入れるかっていう話ですね。
タイトルはぶっちゃけるとちょっとキャッチーなタイトルしたくて、言葉を強めただけで別に明確なアレがあるというわけではないんですけど、
我々クライアントワークを生業としている企業としては、体験設計とか体験を良くすることっていうのはものすごく大事な観点の一つだと思って、
ある意味で比較しても仕方がないし、別に比較できるものではないですけど、
自社プロダクトとかサース事業よりも体験設計っていうのが結構重要だろうなっていうのが僕らクライアントワークだと思ってます。
直接プロダクトを介してエンドユーザーとのお話をするか、それとも直でお客様とお話をしながら物事を進めていくかっていう、
この差は結構でかくて直で人とやり取りをするのが我々ですので、この体験設計はすごく大事だなっていうのをつくづく痛感をしています。
とはいえ別にサースとか自社プロダクトとかシステム会社の体験っていうのもかなり大事だと思いますね。
プロダクトの体験イコール会社の評価に直でつながるので、ここまでいっても場面というか文脈が違うだけで変わりはないんですけど、
体験をでも良くするために顧客のニーズに沿った機能を出したりとか、顧客のニーズに沿った場を提供する、それを満たしてあげるというのが一つ。
人のニーズっていうのは人それぞれバラバラですし統一的なものがあるわけではない。
サースの事業の会社さん、この顧客のニーズに合わせたいけど、こっちの会社さんのニーズに合わせるとそれってバッティングするし矛盾するよねとか、
このニーズは明らかにこのA社さんだけの固有のニーズだよなみたいなのがあったりするじゃないですか。
それを受け入れると自社プロダクトとか自社のサースプロダクトに関してのコンセプトが変わったりとか方向性変えてしまうなみたいなとか、
明らかにこれを満たすとコアな実装まで手を入れなおさなきゃいけなかったりして、結構巨大な変更だなみたいなところ、ゼロではないと思います。
そういう意味でバランスよくどこまで痛みを受け入れるっていうのはそういうお話ですね。
自分たちがでも提供したい世界観とかがあると思います。
それはもうクライアントワークだろうと自社サービスだろうと変わらないと思います。
その世界観にマッチした会社さんとかお客さんが一緒に仕事したいとか自社のプロダクトを使いたいっていうお問い合わせをしに来ると思うんですけど、
それを崩してまでこのお客さんと絶対この顧客が捕まえたいみたいなところをビジネス的に勝負しにいくかっていうのはすごく難しいお話で、
ある意味でどうしてもその会社さんにしたいって言ったら別にいいんですけど、
そのために今まで作ってきたブランドとかコンセプトを少し変えなきゃいけないってなると依存度高いのでリスクを引き上げることにもなるので、
03:08
そこをどう受け入れるかというか、戦略的に取るかっていうのはすごく難しい話だと思っています。
それでもこのお客さんが将来的に自分たちの会社を大きくするためにお付き合いしたいとか、どうしても応援をしてあげたいみたいな企業であるんだって話が変わりますけど、
本当の応援であれば株を買ってあげたりとか資本提供をしてお手伝いをするぐらいの方がスタンスとしてはいいかもしれないですけど、
僕らクライアントワークとしてはそういうことはしないでお付き合いすることになりますので、難しいところでありますね。
あとは僕ら受託というかクライアントワーク、内製化支援の会社の受け入れる痛みの中の一つに、どこまで仕様変更を受け入れるかというところですね。
わかりきっていることなんですけど、仕様通りいくはずなんてまあ欠片もないわけで、人は自分たちのことを全部わかっているわけがないんですよ。
そんな神様みたいな人ははっきりといないと思ってて。
かつ現場の人たちの細かな作業までを現場の監督者もしくは上の人たちが把握しているはずもないので、結局システム開発とかのお手伝いをさせていただいてますけど、
最初の要件定義とか要求定義で全ての仕様だったり全ての運用フローとか、今回必要な機能ってのはなんだみたいなのを全部言語化することは不可能なんですよ。
どうせ現場の人たちのやり取りしたりとか開発が進んでいく中で色々知識とか自分たちの設計みたいなのが熟成されていって、見えてくるものがどんどんあると。
後から見えてきて今まで出してきたものっていうのがやっぱり変わらざるを得ないよねって話は全然あるんですよね。
その後の時に今まで作り上げてきた土台設計っていうものをどこまで変えるかって話はあります。
そのためには仕様変更はやっぱり出てくるものなんですよ。
なのでクライアントワークとしては最初の見積もりを出す時に変更文も含めたバッファーという名目で入れたりします。
お客さんとやり取りしている中、関係値ができているのであれば最初から後ほどの仕様変更とかあるねとか未来の予測不可能な何かのための項数も取らせてくれみたいな交渉はしたりします。
なのでシステムとかウェブ開発やる中で本当の意味でウォーターホールって正直言うと現実的ではないんですよね。
それはやっぱり建築とかいう現場の中でできた言葉であって建築現場ではむしろウォーターホールで後から予測不可能なことが起きたらもう変更聞きようがないのでウォーターホールがむしろ正解なんですけど
僕らソフトウェアの開発とかをする中ではソフトウェアで柔軟に変更できたりするものであるので
やはりアジャイル的に変更を許容しながらどうやって組み込んでいくかっていうのをやるのが正しいのでウォーターホールでは破綻をするんですよね。
実際僕もこの業界十何年やってまして住宅開発10年以上携わってますけど一度としてウォーターホールで成功したプロジェクトは僕は見たことがないですね。
たまたま僕だけかもしれないですけど周りでも聞いたことは一度もないので変更ありきで物事を進めていくっていうのがソフトウェア開発者の大前提になるっていうのがあります。
06:09
これはウォーターホールであると絶対変更はするっていうのを言わなきゃいけない。
であればもう本当お客様に申し訳ないですけど言った最初の要件定義以上のことはもう一切やらなくて契約外ですねそれはって言ってはじくみたいなことをします。
でもそうするとお客さんとしての体験が悪くなりますよね。
なのでうちの会社の評価が下がるというのでやっぱ変更を受け入れるためにどこまで痛みを僕らが受け入れるかって話は結局開発側の方の話にはなってしまいますけど。
とはいえバッファーは全くつまらない見積もりをするからそういうことはなるので多少やっぱりアジャイル的に変更するっていう前提の上で見積もりを出していくっていうことが必要になる。
そのためにあるというとお客さんとの関係地を最初に作ることがものすごく大事だというので結局僕らソフトウェア開発者っていうのはコミュニケーションとかソフトスキルものすごい重要っていうのがよくわかるので技術とかハードスキルってのもめっちゃ大事なんですけどそれは実現するためですね。
描いたものを具現化するためのスキルってのもものすごく大事ではあるんですけどそれはやっぱりソフトスキルの上に立脚したお話だなっていうのは気はします。
なのでクライアントワークの会社であればあるほど技術を触れることも多いし技術的に幅広い挑戦をするのは確かなんですけど求められるのはハードスキルばっかりじゃないよっていうのはやはり伝えていきたいところはありますかね。
とはいえどこまで受け入れるかっていう話は僕もずっと悩み続けてますね。
僕らクライアントワークもそうですけどSaaS事業さんも結局はお客様っていうのを受け入れなきゃいけないビジネスモデルになったりするし自社プロダクトも自分たちのシステムとかアプリケーションを使ってくださるユーザーのための新規機能開発だったり今まで使ってきた機能のある意味廃止っていう判断をしなきゃいけないと思います。
物事とかプロダクトって進化し続けないとやっぱりユーザーって固定はするけど増やすことはできなかったり離脱も結構する可能性があるんですよね。
なので変化をどうやってもしていかなきゃいけないけど固定のユーザーがあるプロダクトであればあるほど今まで使えた機能の見た目が変わるだけで結構ユーザーってまず第一に批判をしたりしますよね。
もしくはそのまま離れちゃうユーザーも結構いますよ。
それぐらい変化をすることも難しいけど変化をし続けていかないと会社としては消されていく可能性は全然あるんですよね。
時代の変化環境の変化によって新しいユーザーたちのニーズと昔ながらのユーザーのニーズってまあ大体乖離するんですよ。
でも進化し続けていく中、今の時代のビジネスをしなきゃいけないとなると新しいユーザーの方に多分重きを置く会社さんの方が多いと思うんですよね。
でなると古い顧客をどこまでペイントして許容するかって難しいんですよね。
古いお客さんって言い方悪いんですけど昔ながらのお客さんであればあるほどちょっと年齢層が上がってくるのでそうすると落としてくれるお金の額はでかかったりするんですよ。
直接的なお話になっちゃいますよ。というのもあるのでどこまで受け入れるかってめちゃめちゃビジネスのバランスが難しくて、
09:00
これはでもなかなかエンジニアの方々ってあんまり意識しないんじゃないかなって気はしますね。
わかんない。僕がたまたまそういう人たちの周りにいるだけかもしれないですけど。
なので結局はビジネスありきで物事を作っていくってのはそうなので会社としてとかプロダクトとして受け入れるところを受け入れるバランスは考えるんですけど、
いざそれを実装の場に落とし込むとなんでそんな話になったのっていう。
今度は現場の中の現場の人たちとのバッティングが起きそうだなっていうのもあって、
マネージャーの方とかシステム開発の運用する側の人たちの大変さってこの辺にあるよなっていうので。
で何が大変かってこれの明確な答えも基準もないわけなんですよね。
結局その場に応じてどう判断するかっていう不確実性と向き合わなきゃいけないお仕事なのですごく
いやー責任重いよなと思いつつ。
まあでもこれがピタッとハマった時の快感はたまらんし、
これで市場のニーズにしっかり合ったプロダクトを出せた、自信持って外に出せたって
いやー胸張れる体験はすごく良いので、
マネージャーの槍が横にあるよなと思ったりはしますけど。
とはいえこの受け入れをする基準とかっていうのはもう本当人依存になってしまうんで、
そのマネージャーさんとか監督の方のさじ加減が物多い世界なんでね。
まあ本当は経験値が良かったりものすごい知識量多い人の方が信頼性は高いかなっていう感触はありますけど、
とはいえちゃんと現場の人たちとお話ができるっていうのはすごく重要なので、
結局コミュニケーションスキルっていうのはソフトウェア開発の現場でも超重要で、
マストスキルだよなって思ったりはしました。
っていうところでざーっと喋りましたけど、
今日喋りたかったことはこんな感じです。
誰か答えというか、明確なこういう基準でやれば上手くいくみたいな銀の弾丸を作ってくれたらめっちゃ嬉しいんですけど、
まあ人と仕事をする限りそんなものは存在しないので、
しっかりこれからもお客さんとかユーザーと向き合いつつ、
僕らもソフトウェア開発を頑張っていきたいなっていうようなお気持ちです。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
