大規模プロジェクトでは「同じ言葉を、同じ意味で」：システム開発プロジェクトの現場から（16）（2/2 ページ）
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
共通の言葉を話すことの大切さ
もう1つ、私が大規模プロジェクトを経験して学んだことがあります。それは「共通の言葉を話す」ことの重要性です。「共通のルールの下、メンバー全員が同じ言葉を同じ意味と認識してコミュニケートする」ということです。
数人で行うプロジェクトでは、進め方などを伝えるのは比較的容易でした。また、どんな課題や問題があるかについても、メンバー間ですぐに共有できました。それに、プロジェクトのメンバーは常に顔見知りだったので、お互いの性格やスキルレベルについてはほぼ熟知していました。私の考える単体テストと私以外のメンバーが考える単体テストは、常に一致していました。ゆえに、明確なルールを必要とするようなシチュエーションは存在しなかったのです。
ですが、プロジェクトメンバーが数十人、数百人となってくると、そう簡単にはいきません。初めて一緒に仕事をする人も多数います。昨今は、オフショア開発などでさまざまな国の人々と働く機会が少なくありません。そういった状況では、私の考える「当たり前」とほかの人が考える「当たり前」が一致することの方が珍しいのではないでしょうか。
私はATSに入社して、全世界のアクセンチュアで利用されている開発方法論を学びました。初めは開発プロセスや成果物が体系的にまとめられたものにすぎないと考えていましたが、実際にプロジェクトで適用してみて、その本当の価値に気付きました（ただし、適用の仕方も重要です。開発方法論自体はフレームワークです。枠組みだけでは機能しません。少し大げさな表現になりますが、プロジェクトごとにきちんと魂を注入する必要があります）。
この開発方法論を適用することで、プロジェクトにかかわるすべての人が、「同じ言葉」を真に「同じ意味」で使えるようになりました。
数百人の間においては、「同じ言葉」を「同じ意味」で使わなければ、正確な意思疎通は図れません。たとえ図れたとしても、膨大な時間がかかってしまうでしょう。「同じ意味」の「同じ言葉」を使用することが、大規模プロジェクトを進めるうえでは必要条件であると感じました。
私がATSに転職した理由の1つに、「大規模なプロジェクトで自分が通用するかを試してみたい」というものがありました（いま考えると小っ恥ずかしいのですが）。
技術的には通用すると思っていましたが、大規模なプロジェクトでは一体何が大変なのかについては、ほとんど理解できていませんでした。大規模プロジェクトでさまざまな経験ができたという意味で、私の転職は成功だったと思っています。
システム開発現場の素晴らしさ
私は、システム開発業界に10年以上従事し、数々のプロジェクトを経験しました。その間、技術はとどまることなく進歩してきましたし、それに伴い、常に学習を余儀なくされてきました。
さまざまな困難も経験しました。大小問わず、さまざまなトラブルにも遭遇しました。もう無理かと思うこともありました……。
いろいろと大変なことは多いですが、苦しいときをともに乗り越え、みんなで1つのモノ（＝システム）を作り上げることの楽しさ、やり遂げたときの達成感はとても素晴らしく、感慨深いものがあります。
何より、自分たちが作ったモノでお客さまに喜んでもらえたときは、最高の気分です。また、多くの魅力的な方々と仕事ができたことは、私にとってかけがえのない財産となっています。
この連載は次回から執筆者が変わり、私の担当は今回が最後となります。こうしたシステム開発現場の楽しさを、多少なりともお伝えすることができていたら、この上ない幸せです。
常に締め切りに追われ（ちなみに最後の最後も徹夜しています）、多くの方にご迷惑をおかけしてきましたので、まさか1年近くも連載を続けられるとは思ってもいませんでした。連載を通じていままでの経験を振り返り、自分の腹の中だけにたまっていた考えや思いを体系化（？）できたことは、非常に有意義でした。このような機会をいただいたことに深く感謝いたします。
多大なるご理解・ご協力をいただいた皆さまに、この場をお借りして心よりお礼申し上げます。
次回からは、入社4年目の若手社員が、新入社員研修、初めての大規模プロジェクト経験などを題材に、システム開発の現場で学んだことをお伝えします。
筆者紹介
新楽清高
1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人（3年目）、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人（3年目）、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの？」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード！ どう乗り切る？
- この案件、ぜひ新しいテクノロジでやりましょう！
- 初めてのトラブル対応。これで直ると思ったのに！
- 「できるか！」な設計書に、どう立ち向かう？
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.