発注前や発注後によく発生するのが「打ち合わせ」。メールやチャットのテキストコミュニケーションが増えてきたとはいえ、直接やり取りしたほうがわかりやすいことや効率がいいことはまだまだたくさんあります。
仕事上、ウェブサイトの制作や改修、ECサイト構築やシステム開発などを行うことが多いのですが、開始前に全体像や概要の説明や、まだ確定していないけどざっくりとこんなことできるか、といったことは話しながら「ここはどう考えていますか」「その場合はこんな方法もあります」などのキャッチボールがその場でき、「それはこうです」「その場合はこういうのもできますか」などの話の展開が容易のため、テキストでやりとりするより双方やりやすいと感じます。
一方、プロジェクト開始後に順調に進んでいき、一度確認をしてもらってフィードバック・修正依頼をもらう際は打ち合わせで実施するのではなく、テキストベースでもらうことをおすすめします。
※他の業種も当てはまるかもしれませんが、サイト制作やシステム開発等に絞って書いてます
目次
打ち合わせで向いている作業・向いていない作業
打ち合わせは参加者同士が同じ場所に集まり、打ち合わせの議題に対してあれこれ意見を交わしていくもの。会社や組織の方針で「ウチは全部Slackでやりとりします」等あるかもしれませんが、ざっくりと打ち合わせが向いているものを上げると、
- 制作前の相談
- 改修や制作の概要の説明
- 進行中プロジェクトの定期的な進捗状況の共有や軌道修正
- キックオフミーティング
- アジャイル開発で作りながらフィードバックを返していく進め方
- テキストだと伝えづらい話
など。逆に、打ち合わせが向いていないものは、
- フィードバックや修正依頼
- メールで送った内容をなぞって確認するための打ち合わせ
などです。前者だと例えば制作前にこんなことをやりたい、こういうことを実現したい、という大枠の相談をしてもらって、今の現状を踏まえて技術的にできたとしても予算的に合わないというのも往々にしてあるため、そのあたりの費用感を伝えつつ、最初から全部盛りにするのではなくまずはここまでを実現しましょう、という話をしてOKもしくはそれならこうしたい、というすり合わせをしていく作業が向いています。チャットでも個人的には問題ないと考えていますが、チャットに慣れていない方もいるので、そのあたりは相手が普段使っているコミュニケーション方法に合わせるのがいいでしょう。メールは返ってくるまでにタイムラグがあるため、数日にわたって議論をすると最初の方に話していた記憶があいまいに…なんてことも。
後者は基本的にやりとりが発生せずに確認だけで済むことです。今回挙げたフィードバックもここに入ります。打ち合わせをしたいというので実施したら、メールで送ってくれた内容をただなぞるだけという打ち合わせも実際にありました…。きっと、この内容で大丈夫かと心配してくれてるんですよね（そう思いたい）
なぜフィードバックはテキストでもらうのがいいのか
理由は大きく3つあります。
- 言った言わないをなくす
- 途中の仕様変更をなくす
- 効率をよくする
言った言わないをなくす
修正箇所・フィードバックをミーティングで実施場合、相手は「ここをもっとこうして〜」と口頭で伝えます。内容的には問題ないとしても、対応する方はすべてメモする必要が出てきます。話を聞きながら、できるかできないかを考えつつ、言ったことをメモする。普通に考えて大変ですよね。なので、聞きながら主要な部分だけメモする、またはメモが追いつかないなどの問題が発生します。
修正対応の結果、「打ち合わせではこう伝えました」「言ったことが治っていません」「ここはこういう意味で依頼したので、修正してください」というような言った言わない問題へ展開してしまう可能性が上がります。これは双方望んでいる状況ではないため避けるべきです。
途中の仕様変更をなくす
相手が修正項目を書き出した上でミーティングを実施したとします。事前に議題を共有してくれているため、打ち合わせしながらメモせずに済みます。ところが、ミーティングでは「この部分はこうできますか？」「こうしたらどうなりますか？」と、当初仕様にはなかったことを聞いてくる可能性があります。相手にとってはただできるかどうか確認しているだけの場合が多いんですが、こちらからすると「（要望の通りに変更すると、別の場所に影響がでるから、そこも修正して、そうすると最初に定義した部分も修正しないといけないから、当初の仕様から変わるけど、できないことないから）できます」という回答になることがあります。
相手からみたら仕様変更をしている意識はまったくありませんが、こちらの作業は増加しています。打ち合わせ段階でここまで予測できればいいのですが、誰もがスーパーマンではないため予測できないことも多々あり、「修正できるって伝えたけどここ修正しないといけない」みたいなことが出てきます。そうなると判明した時点でクライアントへ伝えることになります。さらに再度打ち合わせが発生するということも。テキストでもらっていれば、このような無駄な作業は発生する確率を下げられます。
効率をよくする
打合せを実施するとなると、当たり前ですが時間を確保しないといけません。特にエンジニアやプログラマーにとってはいかに1日を効率よく作業できるかによって納期も質も大きく変わってくるので、ミーティングで時間を使う＋前後の集中が途切れるため開発効率が落ちます。
いまではコロナの影響もあって打ち合わせはオンラインミーティングが主流になりましたが、対面打ち合わせの場合は打ち合わせ場所まで出向く必要があり、前後の移動時間も考慮する必要があります。（個人的にはオンラインミーティングがこのまま主流になっていってほしいと願っている）
特にフリーランス・個人事業主・ひとり会社のエンジニアとして働いている場合は時間=売上に直結するためシビアに考え、テキストで済む・テキストの方が効率が良いと判断できる打ち合わせは積極的にテキストでもらうべきです。（打ち合わせが多くなると「仕事してる感」だけ増え実際は全然進んでいないという状況に陥りがちなので注意）
フィードバックはテキストでもらうことを要件にいれてしまう
「そんなこと言っても、相手からフィードバックの打ち合わせをしたいと言われたらそうせざるを得ない」
そうならないように、要件や見積書内にいれてしまうことをおすすめします。「修正に関して：テキスト形式にて依頼」などのように。
この記載を外すように依頼してきたり、どうしても打ち合わせを実施したいという場合は別途費用にて対応するか、そもそもそういうことを言ってくるクライアントとは付き合いを考えてもいいでしょう。今までそんなことを言われたことはありませんし、大抵のクライアントは問題ないはずです。
私は以前、というかずっと長い間フィードバックに打ち合わせを希望されたら対応していましたが、とある案件でとても大変な思いをしました。それ以来、テキスト形式でもらうように変更しました。それにより、フィードバックを打ち合わせで希望されても「要件に書いています」と伝えられますし、実際テキストでもらうようになって認識漏れも少なくなり使える時間も増え効率が上がりました。結果的に無駄なコストが発生せず、それは工数増加による余計な費用が上乗せされないというクライアントへのメリットに繋がります。
といっても、「要件通りになっていない」「希望したものと異なる」等で、こちら側のミスによる場合は再度すり合わせのための打ち合わせを希望されたら実施しましょう。なんでもかんでも要件に書いてあるからというので決めるのではなく、ときには歩み寄りも必要です。重要なのはプロジェクトの成功ですから。
コメントを残す