こんにちはパッケージ開発ご意見番AURAです！
事業会社にて数多のコマースシステムをリプレイスしまくった経験をもとに、システム導入・リプレイス時にいつもエンジニアの皆さんが見ている景色（Ａ面）の裏面のお話をしたいと思います。 ※事業会社の方には耳の痛い話かも、、、ですが、私自身の「反省」も含めていますのでご一読ください。
はじめに
コマースシステムに限らず、新システム導入やリプレイスを行うと概ねリリース前後でもめたりギスギスします。
要件定義が甘いとか、マネジメント不足とか理由は様々ではありますが、事業会社側の「あるある」を認識し、それを意識した進行を行うだけで、顧客満足度は大きくなると思います。
あるある①：ビジョンがない
システム導入やリプレイスは事業会社のビジョンに則ってコンセプチャルに決定していると思ったら大間違いです。
償却期間が終わったとか、なんとなく現場不満が多いとか、「もうそろそろですよね」といったニュアンスで決定しているものです。
なので、その命を受けた現場も漠然と進めるわけにもいかないので、現場レベルの改善に重きをおいてスタートしてしまいます。
プロジェクトで達成すべき幹をきちんと設定しておかないと、要求のブレが生じ、不必要な要件や過剰開発となってしまいます。
後述あるあるにも出てくる「決裁者」とコミュニケーションを取り、受託社の域を超えた苦言も呈しながら、本来の幹を明確化しておくことが大切です。
あるある②：システム部門＝基幹システム部門
よほどの大きな会社でない限り、システム部門というのは基幹システムの担当部門です。
管理系業務には精通していても、WEBやコマース業務に関してはコマース部門に丸投げしています。
そしてコマース部門にシステムに精通したスタッフがいるかといえば、ほとんどいないケースがほとんどです。
ところが、おおがかりなシステム案件となると、この基幹システム担当が前面に立ち、HTML記述もおぼつかないコマース担当がメンバー参画することとなります。
その結果、つくられるしくみは各々の得意分野の主張に偏った、バランスの欠けたものになってしまいます。
・過剰な連携仕様（基幹システム基準にあわせる）
・逆に手抜き連携（基幹システムをさわりたくない）
・運用優先仕様（日頃の不満を解消！）
・過剰なフロントカスタマイズ（なんでも設定できたほうがよい）
事業会社の人選に口出しをすることはできませんが、進行上のキーマン（バランサー）を早期に見極め、そのキーマンにプロジェクトの事業会社窓口として機能してもらうことが肝要です。
あるある③：プロジェクトオーナーが「決裁者」ではない
各プロセスで段階的にプロジェクト承認を受けながらすすめていても、突然要件がひっくり返ることがあります。
例えばデザインについて「かっこわるい」の一言で要件が崩壊した話や、連携をつくりこんだのに「シンプルなバッチ連携にしてほしい」なんて話はよく聞きます。
センシティブな判断をすることは上位層であることが多いので、プロジェクト内合意＝決定ではなく、「ほんとうの決裁者」（時には機能別で別人であることも）を把握しておき適宜適材で承認を得ていくことが、最終的に手戻りのない進行につながります。
あるある④：影響を考えず気軽に変更
要件確認では往々にして「やっぱりこうしておけばよかった」と変更がはいるものです。
人間ですので整理してみたら気づくこともあるのは仕方ないのですが、それがコストと納期に影響を与えるということは一切考えていません。
また、受託社も「要求変更」として真に受けて持ち帰ってしまいます。
そして、毎週の定例会議で小さな「要求変更」が積みあがっていき、ふたを開けたら納期が大幅にずれ大問題になります。
その時に事業会社から必ず出る言葉は「それなら変更しなくていいのに」です。つまり受託社は「要求変更」を検討する時間をロスしてしまった訳ですね。
ですので、「要求変更」が出たときには粗くてもいいので「百万単位のコスト増ですよ」とか「納期に影響がありますね」と伝えることで、安易な変更を回避することも必要です。
持ち帰る前に影響範囲を伝えることで、事業会社の重要度や優先順位を顧みてもらいましょう。
あるある⑤：テストに向いてる人と向いてない人がいる
リリース前テストといえば、最後の砦で入念なパターンチェックが必要ですが、事業会社担当まるなげは非常にリスキーです。
業務を熟知し、リスク管理ができる担当なんてほんのひとにぎりしかいません。
自分で作成したテストパターンを「はしょる」人は多々いますし、そもそもパターンが不十分な場合がほとんどです。
受託社側からの基本テストパターンの提示や、その進捗・結果確認など、「うざい」と言われるほどに関与して「自分事」にしてもらわないといけません。
Ｂ面まとめ
上記の通り、システム導入やリプレイスは大きなお金と人が動く割には、それをかかえきれない事業会社担当者が「必死のパッチで」まわしているのが現実です。
受託社である私たちは、タスク管理表に沿って淡々とすすめていくだけではなく、大きな投資で最大効果がだせるように時には厳しく、時には事業目線で、時にはコンサルテーションも交えてプロジェクトを進めていくことが重要です。
※ちなみに偉そうに言っている、私自身の「成功（もめなかった）率」は３０％です。（汗）
お知らせ
ecbeingでは新進気鋭なエンジニアを募集しております！
careers.ecbeing.tech
