※この記事の内容は、私自身が体験し考えたことですので、一般的ではないかもしれないということをご了承ください。
数年前、外資系（アメリカ）企業の社内システムの一部の設計・構築の案件を担当していた時の話です。
社内システム、といってもその企業はグローバルな企業であったため、アメリカと中国と日本、それぞれ相互で接続するようなシステムです。
なので、それぞれの国にエンジニアがいて、対応するという体制が組まれました。
私の担当の国はもちろん日本です。
一般的なシステム構築のやり方
日本では、一般的にシステム構築は以下のような流れで決まっていきます。
- 要件定義 お客さんが欲しいものをちゃんと決める
- 基本設計 基本的な設計。っつっても人によって全然解釈が違う…
- 詳細設計 実際に設定するパラメータなどを決める
- 構築 やっと作るよー。詳細設計に従ってよね。
- テスト 要件に沿った動きになるか確認するよー
- 引継ぎ 運用する人にシステムを教えるよー
このプロジェクトも始まる前はそういう流れでやってこうかな、なんて思ってました。
プロジェクトが始まった！
そして始まったプロジェクト。
いきなり「すぐ要件定義書を出せ」とアメリカ人のプロジェクトマネージャーからお達しが来ました。
「要件定義書」というと、普通そんな数日数時間で作れるようなものではないんですね。
国内の官公庁の案件だったら、数十、数百ページとかになることもあります。
いきなりのピンチ。
さすが外資系、要求が厳しいぜ、という第一印象。
なので、ダメもとで交渉！
私「時間的に厳しいっす」
アメリカ人のプロジェクトマネージャー（以下、PM）「そんなの作る簡単デショー」
私「○○ページくらいになりますよ」
PM「そんなにいらないよー。そんなの渡されても読みたくないよー。パワポかエクセルの一枚くらいの絵でいいヨー」
私「え？」
ってなわけで早速、文化の違いを感じる出来事が。
本当にそんなんでいいの？とビビりながらペラッと一枚絵を提出。
PM「エクセレント！」
私「え!?」
そんなんでいいの!? 超カジュアルに進むプロジェクト
続いて、基本設計に入ります。
基本設計に入ると、本国のエンジニアやら謎のアドバイザーやら急に人数が増えてきて、中々方針が決まりません。
あまりにも決まりそうにないので、こちらからアイデアを一枚絵にして提出。
PM「エクセレント！ それでOK！」
またそれでいいのかい！
プロジェクト開始からまだ、パワポの絵を2枚くらいしか作ってません。
国内企業だったら、この段階でwordで100ページ以上の資料を作っていたでしょう。
そして詳細設計。
実際に設定する値を事細かにExcelとかに記載していく作業です。
PM「その詳細設計書とかいうの必要？」
私「え？」
PM「設定値なんか実機みればわかるのに、なんでわざわざExcelに書くの？ マジ意味わかないんだけど」
という流れで、なんと詳細設計書が要らないことに！
マジかよ！
でも、オレも何年もずっとそう思ってたんだよね！
実装者が最強
ついに構築です。
普段の案件ではこの時点で設計やパラメータもガッチリ決まっているんですが、今回はご覧のとおり全然何も決まっていません。
やはり実装を進めていくと、いろいろ問題点が出てきます。
その問題点を夜中にアメリカのエンジニアやPMなどと電話会議で打ち合わせするも、それぞれが言いたいことだけ言うだけ。
私「さすがにそろそろ動かさなきゃスケジュール的にまずいので、仮にコレコレこういう設定で今は動かしてますよ」
PM「えー、動いてんの。じゃ、それでいいじゃん」
アメリカのエンジニア「そのやり方だとメリットはこれでデメリットはこれだけど、まあどっちでもいいぜ。だって動いてるんでしょ」
私「でも誰の承認も得てないし…」
PM「承認？ 要らないでしょ。プロのあなたがその内容でOKと判断したんだから」
上記ではかなり省略して書いたのですが、実際の会話の中で感じたのは、やはり実装する人が、それなりの考えをもって実装した場合、それを作り直させるようなことはわざわざしないということ。
乱暴なようで、エンジニアに対するリスペクトを感じましたよ。
国内案件ではまずありえないですね。
だって全くＩＴを知らない人から承認を得なきゃ進まないもんね。プロを雇っておきながらプロに任せないんだよね。
結局、終始こんな感じでプロジェクトは進んでいって、問題なく完了したのでした。
その後、その会社がさらにデカい会社に買収されてそのシステム自体が廃棄になるまで問題なく使い続けられた、とさ。
他にカルチャーショックを受けたエピソード
プロジェクト内である会議がありました。
この話が進まないと他の作業も遅れてしまう、という大事な会議です。
午前中に始まった会議ですが結論がなかなか決まりません。
その時、お昼をお知らせするチャイムが。
日本であればランチ返上で結論が出るまで議論を続けるでしょう。
しかし！
PM「ミーティングおわり〜」
アメリカのエンジニア「ランチいこうぜ〜」
私「え？ これ決まらなくてどうするの？」
PM「スケジュール遅らせればいいじゃん」
結局、その会議では決まらなかったことを再議論する会議すら開かれず、実装者（私）が決めた内容にみんながOKするってことになりました。
そして、結果的にスケジュールは遅れなかったんですよね。
他にもいろいろ衝撃的だったことがあったような気がするので何年も前なので思い出しきれませんでした。
思い出し次第、追記していくつもりです。
はじめまして、タイで生産管理系のPMを３年ほどしている４０歳の男です。
(PG 3年, SE ５年,PM 10年程度の経験です）
記事を読んで驚いたのですが、こういったやり方でGOLIVEした後に、
障害が大量発生した、、なんてことにはならなかったのですか？
ぜひ参考にしたいのでご経験を聞かせていただければ助かります。
コメントありがとうございます！
この記事で書いたシステムのことなんですが、確かに障害はゼロではなかったです。
ただ、それほど大きな障害ではなかったのですぐに対応することが出来たと記憶しています。
コンピュータは設計した通りではなく、実装した通りにしか動かないので、記事には書いてないですがそのあたり私的にもかなり気を使ったのが功を奏したかのかな、と思ってます。