中国の開発チームと共同で進めたプロジェクトで、「仕様をいつまで変更できるのか」という前提が、双方で合っていなかったことがあります。
一方では早めに仕様を固めたいと思いつつ、でも他方からは、開発途中でも改善案が次々に出てきました。当初「なぜ今になって変更案が出るんだろう」と戸惑いましたが、話を重ねるうち、問題は仕様書そのものではなく、変更できる時期を共有していなかったことだと気づきました。
オフショア開発で仕様調整が噛み合わないとき、何が起きるのか、また、仕様書の中身以外に何を確認しておけばよいのかを見直すときに、読んでもらえればと思います。
中国側チームから仕様変更の提案が次々に出てきた
当時の開発体制は、仕様面で言えば日本側が20名ほど、中国側も同じくらいの人数でした。
私は日本側の統括リーダーで、その下に機能ごとのリーダーが5名ほどいました。中国側も似たような体制です。
やり取りは中国側が通訳を用意してくれていて基本日本語でした。普段はオンライン会議と仕様書を使って意識合わせをし、必要に応じてこちらから中国へ出張したり、中国側の主要メンバーが日本へ来たりしていました。
機能ごとに担当が分かれ、それぞれのチームで設計や開発が進んでいくので、一つの仕様変更でも内容によっては複数の担当へ影響します。
そんな中で、今回一緒に開発した中国側チームから、UIや機能に関する改善提案がかなり多く出てきました。
ユーザー操作に関わる画面遷移や、ちょっとした使い勝手の改善、機能追加などです。
相手側からすると、
「その方が使いやすい」
「機種として良くなる」
という考えだったのだと思います。
提案自体は悪いものではありませんでしたし、それ以上に、少しでも良いものにしようという熱量は強かったと思います。
ただ、統括リーダーとして全体の工程を見ていた私には、
「いや、もうこの内容を検討する時期はとっくに過ぎているよ」
と思う提案もかなりありました。
ただし、共同で開発をし、お互いが良いパートナーとなろうと努力している中、提案に対して最初から「無理です」とは返せません。まず内容を受けて、何を変えたいのか、どこへ影響するのかを確認する必要があります。
中には、「それなら確かに使いやすくなるな」と思うものもあります。
でも、その時点ですでに日本側では設計も終わり、実装が進んでいる場合も多いです。
変更すれば、設計の見直しや他機能への影響、コード変更、テスト項目の見直しが発生します。もちろん仕様書の更新も必要ですし、顧客への説明が必要になる場合もあります。
関連記事：顧客の追加要求をそのまま流さない｜開発への影響を確認して返す対応法
内容によっては費用や納期に大きく影響するものも出てきます。
だから、「案としては分かる。でも今から入れるのは厳しい」という判断が多くなっていきました。しかも、提案された変更の多くは、実際の対応が日本側の担当範囲でした。
中国側の担当者から、実際に、
「良くするために提案しているのに、日本側はなかなか動いてくれない」
という趣旨のことを直接言われたこともあります。一方、当時の日本側チームには、「仕様はもう決めているよね」という意識がありました。
同じ仕様を見ながら、そもそも「今も変更できるものなのか」という前提が違っていたんですね。
同じ「品質」でも重視していたところが違っていた
当時の日本側チームは、品質をかなり重視していました。
特に、
「バグを出さないこと」
「開発後半で仕様を揺らさないこと」
「安定して完成させること」
への意識が強かったと思います。
もちろん、使いやすさを軽視していたわけではありません。ただ、開発の後半になるほど、一つの仕様変更が与える影響は大きくなります。
だから、ある時点までに仕様を固め、その後は変更を減らして設計・実装・テストへ進む。それが品質を守るための進め方として定着していました。
一方、今回一緒に開発した中国側チームでは、開発途中でも、「もっと使いやすくできる」「こう変えた方が良い」という案があれば、積極的に提案する傾向がありました。
最初のうちは、「もう決めた仕様なのに、どうしてまだ変えようとするんだろう」と、私も戸惑いました。でも、やり取りを続けて分かってきましたが、向こうも良い製品にしたいからこそ提案しているんですよね。
当時の日本側チームは、仕様を安定させてバグを抑えることを強く見て、今回の中国側チームは、開発途中でも使いやすさや機能を改善することを強く見ていました。
同じ「良いものを作りたい」でも、どこを品質として重く見るのかが少し違っていました。
これは「日本だから」「中国だから」という話ではなく、会社によっても違いますし、チームや製品、契約条件によっても変わるでしょう。
少なくとも、当時一緒に開発していた二つのチームでは、その違いがかなり大きかったということです。
さらに難しかったのは、費用や納期に関する事情が、中国側の担当者レベルまでどの程度共有されていたのか分からなかったことでした。
もっと上のレベルでは、そうした話もしていたはずです。でも、現場からは、「良くなる案があるから提案する」という形で話が次々に上がってきます。
こちらからすると、「良いか悪いかだけでは決められないんだよ」となりますし、相手からすると、「良くなるのに、なぜやらないんだ」ともなります。
統括リーダーとして、その間に立つ難しさを感じていました。
通常の打ち合わせだけでは仕様が収束しなかった
普段のオンライン会議でも、当然こうした仕様について話していました。
ただ、短い会議を開いて、
「この仕様はこうです」
「分かりました」
で終わるほど単純ではありませんでした。
機能ごとに担当者が違いますし、ある変更が一つの機能だけで済むのか、別の機能まで影響するのかは、仕様担当だけでは判断できないこともあります。
さらに通訳を挟むため、会話を1往復するだけでも時間がかかり、さらに言葉だけでなく背景まで合わせようとするともっと時間もかかります。
一つの提案について話しても、また別の担当から提案が出てくる。こちらで影響を確認して返答するころには、さらに別の話が出ている。
そんな状態では、なかなか「これで仕様は確定」と言えません。
「提案しているのに、なかなか答えが返ってこない」という不満、「もうそろそろ仕様を固めないと、後工程へ進めない」という事情のぶつかり合い。
こうなると、個々の提案をその都度処理するだけではなく、一度まとまった時間を取って、双方で全部確認した方がいいと考え、日本で仕様FIX会議を行うことになりました。
1週間の仕様FIX会議で一つずつ突き合わせた
仕様FIX会議は、だいたい1週間。
ほぼその期間を使って、機能ごとに詳細仕様を確認していきました。進め方は、仕様書を元にした読み合わせです。
中国側から質問や提案を出してもらい、日本側の仕様担当が受け答えする。さらに、その機能を担当する開発リーダーも同席します。
私は責任者として、すべての会議に出席するわけですが、仕様担当だけでは「仕様上はこうです」までは答えられても、「今から変更して開発上問題ないか」までは判断できないことがあります。
そこを開発リーダーが技術面から補います。
「これは問題なくできる」
「ここを変えると別の機能にも影響する」
「この段階から直すのはかなり厳しい」
と、その場で一つずつ確認していきました。
私自身も統括リーダーとして、全体の費用や納期を見ながら、どこかに問題がないかを気にしつつ話を聞きます。
中国側から提案が出る。
仕様担当が内容を確認する。
開発リーダーが技術的な影響を見る。
必要なら、その場でさらに議論する。
これを機能ごとに繰り返しました。
ここで意識したのは、すべての提案を断る会議にしないことでした。
開発側から「その程度なら問題なく対応できます」という判断が出たものは、実際に取り入れましたし、逆に、ぱっと見では簡単そうでも、「そこを変えると別の部分にも影響する」と分かれば、その場で理由まで確認して見送りました。
通常の打ち合わせでは、仕様担当だけでは技術的な影響まで判断できず、いったん持ち帰ることがありましたが、この仕様FIX会議では、仕様担当、開発リーダー、全体を見ている私が同じ場にいたため、提案の内容だけでなく、技術面や工程への影響まで含めて「今この時点で変更できるのか」を判断できました。
私にとっては、仕様を確定させるには、内容を確認するだけでなく、変更可否を判断できる人まで同じ場にそろえる必要があると分かった経験でした。
難しいものは、変更できない理由までその場で説明する。対応できるものは、実際に取り入れる。
一つずつそれを続けることで、少なくとも私自身は、中国側の提案を「決めた仕様をまた変えようとしている」と捉えなくなりました。
完全に考え方が同じになったわけではありません。それでも、それぞれの提案について、なぜ変更したいのか、なぜ今からでは難しいのかまで話せるようになったことで、それまで見えていなかった双方の事情を確認しやすくなりました。
かなり負荷の高い会議で、通訳の方が途中で体調を崩すほどでした。それでも、その1週間が終わるころには、仕様もかなり収束し、その後、中国側からの変更提案も落ち着いていきました。
すべての突き合わせが終わったあとは、両チームで大宴会も開きました。
完全に考え方が同じになったわけではありませんが、「相手はなぜそう言っていたのか」というところまでは、お互いにかなり理解できるようになったと思います。
その後はマイルストーンごとに変更時期も確認
この経験は、その後の進め方にも影響しました。
それまでは、仕様を確認するとき、「何を作るのか」に意識が向きがちでした。
仕様書に何を書くのか。
この機能はどう動くのか。
画面はどうするのか。
もちろん、それも重要です。でも、それだけ合わせても足りませんでした。
同じ仕様を見ていても、「まだ変更してよい仕様」だと思っている人と、「もう確定した仕様」だと思っている人がいれば、また同じことが起きます。
そこで、その後はマイルストーンごとに、仕様の内容だけでなく、その仕様が今どの状態なのかも確認するようになりました。
「ここまでは変更可能」
「この時点で仕様をFIXする」
「FIX後に変更する場合は、影響を確認してから判断する」
こうしたところまで、相手と認識を合わせます。
複数の会社やチームで開発すると、自分たちの「普通」が相手にも同じとは限りません。国が同じでも、会社が違えば開発の進め方は違います。同じ会社でも、チームや製品が変われば考え方が違うこともあります。
この経験以降、私は仕様を確認するとき、「何を作るか」だけでなく「今は変更できる段階なのか」「いつ仕様をFIXするのか」までセットで確認するようになりました。
仕様書に同じことが書いてあるから、認識も同じ、とは限らないんですね。
まとめ
このプロジェクトで一番印象に残ったのは、同じ仕様書を見ていても、認識まで同じとは限らないということです。
仕様そのものだけでなく、「いつまで変えられるのか」「変えると何に影響するのか」まで共有して、初めて同じ前提で話せるのだと思いました。
今では、複数の会社やチームと進めるときほど、自分たちにとっての「当たり前」をそのまま前提にしないようにしています。
コメント