プロジェクトキックオフ！ オリエンテーションで話すこと：ユーザーサイド・プロジェクト推進ガイド（11）（1/2 ページ）

システム開発の経験に乏しいメンバーからなるプロジェクトチームを始めるに当たって、まずは“オリエンテーション”が必要だ。強いプロジェクトチームを作るには、最初に何を伝えるべきだろうか？

[山村秀樹，＠IT]

キックオフをオリエンテーションとする

　チームを発足する際には、まずキックオフミーティングを開催して、プロジェクトの概要、すなわち、目的、スケジュール、組織、その役割などの説明と、メンバーの自己紹介とチーム内での役割と作業の分担を決定します。

　ここでは、キックオフミーティングのことを「オリエンテーション」と呼ぶことにします。

　この連載では、コンピュータ・システム開発の経験があまり豊富とはいえない企業で、メンバーを業務部門から出してもらっているプロジェクトチームを想定しています。このような未経験者ばかりで構成されたプロジェクトチームを立ち上げる際のキックオフミーティングは、リーダーがメンバーにプロジェクトの概要を説明する場であるだけではなく、強いチームを作るためにメンバーを指導、啓蒙する機会でもあるのです。

　従って単にキックオフミーティングというよりは、新入生の指導という意味合いのあるオリエンテーションという言葉の方が適当に思われるのです。

キャリアの違うメンバーに方向性を与える

　業務部門からメンバーを出してもらっているチームでは、特にチームの方向を定めるためにも、オリエンテーションは必要となります。「メンバーは優秀で自律的に動ける人間ばかりだから」と安易に構えていると、気が付いてみれば、一貫性がなく無秩序、整合性がなく矛盾だらけ、温度差があってバランスの取れていない、ベンダ殺しの機能要求仕様が出来上がってしまうのです。

　質の良い機能要求仕様書をスピーディに作成することはユーザーサイドの最大目標です。機能要求仕様書はベンダでの設計作業に利用されるだけではなく、ユーザー側がシステムを検収するときにも、システムの運用後は業務プロセスを管理する資料としても利用されるものです。これが悪ければプロジェクトの目的を達成することは困難です。

　同じ企業内とはいえ、各部門には各部門の立場があり、考え方やものの見方が違います。また、同じ部門内であっても、スタッフやラインなど役割の違いによって、考え方やものの見方に違いがあります。いままでに携わってきた仕事を通して、重要と考えること、得意とすることが違うのです。

　当然、システム開発の考え方や見方とは合致しない部分もあります。各メンバーはキャリアや個性による強みを持っており、これは尊重すべきものですが、それ以上にプロジェクトには重視してもらわねばならない方針が存在します。

　以下に、筆者がプロジェクトの概要など基本的な事柄以外に、メンバーに伝えておきたいと考えていることを挙げていきます。

“チーム”であることを説く

　「All for One, One for All」という言葉があります。チームの一員として活動することをうまく表現しています。チームはメンバーに仕事を押し付けるだけではなく、支援や指導を必要としているメンバーをバックアップします。また、メンバーの仕事は、その人だけのものではなく、チームのためのものです。

　1人で考え込んでしまい、悩み続ける人がいます。自力で難題を解決しようと努力することは素晴らしいことです。その過程で、新たな資料／別の考え方／真の問題／ほかの問題の解やヒントなど思わぬ発見があったり、問題解決のコツやその応用力を身に付けることができたりします。人は悩んで大きくなるのです。しかし、考え込んで停滞している間、ほかのメンバーやベンダの作業に大きな支障が出るとすれば、褒めてばかりもいられません。メンバーの時間はチームの時間でもあります。

　技術的な問題であれば自力解決も可能ですが、政治的な問題というか、地位や権限がなければ解決できないような問題もあり、それで身動きができなくなっているメンバーもいます。部門横断的な大規模なシステム開発では部門間での調整事項が数多くあり、それに対して業務部門から出してもらったメンバーは若い人であることが少なくないため、この点で行き詰まってしまうことがよくあります。権限のない人が権限の必要な作業にぶつかると、そこに停滞が生じます。

　別の問題として、優秀なメンバーがそろっているのに集団になると結果を出せないチームがあります。このようなチームはチームとして機能しているとはいえません。個人個人は優れた知識や技量を持っているのに、それを活用できないのは、コミュニケーションが絶対的に不足しているからであり、さらにいえば「自分は自分、チームとは関係がない」という意識があるからです。

　このような人は、指示された作業以外には責任がないと勘違いしているのです。チームとは、メンバーがお互いに助け合ったり刺激し合ったりして高い成果を出す組織であることを、説明する必要があります。そもそもチームうんぬん以前に、社会人であれば、指示がなくても異常や不具合があればそれを報告したり、具申や提案をしたりすることは義務であり責任であることを知らねばなりません。「義務しか行わない者は、義務を果たしているとはいえない」という言葉を知っておくべきです。

---

参考記事

▼連載：ユーザーサイド・プロジェクト推進ガイド（7） − プロジェクトチーム結成──業務部門との関係を考える（＠IT情報マネジメント）

---

　責任について勘違いしているのではなく、責任を放棄している人もいます。実は、生来最低限の責任しか果たしたくないような横着者は少なくて、いろいろな事情があってチームに無関心を装うスネ者になるケースの方が多いのではないでしょうか。本来、社会的な動物である人間には、集団に貢献するような本能があるはずです。その一方で、集団活動にはリスクがあります。All for One, One for Allはこのリスクを避けるためのキーワードともいえます。

　そこで、メンバーには「1人で悩まない」「チームの仕事は1人の仕事ではない」「何か問題があったら話を上に上げろ」「ほかのメンバーに相談しろ」「リーダーを有効活用せよ」といったことを話します。また、困っているメンバーを支援する、他のメンバーの作業に不備があると思ったら声を掛けるようにいいます。一言でいえば、問題はチームの問題として共有することを教えることです。

　チームの中には、自力解決を目指すメンバーとは逆に、マニュアル人間や教えてクンがいるかもしれません。考えようとしない人間に考えさせようとするよりも、教えてあげる方がその場では簡単で時間もかかりませんが、教えてばかりでは教えてクンのためになりませんし、教える方のコストも問題になってきます。

　そもそも、メンバーはチームに貢献できるようにスキルアップすることが求められ、このことを自覚させなければいけません。メンバーがスキルアップを意識するきっかけは、仕事を通じて興味を持つようになることもあるでしょう。興味のあることにはパフォーマンスを発揮できるものであり、チームの実力を押し上げます。チームはメンバーがスキルアップできるように配慮することも重要です。