開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
こんにちは。アクセンチュア・テクノロジー・ソリューションズ(ATS)の新楽です。
以前も書きましたが(第6回「専門用語で『カッコよく』話すのは簡単だけど」)、私は以前、社員100人ほどのシステムインテグレータに在籍していました。そこでは数人(時には1人)から十数人の規模でシステム開発を行っていました。世間一般では、おそらくこれを小規模プロジェクトと呼ぶのでしょう。
要件定義(時には提案活動から)、設計、開発、テスト、運用と、すべてのフェイズに携わりました。比較的規模の小さい案件を数多く、プロジェクトの立ち上がりからシステムの稼働開始を経て運用に至るまで経験することができました。ATSへ転職してからは、ピーク時100人を超えるような大規模なプロジェクトを複数経験しました。
プロジェクトは、大きさによって何か違いがあるのでしょうか?
規模の大小を問わず、作るシステムが大切であることに変わりはありません。ですが、何となく「大規模プロジェクト=大変」というイメージがあります。
では大規模プロジェクトは、なぜ大変なのでしょうか? 規模が大きいと要件も多くなり、システム自体の規模が大きくなるからでしょうか?
私は経験から、大規模プロジェクトは以下の3点の理由から大変なのだと感じています。
1.初めて一緒に働くメンバーが多い。どんなことができ、どんなことが得意な人なのかという仕事の部分、どういう性格なのかという人間的な部分が分からない状態から開始しなければならない
ATS入社前は、社員100人ほどの会社だったこともあり、プロジェクトメンバーは常に顔見知りの間柄でした。どんなスキルを持っているか、どういう性格なのかなど、ほぼ分かったうえで仕事を進めることができました。大規模なプロジェクトとなると、なかなかそうはいきませんよね。
2.かかわる人の数が多いため、情報を伝達させること、意識を合わせることが難しい
3.全体の方向性やゴールが見えにくくなる
この大変さを、私はどのように克服したかをお話しします。
1については、ありきたりではありますが、積極的にコミュニケーションを取るようにしていました。
何だかんだいっても、システム開発で大事なのはやはり「人」です。なのでなるべく会話の機会を増やし、メールで伝えれば何とかなることであっても必ず口頭で確認するようにして、信頼関係を築くようにしました。信頼関係がなければ、いいものは作れないと思いますので。
2について。大規模なプロジェクトは、当然のことながら人が多いです。チームも多数あります。そういう中でメンバーへ情報を伝えること、チーム間で情報を共有することは、思いのほか難しいと感じました。
メールは便利ですが、メールで伝えるだけだと、異なる解釈をする人がいたり、異なる解釈からあらぬ誤解が生まれたりします。ですので1と同じことになりますが、少しでも誤解が生まれそうなことについては、必ず最初に口頭で確認するようにしていました。
3について。プロジェクトの規模が大きければ、作成する成果物も大量になります。そんな状況で、目の前の仕事に追われ始めると、それぞれの作業が全体の中でどういう意味を持つのか、いまプロジェクトのどの段階にいるのかという意識がなくなってしまうと感じました。
そういう中では、前回(第15回 「『バッファ込み』の工数がスケジュール遅延の原因」)紹介したプロジェクト憲章やチーム憲章が有効だと思いましたし、日ごろからプロジェクトのマイルストーンや全体の中での作業の意味合いについて意識付けをする必要があると強く感じました。全体を意識できていないと、システムの品質も、メンバーのモチベーションも下がっていくと思いますので。
Copyright © ITmedia, Inc. All Rights Reserved.