こんにちは、キノトロープアカデミーです。

「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。

＜中級編 第8回＞
【Webエンジニア向け】企業価値を高めるWebサイト開発手法 の第四回をお届けいたします。

担当は高橋です。

本記事では、Webエンジニアやディレクターに向けて、社内他部署や外部ベンダーへの「開発発注」で発生しがちな納期遅延や仕様の食い違いといったトラブルの原因と対策を解説します。

発注側の「伝えたつもり」「分かってくれているつもり」という思い込みが失敗の元であると指摘し、定期的な進捗確認やプロジェクトの成果・目的を共有する「成功する発注のための三ヶ条」を解説します。

単に指示書を渡すだけでなく、「なぜこの機能が必要なのか」という熱量を発注先に伝えるコミュニケーションを通じて、プロジェクト全体の成果物の品質を最大化する手法をご紹介する内容となっています。

”企業価値を高めるWebサイト開発手法”をテーマに、
今日お伝えしたいことは3つあります。

まず初めに、開発発注における「よくあるトラブル」をいくつか挙げてみたいと思います。

これらのトラブル事例には一つの共通点があります。それは、発注側が「進捗を確認していたつもり」「仕様を説明したつもり」、 そして「先方は分かってくれているつもり」という、すべてが「やったつもり」の思い込みになってしまっている点です。

前回の動画では「開発見積」についてお話ししましたが、見積時のトラブルと同様、自分はベストを尽くした「つもり」になっていることが、そもそもの発端であるケースが多く見られます。もちろん、本当に発注先のクオリティに問題がある場合も考えられますが、それ以前に、自分の発注の仕方に本当に問題がなかったかどうかを見直す必要があります。

「納期が遅れてスケジュールに影響する」「想定していた仕様と異なる」「想定外の費用が発生する」、これらはすべて、プロジェクトの成果・目標に反する事象といえるでしょう。

これまでは、成果や目標をまずは「自分が」意識して仕事をするということに重点にお話をさせていただきました。

ここで一段階ステップアップして、自分が直接担当する成果物だけではなく、発注先の成果物をいかにプロジェクトの成果・目標に近づけるか、という手法をお伝えしたいと思います。

第一条はスケジュールにかかわるトラブルを回避するための心得です。

先ほどのトラブル例では、「納品予定日の直前」になって慌てているので、おそらくそれまで発注先になんの確認もしていなかったと思われます。

悪い報告ほど後回しになりがちなので、発注先には定期的に進捗報告を依頼してください。報告がない場合や遅れている場合であれば、何か悪いことが起きている前兆ですので、必ずこちらから進捗確認を行って状況を把握してください。

また、リマインドについては「この日を過ぎたらスケジュールをリカバリできない」という日の一週間前にリマインドを行ってください。リスク回収が可能な期間までに報告を受ければ、クライアントへの報告やスケジュールの再調整などのリカバリ対応を行うことができます。

ただ、リスクやリカバリの判断にはある程度のプロジェクト経験が必要ですので、経験が浅いうちはとにかく発注から納期までの期間は定期的に進捗を確認し、少しでも予定と異なる場合はすぐに上長に報告するとよいでしょう。

第二条は仕様にかかわるトラブルを回避するための心得です。

Aさんの発注方法が「こういう機能を実装してください」であるのに対し、Bさんの発注方法は「サイトを訪れるお客様のためにこういう成果を出したい。だから、ぜひ御社にこの機能を実現してほしい」というものです。

さて、あなたがクライアントなら、どちらの発注方法のほうがモチベーションは上がるでしょうか。ただやってほしいことを伝えるだけでは、プロジェクトの本来の目的である成果や目標を発注先に伝えることはできません。「何を成し得たいのか」を明確に伝えて、成果の達成に発注先を巻き込みましょう。

もちろん、伝えてからの対応は発注先のクオリティに左右されますが、まずは自分自身がベストを尽くすことが重要です。心ある発注先に仕事に対する熱量が伝われば、必ず成果物の品質向上につながるでしょう。

第三条はコストにかかわるトラブルを回避するための心得です。

今回挙げたトラブル例は、成果物が依頼した内容と完全に異なっていたケースではなく「そこまで細かくは伝えていなかったけど、やってもらえると思っていた」ケースが該当します。

「想定していた仕様と違う」という言葉、あなた自身がクライアントから言われたことはないでしょうか。「事前に指示がなかったので追加費用がかかります」という言葉を、あなた自身がクライアントに対して返したことはないでしょうか。

クライアントはWebサイト構築のプロではありません。なので、前回の見積編の動画でお話しした通り、プロであるあなたから事前にクライアントとの認識のずれがないように働きかける必要があります。

社内の他の部署や、社外の開発ベンダーへの開発発注でも基本的には同じです。先方はもちろん開発に関してプロではありますが、Webサイトでのお客様へのサービス提供に関してはプロではありません。発注用の資料を作っていて、「さすがにここまでは書かなくてもいいかな」と少しでも思ったら、その内容は省略せずに記載してください。

ひとつひとつの仕様項目について、「なんのためにこの機能が必要か」「こういう仕様の前提でないと成果が出せない」等、成果と目標にかかわる内容をなるべく具体的に記載していきましょう。

そこまで書いても完全には伝わりづらいものですから、もし省略したら必ずと言っていいほど伝わりません。「なぜ」の粒度をなるべく細かく、かつ具体的にブレイクダウンして伝えることで、その仕様の必要性が伝わりやすくなります。

いかがでしょうか。まずは自らが「この機能を実現すれば必ず成果を達成できる」と信じること、次に発注する相手にそれを明確に伝えることが重要です。自らが信じていることを語らないとなかなか人は動きません。

サイモン・シネックの有名なスピーチ動画で、「何を」からではなく、「なぜ」から伝えるという主旨のものがあります。「優れたリーダーはどうやって行動を促すか」というタイトルですので、機会がありましたら是非ご覧ください。プロジェクトを牽引するためのコミュニケーションの仕方がいかに重要であるかの理解が深まるかと思います。

是非、明日から、今日ご紹介した三ヶ条を実践してみてください。

最後までご覧いただきありがとうございました。

の３点についての内容でした。