メンバーとの仕様打ち合わせは海を越えて:システム開発プロジェクトの現場から(5)(2/2 ページ)
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
設計書は、詳細に作成するべきか?
オフショアに引き継ぐ設計書を作成することになったとき、最初「よし、誤解の余地がないくらい事細かな設計書にしよう」と思いました。しかしよく考えてみると、記述レベルが細かければその分設計書のボリュームは増大し、作成とメンテナンスの負荷が高まります。そればかりか、設計上のポイントとなる幹の部分が、枝葉に隠れて見えにくくなってしまいます。
やはりそれは得策ではないと考え、アプローチを変えることにしました。設計書の詳細度はプラスアルファ程度にとどめ、むしろ業務的な背景や目的など、日本側のチームでは暗黙知となっているような事柄を極力文書化し、オフショア側と共有することに力を入れたのです。
オフショアの開発者が、その機能が現実の業務あるいはシステム全体の中でどのような役割を持つかを理解し、設計書の行間を読み取れるようにすることに注力しました。
そういうアプローチを取ることで、オフショアの開発者側も作業の意義を理解できるためモチベーションが向上し、「そういう目的だったら、こういうソリューションの方が効果が大きいのでは?」という逆提案も生まれてきました。
こうしたやりとりを重ねていくことで、「オフショアに仕事を出している」という関係ではなく「お互いに仕事を分担して協業している」という関係に近づけたという手応えを感じることができました。
メールでプログラミングの仕様を伝えるのは難しい
日本と大連の間のコミュニケーションは、基本的に大連側の翻訳者を介してメールベースで行うこととしていました。しかし、「こういうケースでのABAP(SAPのプログラム言語)の仕様はどうこう」といった込み入った話になってくると、伝言ゲームのようになってしまってはかどらないケースが出てきました。
やはり、可能な限り共通の言語で直接相手とコミュニケーションする努力は必要だと、私は思いました。
幸いこのプロジェクトでは、オフショア側のメンバーのほとんどが英語に通じていました。必要に応じて電話やインスタントメッセンジャーで会話することで、認識の食い違いを埋めることができました。恥ずかしながら私はあまり英語が得意ではないため、辞書を引きながら会話を進めるなど、冷や汗モノでしたが……。
余談になりますが、メッセンジャーは便利な道具ですね。仕事の合間に、「調子はどう?」とか、「そちらの天気は?」といったちょっとしたやりとりを行えるのが楽しく……。相手との心理的な距離を縮めることにもつながったものです(ちなみにアクセンチュアでは、すべてのPCにメッセンジャーの暗号化ツールが導入され、使用についてはアクセンチュアのセキュリティポリシーに従うことになっています)。
一方通行のコミュニケーションは危険
こちらも多忙を極めているとつい、設計書を渡したら「後はよろしく」といいたくなります。「そちらに任せたのだから、そちらの判断で進めてください」と。
的外れに思える意見や質問を受けると、「はあ」とため息が出て、ついついつれない対応を取ってしまいそうになります。
しかし、そのような姿勢でコミュニケーションをシャットアウトしてしまうと、背後に潜んでいる認識のずれなどが解決されず、問題が発覚するのが遅れます。お互いにとって利益になりませんし、何より相手を尊重する姿勢を欠いた行動です。
どんなやりとりにも真摯(しんし)に対応し、小さなことでも意見や質問を出せるような雰囲気づくりが重要だとあらためて感じました。
どんなプロジェクトにも重要なこと
上記のポイントを見直してみると、オフショア特有というより、プロジェクトを運営していくうえで普遍的な要素が多いことが分かります。国内で仕事が完結している場合、これらの要素に欠落があっても無意識のうちに補完され、問題として顕在化しないだけのことなのです。
オフショアは予期せぬ負荷やリスクが高く、敬遠する向きもあるようです。しかし経済のグローバル化や国際的な協業が今後も進展していくことは、おそらく避けられないでしょう。
それならば互いに理解を深め、より良い仕事をするように努力する方が前向きであり、建設的ではないでしょうか。モノは考えようで、オフショア拠点とうまく協業できるノウハウが身に付けば、国内他社との協業、社内でプロジェクトを運営する際のスキルも向上するはずです。
「Win-Winの関係」という言葉はビジネスの基本ですが、この言葉は、自分の成功のためには相手の成功も必要であることを本質的に語っています。電話の向こう、メールの向こうにいるのは、血の通った、感情のある人間です。相手の立場になって考えるという想像力はビジネスパーソンとして不可欠であり、オフショアと協業する場合は特に重要といえるでしょう。
ITエンジニアは魅力的な職種
これまで5回にわたって連載してきましたが、今回で私による記事はひとまず終了となります。お付き合いいただいた皆さん、ありがとうございました。ぜひご意見・ご感想をお寄せください。
近年、ITを取り巻く環境は厳しさを増し、この業界の魅力が薄れてきたといわれることもあります。ずっとこの業界で仕事をしてきた私にとってはさびしい限りです。
私はいまでも、ITエンジニアとは技術力とともに人間力を磨くことのできる、数少ない魅力的な職種だと考えています。皆さんはどう思われますか? これまでの連載を通じてそうしたメッセージが伝われば、筆者としては幸甚です。
なお、この連載は、今後もほかの筆者によって継続されます。引き続きよろしくお願いします。
最後になりましたが、このような機会をいただき、また連載中も数々のサポートをいただいた関係者の皆さんに深く感謝いたします。ありがとうございました。
筆者紹介
アクセンチュア・テクノロジー・ソリューションズ
稲井紀茂
1972年生まれ。神戸生まれの大阪育ち。大阪でプログラマ、システムエンジニアとして約7年を過ごした後、2003年にアクセンチュア・テクノロジー・ソリューションズに入社し上京。主に流通業・製造業の販売管理・SCM系システムの構築に携わり、現在に至る。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人(3年目)、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人(3年目)、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの?」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード! どう乗り切る?
- この案件、ぜひ新しいテクノロジでやりましょう!
- 初めてのトラブル対応。これで直ると思ったのに!
- 「できるか!」な設計書に、どう立ち向かう?
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.