どうしましょう？という聞き方を卒業しないと成長しない。

一般的に企業では「わからない事があったら迷って考えてる時間が無駄だからわかる人にすぐ聞いて」と言われる事の方が多いと思いますが、ベクトルではスタッフには「どうしましょう？」という聞き方をしないようにお願いしています。

もちろんチームに加入したばかりで、まったく初めてやる業務や組織のスタンスなどが何もわからない時期は普段の対応を聞いていただいた方が良いのですが、今回は組織や業務の一連の流れに慣れた段階での話です。

ベクトルで「どうしましょう？」という場面といえば

• ここの仕様どうしましょう？
• こういう問い合わせ来たけどどうしましょう？
• 手が空いてますけどどうしましょう？

が多いです。

そういうケースの場合に「どうしましょう？」ではなく「こうしようと思いますけどどうでしょう？」と聞いて欲しいのです。

これは、そこそこ組織化された企業だと話は別になるかもしれませんが、スタートアップやフリーランスではわりと同様なのかなと思いブログという形で共有しようと思い公開しました。

どうしましょう？が良くない理由

組織も本人も成長しない

まず大前提として、「どうするか自分で考えて」と言っても、完璧な判断を求めているわけではありません。そもそも論で「完璧な判断」自体が存在しませんし。

でも組織が成長するためには判断できるリーダーを増やさないと、既存のリーダーの目の届く範囲が限界になってしまいます。

判断できるリーダーを増やしていかないとチームとしての規模が成長しない。そのためにまずは自分としては何がベストなのか考えるという習慣をつけて欲しいのです。

その自分の考えを持った上で、その判断で進めて大丈夫かを聞く事を繰り返す事によって、既存のリーダーと判断が一致する率が高くなって、次のリーダーに成長していくのかなと思います。

替えが効く人か、この人じゃないと駄目か？

僕個人の考えですが、そもそも仕様をすべてドキュメントにして用意する必要があるのであれば、依頼先がその人である必要はなくなってしまいます。それは本人にとっても「替えがきく人物」でしかないので、会社員であってもフリーランスであってもその姿勢では安い単価の仕事しか取れません。

ところが「その問題だったらこうしたらどうでしょう？」「その機能だったらこういう仕様でどうでしょう？」と提案できるなら、発注者としてはとても楽になるし、実装者も「提案・仕様設計」でも稼げる人になる。提案・設計が出来る人となると数が一気に減るので「替えがきく人」と「この人じゃないと駄目」では単価も全然違います。

もちろん人間的にプログラミングに特化していて、仕様調整の打ち合わせやドキュメント作成に向かない人はいます。それでも実装スキルがズバ抜けていれば仕事は取れますが、そうでない場合は単純に安い仕事しか取れないままになってしまいます。

内部スタッフであれば、ベクトルの仕事をずっと今の報酬で行うならそれでも良いかもしれませんが、もっと条件の良い会社に移籍したり、将来フリーランスになったり、自分のサービスで独立したり、次のステップに上がるためにも、まずは組織にとって今何をする事がベストか自分で先に考える事を当たり前にして欲しいです。

実装スキルが極端に高いからと言って仕事がとれるとは限らない

「コミュニケーションスキルよりも技術力で勝負するから」と思う人もいると思いますが、発注する側の視点では「高度な技術を持つ人でないとできない」＝「リリース後にその人と連絡が取れなくなったりするとメンテ・改修で困る」という事で敬遠されたり、高度な技術を要する内容だからこそ仕様などの意見交換もできる「信頼できる人」にしか仕事は来ないので、仕様を自分で考えて提案できるという事はとても重要なのです。

仕様（仕事）は自分で作る

若干話が逸れますが、類似事項で仕様の策定について。

僕も若い頃は「構成ください」「原稿ください」「仕様ください」と平気で言っていて、

「クライアントが出してきたこの微妙な仕様で作ったから、まぁこのクオリティーだよね。」
「自分だってもっと大手の案件とかあったらクリエイティブなサイト作れるのに…。」

などと思った時代もあったのですが、そうじゃない。

もっといいモノを作れるなら自分から提案しないと仕事なんて落ちてきません。

相手は専門家じゃない。専門家が最適なプランを企画・提案する。
作りたいアイデアがあったら自分で提案する。

そしたら意外と普通に取れたりするし、企画から入ると受注単価も高くなる。

自分も、若い頃は「提案」なんて無縁の製造業の部署に長年居たので、最初は仕事は「決められたものが落ちてくるもの」という意識が潜在的にあって、「クライアントに提案」という発想自体遠い存在だったのですが、ウェブ制作やシステム開発は思った事やクライアントの意向を纏めて仕様を作ってこそ仕事に繋がります。

「仕事がない」と言っているフリーランスやフリーランスを目指してウェブ制作やプログラミングをしている人は、そこが出来ていない事が原因である事が多いと思います。

---

チーム内での話に戻すと、何か懸案事項があって、対応するもの作ろうとなった時に、過去在籍したスタッフも含めて仕様の話をしてると、

「じゃあ仕様纏めてください」

と言われる事が昔からちょくちょくある。

いや、そうじゃない。

今説明してるんだからそれをまずメモろう。
そしてそれを自分が纏めよう。

仕様を纏められる人になろう。

先述の話と同じで口頭で説明してたのに結局仕様をこちらで用意しないとできないなら、今話してた時間最初から要らなかったし、仕様書書くなら依頼先は他の人でもよくなってしまう。

受託案件でウェブ制作やシステム開発の相談がきたとして、依頼内容を説明し終わったクライアントに対して

「それでは改めて仕様纏めて送ってください」

という業者Aと、

「じゃあ今日のお話一旦纏めて提案しますね」

という業者B、どっちが受注して、受注単価にどれくらい差が出るか？という事です。

業者Bのような所は受注した単価の半値以下で業者Aに実装を発注したりする事も珍しくないでしょう。

そのくせ業者Aのスタッフは「業者Bは何もしてないのにウチの見積もりの半分以上も上乗せしてぼったくってる」と文句を言ったりする。

だから「どうしましょう？」と仕様を聞くのではなく、自分としての最適な案をまず考えて欲しい。

ベクトルの場合あくまでチーム内部なので、もしその案が依頼者の意向に沿っていなくても、フリーランスのように「失注したら労力かけて提案したのに収入もない」というリスクもなくスキルアップもできるので、積極的に利用して貰えたらいいなと思います。

内部的な案件の資料なら伝われば手段は何でも良い

仕様を作るといっても、知識のないクライアント向けに資料をご丁寧に作る必要はないので、文字だけでも良いし、伝わりにくければFigmaだろうとGoogleスライドだろうと、モックアップ組んだ方が早いならそれでも良いと思います。

相手に仕様を伝える手段を状況に応じて使い分けるのもスキルの一つなので、とにかく「自分で考えた事を口頭・文章・図・モックアップなどで伝えてそれで方向性が合ってるか聞く」というようにすれば「どうしましょう？」という聞き方をしなくてもよくなると思います。

自発的な人とする事の楽しさ

現在ベクトルは社員・業務委託を含めてたくさんの人が一緒に働いているのですが、僕がお願いしなくても

「これやった方がいいですよね？ 」「やっときました！」

という事が多々あって、そういう場面は物凄く頼もしい、嬉しい、感謝なのです。

「これお願いします。」→「これできました。」だと想定内なのですが、手の届いていない所やそもそも僕が気付いてない所を

「これしましょう！」→「これやっといたよ！」と来られると、僕としては

「ふぁー！あざーっす！」と、とても嬉しいし、他の人にとっても

「あら！そうきたの！やるわね！さすが！」とテンション上がるわけで、

我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。

という悪い意味で僕の脳内に影響を及ぼしてしまっている超有名な荒巻氏のセリフがあるのですが、少しだけ近づいているのかなとも感じます。

※ とは言え、僕レベルのリーダーの場合はスタンドプレーに頼るのは只の怠慢なので、チームプレーが当たり前にできる組織づくりを善処したいと思います。

「これやりますね」の宣言を飛ばして「これやっといたよ！」をしてしまうとトラブルになる確率が高いので、何をやるかは事前に報告した方が無難です。

「聞くな」と言ってるわけではない

ここまでのくだりを読むと、わからない事を「聞きにくい」という印象になってしまうかもしれないのですが、「聞くな」と言っているわけではなくて「自分はこう思うけどこれでどうでしょう？」というように、自分の考えを用意した上で聞いて欲しい。

自分に振られていたタスクがなくなった時も「何しましょう？」ではなく、チームの中でするべきタスクを自分で考えて「これやろうと思うけど良い？」と聞いて欲しい。

そもそも言われた事そのままやるだけの仕事なんてつまらなくないですか？
自分がやってみたいと思う作業しましょうよ。

そうやって、リーダー不在の時でも自然に機能する組織ができるのかなと思います。

「すぐ聞いて」の方が良いケース

最後に例外です。

前例があるか？は事前に聞いて欲しい

単純に過去に前例（実装など）があったりする場合などはその資産を流用できればした方が早いので、前例や参考資料知ってるか聞いていただいた方が、誰かが有効な内部資料・外部資料がある時に提供して貰えて仕事も早くなると思うので、そういうのは遠慮なく聞いた方が良いと思います。

とは言え…

自分もちゃんと伝わる仕様を書くようになるべく善処したいと思います…。

この記事を書いた人

石川栄和代表取締役

名古屋のウェブ制作会社数社に10年程度務めた後、株式会社ベクトル設立。
企画・運営・コンサルティング〜WordPressを中心としたシステム開発まで幅広く携わる。
[ 著書 ]
・いちばんやさしいWordPressの教本（共著）
・現場でかならず使われているWordPressデザインのメソッド（共著）
[ 最近のWordPressコミュニティでの活動 ]
WordCamp Tokoy 2023 セッションスピーカー
WordCamp Asia 2023 セッションスピーカー（LT）
WordCamp Niigata 2019 セッションスピーカー
WordCamp Haneda 2019 セッションスピーカー
WordCamp Osaka 2018 セッションスピーカー
WordCamp Kyoto 2017 セッションスピーカー
他

最近の投稿

• WordPress2025年4月9日AIコーディング時代の到来によって手を動かすだけのエンジニアは完全に淘汰されるのか？
• WordPress2024年12月25日2024年リリースのイチオシ機能を一挙紹介！
• WordPress2024年12月1日ベクトル製品リリースタイムラインから見る開発の裏話と進化の歴史
• WordPress2024年10月30日ブロックテーマで編集権限のユーザーでもメニューを編集できるようにする