ソフト会社って何なん？【第２章】 （第2話）開発場所は？
どこでシステムを作るのか？
前回は、システム開発にはいろいろな進め方があるというお話をしました。
今回は、その中の一つ、
「どこでシステムを作るのか」
について考えてみたいと思います。
大きく分ければ、次の三つがあります。
- お客様の会社に集まって開発する
- ソフト会社に持ち帰って開発する
- それぞれ離れた場所からリモートで開発する
どの方法にもメリットとデメリットがあります。
そして、お客様から見た大きな違いは、
開発場所が離れるほど、実際の仕事が見えにくくなることです。
今回は、この違いについて見ていきたいと思います。
その前に、「1人月」だけ知っておいてください
システム開発では、技術者の仕事量を「人月」という単位で表すことがよくあります。
一人の技術者が、平日に1日8時間、1か月働く仕事量を「1人月」と呼びます。
今回は、この1人月の仕事を、
「どこでやってもらうのか」
という視点から考えてみます。
① お客様の会社に集まって開発する
一つ目は、SEやプログラマがお客様の会社に入り、用意された場所で開発する方法です。
この方法の一番の特徴は、
仕事が目の前にあることです。
どのような人が来ているのか。
今、何をしているのか。
どのくらい進んでいるのか。
そして、契約した時間、自社のシステム開発に従事しているのか。
こうしたことを比較的確認しやすくなります。
もちろん、そこに座っているだけで仕事の質まで保証されるわけではありません。
しかし、契約した時間に自社の仕事をしていることは、三つの方法の中では最も確認しやすいでしょう。
これは、お客様にとって大きなメリットです。
一方で、お客様には負担もあります。
仕事をする場所や机、ネットワークなどを用意しなければなりません。
工場などでは、安全教育や入場ルールも必要になります。
また、外部の人が社内に入る以上、関係のない資料や画面、社内での会話など、機密情報にも気を配る必要が
あります。
つまり、
仕事は見えやすいが、お客様側の受け入れ負担は大きい。
これが、お客様の会社で開発する方法です。
② ソフト会社に持ち帰って開発する
二つ目は、業務や要望を確認した後、ソフト会社に持ち帰って開発する方法です。
お客様は、開発場所を用意する必要がありません。
ソフト会社側も、自社の設備や環境を使って仕事を進めることができます。
その代わり、
お客様から仕事が見えにくくなります。
ここで考えていただきたいのが、
「契約した1人月が、本当に自社のための1人月になっているのか」
ということです。
ソフト会社では、当然ほかのお客様の仕事も行われています。
一人のSEやプログラマが複数の案件に関わることもあります。
それ自体が悪いわけではありません。
しかし、お客様が1人月分の費用を支払っているという認識なのに、実際にはほかの仕事と兼務しているので
あれば、「実際に自社のために使われている工数はどのくらいなのだろう？」という疑問が出てきます。
私自身、38年間の現場経験の中で、契約上の工数と、実際にそのお客様のために使われている工数に
差があるケースに、何度か遭遇したことがあります。
もちろん、すべてのソフト会社がそうだという話ではありません。
しかし、持ち帰り開発では、こうした違いがあったとしても、お客様から直接確認することは難しくなります。
ここは、経営者として知っておいていただきたいところです。
③ それぞれ離れた場所からリモートで開発する
三つ目は、SEやプログラマがそれぞれ離れた場所から参加するリモート開発です。
リモート開発の大きなメリットは、
人を集めやすいことです。
地域に縛られません。
通勤も必要ありません。
社員だけでなく、協力会社やフリーランスなど、広い範囲から技術者を集めることもできます。
働く側にとっても自由度が高く、通勤時間がなくなり、一人で集中することで高い成果を出す人もいます。
一方、現在では、毎日決められた場所への出社を条件にすると、技術者を集めにくくなる場合もあります。
条件によっては、人材を確保するために単価を上げなければならないこともあるでしょう。
その意味では、リモートは人材を確保するための有効な方法でもあります。
しかし、お客様から見ると、
仕事の実態はさらに見えにくくなります。
誰が仕事をしているのか。
契約どおりの工数で、自社の仕事をしているのか。
そして、
報告されている進捗と、実際の進捗が一致しているのか。
という問題も出てきます。
「二つの進捗」が生まれることがある
これは私自身が、実際の開発現場で経験したことです。
「順調に進んでいます」
「ほぼ出来ています」
「現在テスト中です」
そう報告を受けていたにもかかわらず、
「では、今出来ているところまで見せてください」
と確認すると、見せることに抵抗されることがありました。
完成していなくても構いません。
途中の画面でも、プログラムでも、設計書でも、テストした記録でもいい。
さらには、「作業中に書いた殴り書きのメモでも構いません」と伝えました。
しかし、それでも見せてもらうことはできませんでした。
そして、実際には、報告されていたほど仕事が進んでいなかったというケースもありました。
さらに、そのような状況になった原因について、
「お客様から適切な指示がなかったから進められなかった」
という説明を受けたこともあります。
もちろん、お客様から必要な情報や判断が出なければ、開発が止まることはあります。
それならば、本来はその時点で、
「この情報がないので、ここから先へ進めません」
と伝える必要があるはずです。
進捗上は「順調です」と報告しながら、後になって「指示がなかったから進んでいません」という
ことになれば、お客様には実際の状況が分かりません。
つまり、開発現場では、
「報告されている進捗」
と、
「実際の進捗」
という、二つの進捗が生まれてしまうことがあります。
もちろん、すべてのリモート開発で起きる話ではありません。
リモートの方が集中でき、高い成果を出す技術者もいます。
仕事の自由度が高く、お客様から直接見えない以上、実際の工数や進捗との違いがあっても発見しにくい
ということは知っておく必要があります。
最後の納期だけ合えばよいのでしょうか？
「それでも、最後に納期に間に合えばいいのでは？」
という考え方もあるでしょう。
しかし、システム開発はいろいろな仕事が絡み合って進みます。
設計。
プログラム。
データベース。
ほかの機能との連携。
テスト。
一つの仕事が実際には遅れているのに、報告上だけ予定どおりになっていれば、ほかの作業にも
影響します。
そして最後になって、
「実は、ここまでしか出来ていませんでした」
となれば、一気に問題が表面化します。
だからシステム開発では、最後の納期だけではなく、途中の進捗が実際の成果と合っていることも
大切なのです。
では、お客様の会社で開発するのが一番良いのでしょうか？
お客様側だけを考えれば、目の前で仕事をしてもらう方が分かりやすいでしょう。
しかし現実には、それだけでは決められません。
お客様の会社での開発は、場所や設備、安全管理などの負担があります。
さらに現在の人材事情では、
「毎日ここに来て、決められた時間仕事をしてください」
という条件にすると、技術者を集めにくくなる場合もあります。
反対にリモートを認めれば、人材は集めやすくなる。
しかし、仕事の実態は見えにくくなる。
つまり、
「管理のしやすさ」と「人材の集めやすさ」
の両方を考えなければなりません。
大切なのは、場所と確認方法を一緒に決めること
だから、
「お客様の会社で開発するのが正しい」
「リモートは駄目だ」
という話ではありません。
経営者に知っておいていただきたいのは、
同じ1人月でも、どこで仕事をするかによって、その仕事の実態の見え方が違う。
ということです。
その違いを知ったうえで、ソフト会社と話し合い、
「自社のシステムを、どのような場所で開発するのか」
を決めていくことが大切です。
そして、もう一つ一緒に決めていただきたいことがあります。
「開発状況を、どのように確認するのか」
ということです。
毎日細かな報告書を書かせたり、技術者を一日中監視したりする必要はありません。
報告すること自体が仕事になってしまえば、本来の開発が進まなくなります。
お客様にとって分かりやすい。
ソフト会社にとっても管理しやすい。
実際に開発する技術者にとっても無理がない。
そのうえで、
できるだけ実際の進捗や問題が、そのまま伝わる方法を考える。
どのくらいの間隔で確認するのか。
何を報告するのか。
途中の成果物をいつ見るのか。
問題が起きたときは、どのように連絡するのか。
こうしたことを、ソフト会社や実際に開発する人たちと話し合っておくことです。
見えないものを無理に監視するのではなく、無理なく実際の姿が見えるコミュニケーションの方法を作る。
私は38年間の現場経験から、
開発する場所を決めることと、その場所に合ったコミュニケーションの取り方を決めることは、
セットで考えた方がよい
と思っています。
次回 第3話 誰がシステムを作るのか？
今回お話ししたのは、
「どこで作るのか」
という開発場所の話でした。
では、その場所で実際にシステムを作っているのは誰なのでしょうか。
ソフト会社の社員なのか。
協力会社の技術者なのか。
SESなどで参加している技術者なのか。
フリーランスなのか。
あるいは、それらが混ざった開発チームなのか。
ソフト会社に依頼したからといって、その会社の社員だけでシステムを作っているとは
限りません。
では、誰が作るかによって何が変わるのでしょうか。
そして、お客様は何を確認しておけばよいのでしょうか。
次回は、
「誰がシステムを作るのか？」
開発体制について、お客様の立場から考えてみたいと思います。
※本記事は、筆者が38年間システム開発の現場で経験した内容や考え方をもとに執筆しています。
システム開発にはさまざまな契約形態や開発方法があり、すべての企業や開発案件に当てはまるものでは
ありません。一つの考え方として参考にしていただければ幸いです。