目次
異文化いたばさみエンジニア日記<を書こうと思った
筆者のエンジニア人生を振り返ってみると,新卒からずっと社内 SE でありながら,社内にとどまることはあまりなかったような気がします。
(広い意味では,グループ企業内なので,社内と言えるかも知れませんが……)海外現地法人へ駐在して,IT 組織を運営したり,生産拠点へのシステム導入出張で第三国へ飛び立ったり(駐在先から,さらに海外出張),日本帰国後も,海外との接点は,なぜか増える一方。
そんな中,海外現地法人の IT 組織(若手エンジニアを多数抱える開発部隊)を活用しながら,大小さまざまな規模のプロジェクトをけん引することもあり,聞こえのいいように言えば「グローバルな仕事」をしていて思うことを,記事のネタにしてみようと思い,キーボードを叩いています。
具体的には,日本側が上流工程(企画,要件定義,設計前半),海外側が下流工程(設計後半,実装,テスト)を分業するという,国際協業プロジェクトの現場ストーリです。
※実際には,かなり泥臭くて,ストレス要因も多いジョブポジションですが,ぜんぶ吐き出すと,ネガティブ形容詞の百科事典になりますので,かなり簡素化(美化しない程度に)したストーリに仕立てています。
柔軟な IT 促進を阻む,特殊な日本文化
日本のシステム開発文化って,かなり特殊。
- 作り込みが重視され,実装工数に見合う効果があるかさえ不透明な「便利機能」を要求するエンドユーザ
- 完成度が重視され,「バグ」が一件でも見つかれば,プロジェクト完了を渋るシステムオーナー
「八十点クオリティじゃ,ダメなんですか?」
なかなかシステム引き渡しが終わらない案件で,そう言いたくなるエンジニアもいるのでは?
実際,システム心臓部でもある,データベース読み書きの整合性さえ,キチンと保障されていれば,システム運用面を工夫することによって,後回しリリースにできるような要求事項って,少なくないものです。
「ソフトオープン」が受容される海外文化
一方,海外だと,「八割」の完成度に達したら運用開始し,あとはちょっとずつ,調整を重ねていくという方式も少なくありません。
システム開発以外でも似たようなことが言えて,たとえばレストラン開業をひきあいに出しても,海外では,内装工事が完璧に終わっていなくとも,営業時間を短くしたり,提供メニュー種類を減らしたりしつつ,「ソフトオープン」と称して,営業開始してしまうことも,一般的です。
日本人の,几帳面で完璧主義な国民性では,「準備万端で開業日を迎える」ことが美徳とされがち。
ましてや,「ソフトオープン」なんて,「お客様に失礼」という批判をする人も出そうですが,この日本特有とも言える価値観は,システム開発現場の生産性低下にも,影を落とす要因になります。
国際協業プロジェクトの現場で起こる,文化の摩擦
日本文化,海外文化,違っていて,当たり前です。
日本側が長所・短所を抱えるのと同様,海外側も,しかり。
両サイドが感じるストレスを最小限化し,あわよくば,シナジー効果を生み出して,お互いに補完関係となるようなビジネスパートナーシップを構築できる協業体制が,理想的ですね。
そしてこれって,日本対海外のみならず,日本対日本という国内協業プロジェクトでも同様。
国際協業プロジェクト現場,劇的 Before & After
冒頭でも触れたように,日本側が上流工程(企画,要件定義,設計前半),海外側が下流工程(設計後半,実装,テスト)を分業するという,十五人月ほどの国際協業プロジェクト現場で起きた話です。
話を,超はしょりまくって(全部書こうとすれば,文庫本数冊になります w),いきなり結論を書くと,順調に思われた進捗とは裏腹に,テスト段階での品質はボロボロ。
原因分析を重ねたところ,失敗要因は大きく二つ:
- 日本側の,具体化スキル不足(指示があいまい,後出し情報が多い)
- 海外側の,解釈スキル不足(書かれてあること以外やらない or 勝手に判断する)
どちらも,両国の文化に深く根付いた課題(国民性?)であるため,一朝一夕の解決は困難。
当時,新米プロマネながら,国際協業アプローチを大幅に見直すという,難しいかじ取りをもとめられることになったおじさん(当時は,おにいさん w)。
協業アプローチ Before 編:「ウォーターフォールもどき」
- 中長期方針をもとにシステム企画
- 利用部門と要件定義を推進
- それをもとに設計書前半(画面デザインなど,基礎的なもの)を起こす
こんなウォーターフォール(もどき)のスタイルで続けていると,設計書は「スタミナ切れ」状態で着手することになり,記載粒度(質と量)は荒くなりがち。
何でもかんでも,最初に「耳を揃えて」仕様として明記しなければ,協業開発先である海外側からのアウトプットは,「期待」から離れたものになっても,文句は言えません。
全部きっちり仕様が出るまで,海外側へ仕事を依頼できないという葛藤,課題にも,つながりました。
国内ビジネスパートナー相手に,協業開発をする場合でも,こんな課題を抱えている現場は,日本のどこかにありそうですが……
立ち止まって,異文化ギャップについて考えてみた
「異文化ギャップについて考えてみよう」と,立ち止まりました。
そもそも,日本って,カイゼン方式で品質を高めて,百パーセントに近づけていく(後付け方式)ことを得意とする国民性があるので,アメリカ(何でもかんでも,最初に明文化)発祥の IT スタイルをそのままマネても,ぎこちなくなるのは,当然のこと。
アメリカで「何でもかんでも,最初に明文化」が可能なのは,シンプルなシステム仕様でも,エンドユーザが受け入れてくれる土壌(トップダウンで推進できるプロジェクト体制)が大きいと思います。
冒頭で「ソフトオープン」のたとえ話をしましたが,いわば,「八十点でも合格を取れる」システム仕様だからこそ,ウォーターフォールが通用したのかも知れません。
かたや,現場(エンドユーザ)の改善意識が強く,声も強い日本は,一般的に,トップダウンで仕事を進めることが困難(特に,企業規模が大きくなるほど,権限の細分化,業務の分業化が進んでいて,顕著にみられる傾向だと思います)。
テストや導入に手間取っていると,いつの間にか,利用者からの要求がエスカレートし,「百五点取らないと,合格できないシステム仕様」にすり替わっていることも。
ひたすら,高機能化,高付加価値化(エンドユーザへの忖度)を重ねるという戦略で,かつて,白物家電で世界市場を制した日本ですが,その後,中韓勢の台頭に敗退を喫した歴史から,教訓を得ようとしない風土が,システム開発の現場にも,暗い影を落としているようでした。
協業アプローチ After 編:「アジャイルもどき」
- 日本側の,具体化スキル不足(指示があいまい,後出し情報が多い)
- 海外側の,解釈スキル不足(書かれてあること以外やらない or 勝手に判断する)
失敗要因を振り返り,「両サイドの弱点を補えるような,国際協業アプローチとは?」を考えた結果,発注を4段階に分けるという戦略を立てました。
はたまた,話を,超はしょって書きますが:
- STEP #1: 画面の作成(モックアップだけど,実運用に耐える HTML コード)
- STEP #2: 読込系(READ)の実装
- STEP #3: 書込系(CREATE / UPDATE / DELETE)の実装
- STEP #4: 検証系(VALIDATE)の実装
最初は,「画面だけ」を作る仕事で,プロジェクトを一周します。
あくまでも,全機能について「画面だけ」を先に終わらせる,というのが,ミソ:
- ややこしい,バックエンド側ロジックについて,議論・実装する必要がないこと
- どこに,どんなパーツ(text / checkbox / radio / select / button など……)を配置するかを会話するだけなので,日本と海外で,認識のズレが生じづらいこと
- 出来上がりを,早期段階からエンドユーザに見てもらえるので,進捗が見えて,安心してもらえることにより,後に,テストやリリースでも協力的関係を構築するのが容易になったこと
当然のことながら,仕事は,すごいスピードで終わりました。
カラッポの画面が表示されるだけですが,プロジェクトメンバーには,まるでプロジェクトが完了したような達成感が芽生え,目に見えるフロントエンドのアセットが出そろうことの強み,精神的メリットを感じました。
次は,STEP #1 で仕上がった画面に,「読込系(READ)だけ」を機能追加していくという,プロジェクト推進。
(これまではデータが空っぽだった)画面に,実データが流れ込んだものが,アウトプットとして仕上がって来るので,最終完成形へグッと近づきます。
あくまでも「読込系(READ)だけ」というのが,ミソ:
- SQL 的には,セレクト文の仕様を詰めるだけなので,議論が発散しないこと
- テスト時,検品時に,セレクト文だけをひたすら確認すればよいので,思考経済的にコスパが良かったこと
同じような方法で,STEP #3,STEP #4 と進めて,プロジェクトは,何事もなかったかのように,無事終わりました。
しかも,反復作業(例:画面作成だけ,読込系だけ,書込系だけ,検証系だけ)のカタマリで推進してきたため,五名のコーダーで仕上げたシステムでも,まるで一人の熟練した開発者が完成させたかのような,標準化され尽したものが得られたのです。
いわば,百点満点しか許されない「学年末テスト」方式が無理ゲー過ぎたので,出題範囲のヤマも張りやすい,二十五点の「小テスト」四つに小分解することで,合格ハードルを下げるアプローチが効果的だったのでした。
結局は,コードもプロジェクトも,一緒だったという気づき
子どもでも思いつきそうな単純発想で,仕事のしやすさを,グーンと変えられるマジックが潜んでいるのは,IT の仕事をしていて,面白い!と感じるポイントです。
おじさんが試みた方法は,いわば,「スコープを小さくする」という,コードを書くときの原理原則を,プロジェクト運用にも応用しただけであり,専門知識を駆使したわけでもなければ,目新しさや斬新さがあるものじゃなかったです。
むしろ,インターンシップ制度の学生さんが,ブレーンストーミングでちょろっと口に出してもおかしくないような,単純アプローチ。
それでも,効果は絶大でした:
- 仕様が完璧に決まっていなくても発注できる(例:画面仕様が決まれば,そこで発注し,バックエンドは後回しにできた)
- ステップごとの実装作業が単純なものとなり,開発標準化しやすく,技術者教育も容易な上,作業所要時間の見積精度が劇的に高まった
- 完成物が「やり直し」になる場面が劇的に減り,日本側と海外側の士気を上げることに寄与した
- 議論(質疑応答)のスコープを絞り込めたので,時差や言語の差があるオンラインミーティングでも,話がズレたり,まったく関係のない方向へ反れることがなくなった
- 設計のスコープを絞り込めたので,日本人が苦手とする「具体的に書く」ことも,弱点ではなくなった。毎回のステップで記述すべき内容が明確となり,書きモレの生じづらい設計書テンプレを生み出せた
- 開発のスコープを絞り込めたことで,海外側が「良かれ」と思って,望まれていないコードを追加することが激減した。書かれていないことは,勝手に判断してすすめる文化に,一定の抑止力を働かされた
- テストのスコープを絞り込めたことで,テストコードを書いて一部を自動化でき,プロジェクトが終わってからも再利用できる,テストモジュールが得られた
一つのメソッドが十五行以内に収められ,スコープが適切に区切られたコードは,開発者の思考経済コスパを,一気に高め,生産性を飛躍的に向上させてくれるものです。
コードからプロジェクトへと,考える対象が大きくなっても,「スコープを小さくする」ことの効果が薄れることはありません。
むしろ,プロジェクトが複雑なものになるほど,「スコープを小さくする」ことのメリットを生かす場面が増えると思います。
可読性・保守性・拡張性を考慮しながらコードを書くエチケットは,下流工程のみならず,むしろ,上流工程の,企画や要件定義といったプロセスでも(だからこそ?),その恩恵はプロジェクト全体に及びますし,プロマネ自身も含め,幸せになれるプロジェクトメンバーも増えるでしょう。
このプロジェクトでは,ステップごとの「成果物の分かりやすさ」を重視し,たまたま CRUD という切り口で,スコープ分割を考えてみましたが,まだまだ他にも,いろんな切り口を使うことができると思います。
「スコープ」の偉大さを学び,かつての自分自身が,プロマネとして一皮むける成長機会につながったプロジェクトでもあったため,こうして記事形式でご紹介しましたが,本記事が参考になったという方がいらっしゃれば,大変うれしく思います。