チームで成功を目指す
チームにはカラーというものがあります。
カラーとは個性であり、チーム以外の人から見える明らかな特徴です。にぎやかなチームや活気のあるチーム、規律あるチームは、一般的に良いカラーと言われています。逆に、静まり返ったチームや話すこと自体が悪いという空気の中で行うチーム、規律や基準、ルールの無いチームは、悪いチームと言われています。
特に、仕事に関した「コミュニケーション」すらも阻害する人は、いかなる事情があったとしても、チームにとって悪影響を及ぼします。
チームのカラーとはいえ、実際にはリーダーの影響を受けています。あなたの周りのチームを思い浮かべてみてください。多かれ少なかれ、リーダーの個性が反映されているでしょう。
これは悪いことではありません。
ただ、これだけでは物足りません。
プロジェクトの主役は、実際に活動している担当者、メンバーです。
サーバント型のリーダーシップが求められる昨今、リーダーやマネージャーが主役であってはならないのです。より仕事を楽しみ、成長するには、みなさん一人ひとりの色もチームのカラーに混ぜ込みましょう。
自分のカラーが大事だといっても、自分勝手な思いや振る舞いを勧めるものではありません。リーダーと共にチームのカラーを作り上げてほしいのです。
どのようなプロジェクト活動にもリーダーシップは必要となってきます。特に、トラブル時など重要な意思決定の局面では、リーダーの采配に従わなくてはいけません。
しかし、チームカラーは日常の行動の積み重ねから自然と醸し出されます。
プロジェクトの「日常」はメンバーである開発担当者が作り上げるもので、そのために次の３つの力を鍛えなくてはいけません。
リーダーとの関係構築力
まず重視したいのはリーダーと良い関係を築く力です。
特に若手の開発者は、お客さまよりリーダーとのコミュニケーションの頻度が多いはずです。リーダーと良い関係を築くには、リーダーのカラーをつかみ、それに応じて自分のカラーを出していく必要があります。
いたずらに自分の我を出しても、確実にチームに悪い影響を与えます。
私は、リーダーのカラーを決めるのは「意思決定の癖」だと思っています。
図は「意思決定においてトップダウン／ボトムアップのどちらを好むか」を横軸に、「意思決定においてプランニング(事前の計画）／アドリブ(その場の判断)のどちらを好むか」を縦軸にとって類型化したものです。
図のそれぞれの象限が代表的な「リーダーのカラー」です。
特徴をイメージするわかりやすい名前をつけてみました。
類型化し過ぎかもしれませんが、私が今まで付き合ったリーダーを思い浮かべると、ほぼ100%いずれかのタイプに分けることができます。程度の差や２つの象限の中間の人ももちろんありえると思います。
私自身はと言うと、「バリバリ」型ベースにして、その下に就くメンバーの能力や性格を見ながら、「サクサク」型と「よしよし」型との間をロールプレイするようにしています。
｢バリバリ」リーダーとうまくやる
バリバリリーダーは一般に優秀だと言われるリーダーで、受託開発にはこのカラーを持つリーダーは多いと感じます。納期が重視される開発や大規模な開発、あるいは新規のお客さまや市場開拓するような開発に向いています。
バリバリリーダーには、きっちりと計画し、慎重に行動するタイプが多く、メンバーにも同様の行動を期待します。
バリバリリーダーの下で自分のカラーを出すには、リーダーとは被らない特技を持つのかいいでしょう。リーダーの不得意分野の技術を持っていれば、リーダーにとって心強いメンバーとなります。
いくぶん厳しめなリーダーですが、その下でオンリーワンな右腕を目指しましょう。
「サクサク」リーダーとうまくやる
このタイプのリーダーはとっさの判断力が優れていて、トラブルが発生してもメンバーにはそのような印象を与えません。判断力のスピードがそうさせるのでしょう。
サクサクリーダーは、比較的小規模でスピードが必要とされる開発に向いています。事前の計画を守るというよりは、プロジェクトの状況に応じて作業の優先度を適宜変更し、最終的には何か成果を残すタイプです。
このタイプのリーダーとは仲間感覚で仕事が進みがちです。
それはそれで楽しいチームになることも多いのですが、それに甘え過ぎないよう注意しましょう。自覚のないまま「甘える」ことに慣れてしまうと、ほかのタイプのリーダーやお客さまとのギャップに苦労することになります。
｢よしよし」リーダーとうまくやる
このタイプのリーダーは、チームを引っ張るというよりはチームを支えるマネージャ的な存在です。大方針は変えませんが、細かな方針変更は跨跨しません。
適材適所を心がけるリーダーで、あなたのキャラクターに合った役割や作業を振ってきます。大方針とマッチしている限り、あなたのやりたいようにやらせてくれます。
その分、メンバーに対しては主体的な行動と成果を期待します。
指示待ちオンリーの受動的なメンバーは好みません。
よしよしリーダーは、各メンバーの行動の癖や性格ですら織り込んで計画することもあります。優れたリーダーほどその傾向が強く出ますので、困難かも知れませんが、期待を上回る成果を出すことで、リーダーに驚きを与えてやりましょう。
｢ふむふむ」リーダーとうまくやる
一見優柔不断。
これが、このタイプのリーダーの特徴です。
開発者の言葉に耳を傾け判断の材料とします。
ふむふむリーダーとは、「○○でいいかな？」といった質問形式の会話が多くなります。開発者にとってやりやすい環境のように思えますが、実はプロジェクト全体にとって良いことではありません。
みんなの言うことを聴き過ぎて、折り合いがつかなくなるくらいがんじがらめになってしまったり、人間関係の修復に手間取って、本質的な仕事に従事できず、リーダーにストレスが溜まりがちなのです。
メンバーが主体的に、リーダーを上手に盛り立てていきましょう。優柔不断とはいえ、まったく判断ができないわけではないのです。問題は、"建設的"であっても、"非建設的"であっても、分け隔てなくなんとかしようと抱え込んでしまうだけなのです。
メンバーは自分本位にリーダーを振り回すのではなく、常にプロジェクトのことを考えながら、会話を通じてリーダーに意見を伝え、プロジェクトのコントロールに「こっそりと」協力しましょう。
「普段着」の行動力
リーダーとの関係を意識するだけではチーム全休に影響を与えられません。
あわせて必要なのは行動力です。「普段着の行動」とは、日常の何気ない行動です。
強いリーダーシップだけでなく、メンバー一人ひとりの小さな行動の積み重ねでチームのカラーを変えることができるのです。
具体的には次の4点を意識した行動を行います。
目的と課題の共有
まず目的の共有が最優先です。
ソフトウェア開発に限らず、すべての仕事には目的があります。
プロジェクトの目的、与えられた役割の目的、作業の目的、機能の目的。
こうしたすべてにおいて目的を共有します。
課題の共有も重要です。課題はプロジェクトで乗り越えるべき壁であり、ちゃんと共有・管理されている課題であれば必ず解決できます。「技術的なリスク」などは、課題の代表例でしょう。リーダーだけが目的や課題を握ってしまわないよう、メンバーとして心配りを怠らず、これらの共有を進めるような働きかけを行います。
目的を共有するためには、普段の発言を工夫します。「目的」という言葉を意識して多用し、リーダーの指示ごとに目的を確認します。
リーダーが目的を把握していないのは、プロジェクトが失敗する兆候です。リーダーに目的を明確にするよう要請してください。
目的とは違い、課題はメンバーが発見することも多くあります。
課題を自分で抱え込まないよう意識してください。
プラスαの行動
お客さま相手でなくても「プラスα」の精神を発揮してください。言われたことだけをやっているのでは、周囲と比べても、市場と比べても、当然魅力と競争力が弱くなります。
調べ物一つするにしても、Googleですぐにわかる情報に価値はありません。自分の頭と手と足で稼いだ情報をチームに提供し、しかもそれをさりげなくアピールします。
プラスαの行動をするには、絶対的に『主体性』が必要です。
つまり、自分なりの立場でプロジェクトのことを真剣に考えて行動し、結果を出してください。
スティーブン.R.コヴィーの「7つの習慣」によると、「主体的」の反意語は「反応的」です。リーダーの言動に極度に反応したり、ついリーダーの指示命令を待ってしまうことはありませんか？
リーダーに依存し過ぎてはいけません。
よくできたリーダーが求めるのは言いなりのメンバーではありません。主体的に行動し、プラスαをもたらしてくれるメンバーなのです。
冷静と情熱のバランス
メンバーにも、もちろん主義主張はあります。
それがすべて認められるかどうかはさておき、自分の主義主張は明確にしてかまいません。ただ、突っ張るだけが主義主張を通す方法ではありません。時には現実と妥協もしつつ、自分の思いと組織の目標をすり合わせ交渉する冷静さも必要です。
身内であるリーダーと交渉するなんて大げさだと思われるかもしれません。
しかし、主張し、譲歩し、獲得するという活動は交渉そのものです。
一方、愚直に継続することも必要です。
継続される情熱が信念に変わります。新しいプログラミング言語や開発プロセスはそう簡単に採用されません。下請けの立場でやっている場合は特にそうです。時期を待ち、腕を磨いておくしかない場合も多いのです。それでも愚直に研讃を続けることで、理想に近づくことができる人もいます。
たとえば、「自分だったらこうする」というイメージを練りに練っておき、
次のプロジェクト以降で活躍する場を得た時に、スタートダッシュする人などです。
・理想を実現するために現実を見つめられる冷静さ。
・自分のやりたいことをあきらめず、「いつかみんなのためになる」と思って情熱を持ち続けること。
普段からこれら２つのバランスを心がけましょう。
チーム優先
個人ではなく「チーム全員で成功すること」を優先します。
こう書くと精神論めいてますが、プロジェクトの士気を下げるような言動を慎むだけで効果があります。すぐに試せる具体的な行動として次の3つがあります。
・解決できない、非現実的な陰口や文句を止める
・困っているメンバーに話しかけてみる
・元気にあいさつしてみる
おそらくリーダーは率先してこれらの行動を行っているはずですが、もしまったく逆の行動をしているようであれば、メンバーがリーダーに対して指摘しなくてはいけません。
できればチーム全体でリーダーをフォローしたいものです。
もう一つ、チームで決めたことには積極的に関わります。「朝会」や「ふりかえり」といった「プロジェクトファシリテーション」のプラクティスを導入しているチームも多いでしょう。プロジェクトファシリテーションは、プロセスとコミュニケーションを「見える化」し、「カイゼン」する力を持ったテクニックです。
しかし、これらはリーダーの旗振りだけでうまく機能するものではありません。メンバー全員の参加があってこそのプロジェクトファシリテーションですから、チームで決めたことはメンバーも協力します。
たとえば、朝会はリーダーがいなくても実施できなくてはいけませんし、ふりかえりはリーダーが指示をしなくても率先して行ってください。
交渉力
良いチームを作り上げるには交渉も避けられません。交渉といえばリーダーの仕事のようですが、開発担当者にも交渉の機会は多いのです。
開発現場でよくあるケースを題材に考えてみましょう。
重要な仕様変更が入り、今週中に対応する必要がありそうです。
しかし、今週末は友達との旅行の約束があって週末に出勤したくはありません。辛い状況です。どう解決したらよいでしょうか。
リーダーとメンバーでは利害が一致しません。
リーダーは休日出勤を望み、メンバーは休みと旅行を望んでいます。
交渉とはコンフリクト（衝突）の解消です。
交渉力を身につけ、コンフリクトの解消をしなくてはいけません。そのためにまずは「交渉の３原則」を覚えてください。
原則1：勝ち過ぎない
交渉とはWin-Win、つまりは共益関係の探りあいであり、それが目的です。特にお客さまと開発チーム、リーダーとメンバーといった「長い付き合いとなる関係」では、一方がLoseとなってしまってはいけません。
勝ち過ぎは禁物です。
たとえば、リーダーの立場からすれば、開発担当者から妥協を引き出すのは難しくないでしょう。休日出勤の例では「仕事が最優先である」という言葉を使えば交渉は有利に進められます（もはや交渉ではないかもしれませんが）。
ただそれで1日分の工数を勝ち取ったとしても、それにより失うものも大きいかもしれません。
ほかの勝ち方はないのでしょうか。
たとえば休日ではなく、平日の残業によってカバーするやり方もあります。
作業をチームで分担し、休日の午前中には終わらせるやり方も考えられます。
お客さまとの交渉でも勝も過ぎには注意してください。
たとえば、困っているお客さまの足元を見るような価格交渉をすると、いつかしっぺ返しを喰らいます。お客さまとの関係はプロジェクトの期間よりも長いのです。今回だけよければいいという考え方はサービス中心主義に反します。もっと長い目で見た関係を考えてください。
原則2 ： 代替案を持つ
交渉術では
「最悪の場合の代替案」
(BATNA=Best Alternative to Negotiated Agreement）
という用語に相当しますが、要は「自分が最低限守りたいことは事前に考えておけ」ということです。
旅行に行きたい開発担当者を例に取ると、旅行のプランは修正可能かどうか、その場合の条件は何かまで考えておきます。その結果、どうしても譲れないのは「今月中の旅行」なのかもしれず、そうなれば交渉の余地が広がります。
リーダーの立場で考えると、仕様変更を受けなかったらどのような不利益があるかお客さまとチーム双方の立場で冷静に検討する必要があります。もしかすると、変更の重要度はリーダーの想定より低いかもしれず、実際には変更の時期は調整可能なのかもしれません。
BATNAをオープンにするかクローズにするかは相手によります。
一般にはBATNAは相手に悟られてはいけません。
たとえば量販店での買い物です。
ここでのBATNAは「出してもいい最高金額」となりますが、これを店員に悟られては値切り交渉はうまくいきません。ただ、特に身内での交渉の場合、腹を割ってBATNAをオープンにするほうが話を早くまとめることができますし、そもそも無用な探りあいは気持ちが良いものではありません。
相手によってオープンにするかしないかのさじ加減を調整してください。
原則3：気づきと築き
交渉のプロ同士でない限り、お互いに自分が本当に望んでいることに気がつかないことも多いのです。特に開発現場での開発者同士、開発者とリーダー問での交渉はそうです。
リーダーがメンバーに、メンバーがリーダーに、開発者がお客さまに、相手が本当に望んでいるであろうこと、喜ぶであろうことをどんどん提案します。
交渉の場は、お互いの気づきの場でもあり、信頼を築いていく場でもあります。先ほどの例ですと、リーダーが本当に望んでいるのは休日出勤ではありません。期日までにお客さまの要求になるだけ応え、顧客満足を下げないことを望んでいるのです。
信頼関係が築かれることで、不毛な神経戦としての交渉が不要になります。
お互い、素直に自分の考えや気持ちを伝えられる関係を目指しましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。