システム開発を依頼して、打ち合わせも終わり、開発がスタートする。そこからしばらく、開発会社から目立った連絡はありません。

「きっと順調に進んでいるんだろう」と思いながら待っていると、納期が近づいたある日、突然連絡が来ます。

「完成しました。ご確認ください」

渡されたシステムを開いて、そこで初めて、何ができあがったのかを知る。福袋なら楽しいかもしれませんが、システム開発では笑えません。

嘘のような話ですが、途中経過をほとんど共有せず、最後に完成品を「はい、どうぞ」と渡す開発会社は実際にあります。私たちEFGは、このような進め方をしません。システム開発は、完成品だけが合っていればよいものではありません。開発の途中でお客様にも状況を見ていただき、認識を合わせながら進めることが大切です。

完成するまで何も見えない。それが一番怖い

システム開発を発注するお客様の多くは、ITの専門家ではありません。

開発会社から「現在は設計中です」「実装を進めています」と言われても、具体的にどこまで進んでいるのか、予定どおりなのかを判断するのは難しいと思います。だからこそ、開発会社には状況を分かりやすく伝える責任があります。

途中の状況が見えないと、お客様は「順調だと言われたから、順調なのだろう」と信じるしかありません。しかし、認識のズレや仕様の問題は、完成した瞬間に突然生まれるものではありません。もっと前の段階で、小さなズレとして発生しています。

その小さなズレを共有しないまま開発を続けると、最後になって「思っていたものと違う」という大きな問題になります。

EFGは、開発をブラックボックスにしない

EFGでは、開発を始める前に、進捗をどのように共有するかをお客様と相談します。

どれくらいの頻度で打ち合わせをするのか。どのような方法でタスクを確認するのか。開発途中の画面を、どの段階で見ていただくのか。こちらから進め方をご提案し、お客様のご要望も伺いながら、両者が納得した状態で開発をスタートします。

すべての案件を、まったく同じ方法で進めるわけではありません。システムの規模、開発期間、お客様の社内体制によって、ちょうどよい共有方法は変わります。「EFGでは絶対に毎週この形式で報告します」と、一律に決めることが大切なのではありません。

大切なのは、お客様が開発の状況を把握できる状態をつくることです。

• STEP.1 共有方法を相談する
  開発を始める前に、打ち合わせの頻度やタスクの確認方法をご提案し、お客様と一緒に決めます。
• STEP.2 定例会で認識を合わせる
  開発初期は週1回程度を基本に、案件の規模や進み方に合わせて頻度を調整します。
• STEP.3 Backlogで状況を開く
  タスクの進行状況や確認事項を、お客様にも見える形で共有します。
• STEP.4 途中の画面を確認してもらう
  必要な段階で作成途中の画面を見ていただき、完成前に認識のズレを調整します。

開発の初期は、少しこまめに話す

開発の初期は、お客様と開発会社の認識を合わせることが特に重要です。そのためEFGでは、最初のうちは週に1回程度、定例の打ち合わせを設けることが多くあります。

開発の目的、機能の考え方、画面のイメージなど、最初に合わせておきたいことが多いからです。この時期にしっかり話しておけば、後から大きなズレが見つかる可能性を減らせます。

一方で、長期間にわたる案件では、途中から隔週にすることもあります。開発内容によっては、1週間では見せられるほど状況が変わらないこともあります。

それでも「毎週と決めたから」という理由だけで定例会を開くと、「今週は、先週から大きな変更はありません」「分かりました」「では、また来週」という会議が生まれます。これでは、お互いの忙しい時間が静かに消えていくだけです。

Backlogで、タスクと状況をオープンにする

定例会のない日に、開発状況がまったく分からなくなるわけではありません。

EFGでは、タスク管理ツールの「Backlog」を使い、お客様にも状況を確認していただける形で開発を進めています。

何に取り組んでいるのか。どのタスクが完了したのか。現在、確認が必要なことは何か。こうした情報を、開発会社の中だけに閉じ込めません。

お客様から確認したいことがある場合も、Backlog上でやり取りできます。話した内容や判断の経緯が残るため、「あの件はどう決まったんでしたっけ」というときにも振り返れます。

口頭だけのやり取りは、その場では早いのですが、時間がたつと記憶が少しずつ変わります。人間の記憶は、残念ながら自動保存されません。記録を残し、両者が同じ情報を見られる状態にすることも、認識のズレを防ぐために重要です。

完成前の画面も見てもらう

開発がある程度進んだ段階で、お客様に作成途中の画面を見ていただくこともあります。

もちろん、まだ完成品ではありません。見た目が整っていなかったり、一部の機能が動かなかったりする場合もあります。それでも、途中の段階で実際の画面を見ることには意味があります。

文章で説明を受けているときには問題ないと思っていても、画面を見ることで初めて気づくことがあるからです。

「このボタンは、こちらにあったほうが使いやすい」「この項目は、現場ではこの順番で確認している」「この画面は、想像していた使い方と少し違う」。こうした気づきを早い段階で共有できれば、まだ調整しやすい段階で対応できます。

すべてが完成してから同じ話が出ると、修正する範囲が広くなり、追加の費用や期間が必要になる可能性もあります。完成前に見せるのは、未完成のものをお客様に押しつけるためではありません。完成後の「思っていたものと違う」を防ぐためです。

悪い知らせほど、早めに共有する

システム開発では、予定していたとおりに進まないこともあります。調査を進めた結果、想定より複雑な処理が必要だと分かることもあれば、外部サービスの仕様によって、当初考えていた方法が使えないこともあります。

こうした問題を、見えない場所に隠しておいても解決しません。

早い段階で分かれば、機能の優先順位を調整する、別の方法を検討する、スケジュールを組み直すなど、選択肢を持てます。納期の直前になって初めて伝えられたら、お客様側も対応のしようがありません。

良い状況だけでなく、問題も含めて共有する。これは、お客様と開発会社が同じチームとして進むために欠かせないことです。

進捗報告は、会議を開くことが目的ではない

週1回の定例会を開くこと。Backlogにタスクを登録すること。途中の画面を見せること。どれも進捗共有の方法ですが、それ自体が目的ではありません。

目的は、お客様が現在の状況を把握し、必要なタイミングで判断できることです。

毎週会議をしていても、曖昧な報告しかなければ意味がありません。反対に、隔週の打ち合わせでも、Backlogで日々の状況が共有され、必要なときにすぐ話せるのであれば、安心して進められます。

案件ごとに、適切な距離感や頻度は違います。だからEFGでは、開発を始める前に進め方を相談し、開発中も必要に応じて調整します。決められた報告の形を守ることより、お客様にとって状況が見えることを優先しています。

最後に「はい、できました」では終わらせない

システム開発は、開発会社が裏側で作業し、最後に完成品を納品するだけの仕事ではありません。途中の状況を共有し、お客様に確認していただき、必要な調整をしながら完成へ近づけていくものです。

もちろん、お客様に毎日細かく確認していただく必要はありません。打ち合わせの頻度や共有方法は、案件の規模やご要望に合わせて決めます。ただし、完成するまで何ができているのか分からない、という状態にはしません。

EFGは、定例会、Backlog、資料、開発途中の画面などを使いながら、お客様と状況を共有して開発を進めます。

納期直前に謎の箱を持ってきて、「できました。さあ、開けてください」とは言いません。システム開発に、完成品ガチャはいらないのです。