個人主義にならない／チーム活動のコツ

あたりまえですが、現在『企業』の中で行われてるミッションやプロジェクト活動というのは、たった１人だけでは抱えきれず、チームでなければ遂行することができないものが殆どです。

1980年代～2000年代くらいまでは個人で２～３プロジェクトを抱えるくらい小規模なものも多い時期もありました。今でもごく少数ですが存在はしているとおもいます。

そのため人材の育成などが疎かになり、「個人」に丸投げして任せっぱなしにすればいい…と思っている世代が今まさに経営層にいるため、依存しきっていた「個人」がいなくなった瞬間、立ち行かなくなる中小企業…というのも珍しくありません。

そういう意味では、今まさに"組織的活動"のできる企業に成長できるか否かの分水嶺にあり、これから社会人となって企業にはいってくる新人から見ると、意外にも先輩や上司と呼ばれる方の中にはチーム活動に苦手意識を持っている方もいらっしゃるかもしれません。

さて、そんな事情はさておき。

今後ゼロにはなることはないでしょうが、個人単位で活動できるプロジェクト活動と言うのはさらに激減していくことでしょう。少なくともＩＴ業界ではそうなります。

なぜなら、旧態依然としたハードやシステムを使いまわしている分にはともかく、世の中のニーズが、AI、第４次産業革命だのと賑わっている中、そういった技術を取り込もうと思ったら到底１人でなんとかなるような規模でおさまらなくなるからです。

では、そういう時代の流れに合わせてチーム活動するとなった場合、何が必要なのでしょうか。

答えを言う前に、皆さんがイメージするチーム活動というものを連想してみてください。サークルやクラブ活動でも、飲み会の司会進行などでもかまいません。オンラインゲームで他人と遊ぶ、でもいいでしょう。

考えるべきは

　・アイコンタクトや阿吽の呼吸で通じ合うとかそんな夢物語は存在したか
　・それらの連想した過去の活動に絶対的に必要だったものはなにか
　・その必要なことをしない人たちはどういう扱いを受けたか

です。
意外と社会人になると皆が忘れてしまって、自分の仕事だけに集中したいと言う人が増えてしまいますが、こうした課題はクラブ活動であろうと、プライベートの付き合いであろうと、ゲームであろうと、何も変わりません。

1. 役割を定義する

まずはこれから始めましょう。
私たちは、組織図または体制図と呼ばれるものを作り、

　「リーダーは誰がやるの？」
　「その作業は誰が担当するの？」

など、役割の明確な分担を決めます。

もちろん、形骸化した名ばかりの決定など、何の意味もありません。「役割」には、それに見合った「責任」がつきまといますし、その責任を果たすための「権限」も付与されます。

この３つの要素がそろって初めて仕事が遂行できます。
どれかが１つでも欠けると、人は仕事ができません。

たとえばリーダーとなる場合、リーダーという役割である以上、

・メンバーを牽引しなければならない
・従わないのはリーダーシップが弱い責任意識を持たなければならない
・問題があれば、率先してその解決に当たらねばならない

など、責任に見合った面倒くさい作業がついて回りますが、
替わりに

・活動が成功するよう、メンバーに指示、命令
　および役割の変更や調整を決定できる権限がある
・メンバーは、リーダーを補佐し、その指示に従い
　目的達成のために尽力しなければならない

と言った権限や制約が付与されます。

そもそも、『役割』を決めたら、その役割にはどんな「作業」・「責任」・「権限」があるのかを明確にし、そのルールには全員一致で従わなければならないという統一感を持たなければなりません。

決定や承認をするのはあくまで責任者...ここではリーダーが望ましいでしょう。このように役割分担をおこなうことで、

　・目的達成のために不足している作業（タスク）を作らない
　・重複した作業を作らない

等を避け、さらに勝手な判断をしたり、誰に確認すればいいのかわからないという状況を作らないようにしたり、と言った効果を生み出します。クラブではキャプテン（主将）がいたり、スポーツならそれぞれにポジションが決まっていたり、と言うのはそのためです。役割が定まっていないと、ただの烏合の衆にしかなりえないのです。

チーム活動では、必要な活動に対して過不足なくメンバを割り当て、互いが互いの権利や役割を冒さず、自身の責務を果たすことで成立します。

これを決めずに、ただの仲良しごっこでビジネスを進めると、十中九～十は破綻することでしょう。逆に、そういった重責を全うするからこそ最も評価される対象となるわけです。

2. メンバーのベクトルを一致させる

ただのチーム活動を"プロジェクト"と呼ぶために、チームメンバ全員で以下のことを決めましょう。厳密には

　・決定するのはリーダー
　・意見を出し合うのはメンバー（リーダーもメンバーの１人と言う扱い）

ですね。
決めることは

・プロジェクト名
・期間または期限
・ゴール（どうなっていることがゴールか？何を作るのか？等）
・活動目標

プロジェクトチーム内で自分たちのプロジェクトの名前を決めます。

たかが名前…と思うかもしれませんが、自覚意識を芽生えさせるためには有効です。たとえば、ペット…犬を飼う時に、名前を付けるかつけないかで、多くの人は愛着や責任感というものが変わってくるのではないでしょうか。それと同じことです。

名前の決め方は開発するシステムの名前から取ったり、自分たちの目標や夢を表す名前をつけたり、場合によってはメンバの名前から取ったりと、自由に考えて構いません（意匠権や商標権などに抵触しない範囲で）。

プロジェクト名とシステム名（製品名）は異なります。システム名は顧客に納品された際、顧客内で用いる通称となるため、システムそのものが持つ目的を表した名称とすることが多いのですが、プロジェクト名はあくまでプロジェクトチームあるいは所属する会社内で用いる通称であるため、わかりやすい名称が求められます。

ただし、名前の重複を避けるためだけの理由で意味のない通番などを用いることは避けた方がよいでしょう。通番の違いが具体的に何が異なるためにあるのか、同じ社内でも理解できる人間は皆無に近くなり、管理面においても支障をきたす状況に陥りかねません。

メンバー間の役割が決定し、必要なプロジェクトとしての定義が終わったら、次はメンバー全員が開発途上で迷うことのないよう、同じベクトルを指し示す『目標』を作ります。

ここでは例としてチーム内で自分たちのプロジェクト、システム開発の過程において最も重要視すべき”現実的な”活動目標を３つほど決めましょう。活動目標の決め方は例を参考にしてチーム全員で決定してください。

リーダーが勝手に決めてはいけません。それは命令と変わらなくなってしまいます。全員の合意で決めることが全員で守ることにつながります。

また、ここではあまり定量的に評価できるようなものにせず、誰もが意識できて、苦も無く日頃からできるようなものにしておくといいでしょう。目的は「評価するため」ではありません。評価はレビューやテストだけで十分です。ここではあくまで

　「仕事の質を上げるため」

のものでなくてはなりません。

また、決めた活動目標はプロジェクト名と併せて大きく紙に書き、いつも確認ができるよう張り出しておくなど、オープン化／可視化するとさらに効果があります。プロジェクト活動期間中は毎日確認し、常に意識して作業を実施します。

そして最後に、システム開発終了後に決めた活動目標に対して、順守できたかどうかの見直しを全員で行います。こうすることで『意識』の定着と向上を図り、プロジェクトチーム全体が１つの集合体として活動できるようサポートしていきます。

3. 運営ルールを決める

今後、プロジェクトチームを組んで開発を実施していくにあたり、以下の項目についてその運営ルールを決めます。「開発」そのものではないこうした活動を『支援プロセス』といいますが、これらを疎かにすれば開発そのものも進まなくなります。たかが支援…と思って杜撰にする人やチームはたくさんありますが、

　・成果物管理（構成管理、変更管理）
　・スケジュール管理（プロジェクト管理）
　・レビュー実施方法（共同レビュー管理）
　・質問・トラブルの解決の仕方（問題解決管理）
　・プロジェクト内での問題解決の仕方（問題解決管理）

決めたルールはチーム全員が守ることが大切です。つまり守れそうもないルールを決めても仕方がありません。チーム内で十分検討しあって決定してください。たとえば、次のようなテーマについてです。

■成果物管理の仕方

システム開発のプロジェクトでは多量のドキュメントやプログラムを作成することになります。その殆どが顧客への納品物であり、納品後は顧客の所有物となります。システムのみならずドキュメントにおいても１つの『製品』としての自覚を持ち、しっかりとした商品として形作られなければなりません。

もしも紛失、破損、デグレ等が発生した時、その責任は発生させた者にあるのではなく、発生させるような運用プロセスを用意した者にあることを忘れてはなりません。

そのため、必ず作成されたドキュメントやソースコードの運用・管理方法についてルールを決めましょう。

a）誰が管理するか
b）どこに管理するか
c）どのように管理するか

■スケジュール管理の仕方

プロジェクトが計画したスケジュール通りに進んでいるかについての確認方法およびルールを決めましょう。スケジュールは、リーダーやマネージャー等、責任を持つ者だけが知っていればいいというわけではありません。

全員がいつでも認識・把握できる管理方法を決める必要があります。

a）誰が管理するか
b）いつ管理するか
c）どのように記録するか

■レビューの仕方

成果物や作業の品質をプロジェクトチーム内で保証するために、各工程でそれぞれの成果物に応じたレビューを実施します。
レビューはそのシステムの品質を決める最も重要な作業の１つです。
この内容如何によってシステムの成功と失敗が決まると言っても過言ではないので、その運用方法についてルールを決めましょう。

a）いつ実施するか
b）どのように実施するか
c）誰が参加するか

■質問・課題の解決の仕方

システム開発中に発生した質問や課題はその原因を究明し、今後同様の事象発生を防ぐ必要があります。そのためにこうした結果についても管理・運用についてルールを決めましょう。

レビューの運用が完全に回っていれば大きな質問や課題が増加することもありませんが、もしも増加してしまった場合にこの運用が役に立つことになります。

a）どのように管理・蓄積するか
b）どのように周知徹底するか
c）どのように再利用するか

■プロジェクト内での問題解決の仕方

上記以外でプロジェクト進行中に発生した問題点について、その管理と解決の仕方についてルールを決めましょう。

どのような問題が発生するかはこの時点では未知数なので、決めることはシンプルです。しかし、影響範囲の特定や類似問題の調査などは決して疎かにしてはなりません。

a）どのように管理するか
b）問題の討議はいつするか
c）他への影響や類似問題は無いのか

以上、ざっと例をあげてプロジェクト運用のルールについて重要な部分のみ抜粋しましたが、もちろんルールを決めただけではプロジェクトが成功するわけはありません。

決めたルールを守るのは当然のことですが、それ以上に必要なのは

　プロジェクト関係者が、そのプロジェクトの目標を意識し、
　自分自身の作業を確実に行い、お互いに協力しあって進める

と言うことです。

ここで言うプロジェクト関係者とは、プロジェクトで実動するメンバーだけでなく、たとえば上司や企業そのもの、あるいは顧客なども含まれることを忘れてはなりません。つまり

　『丸投げしていればいい…なんてことは絶対に無い』

ということです。