開発に「個人主義」は持ち込むな
システム開発作業は一般的にプロジェクトチームを結成して実施します。まぁ１人プロジェクトはいったん置いておきましょう。
プロジェクトチームと言うのは野球やサッカーなどスポーツのチームと同じで、監督の指導のしかた、チーム１人１人の能力、チームワークなどによって強くもなり、弱くもなります。
みなさんはそのチームの一員として行動しなければいけません。皆さんの心がけ次第で、そのチームが良い成績を上げられるかどうかが決まります。
チーム活動を円滑に行うためには、どのようにすればよいか具体的に考えてみましょう。
大事なのはチーム内のコミュニケーション
チーム内のコミュニケーションがきちんと取られているかどうかにかかっています。プロジェクトが失敗する要因の多くはコミュニケーションがうまくいき成立していないことで起きているからです。
懐かしいですね、この図。
この図における期待通りとならない結果の多くはコミュニケーションの失敗によって起きています。「お客さまのニーズを実現する」という集団的な目的意識の徹底ができていれば失敗の多くは防げたのでしょうけど、マネージャーの思い込みやエンジニアの個人主義などが横行するとこうなってしまうのは仕方のないことなのかもしれません。
だからこそチーム活動でまず考えなければならないのが、「チーム内のコミュニケーションを良くするにはどうすればよいか」です。みなさんもチームの一員としてコミュニケーション向上のために努力しましょう。
では、チーム内のコミュニケーションを良くする為には実際にどうすれば良いのでしょうか。
ありがとう、ごくろうさま、すいませんの言える人になる
みなさんが先輩の立場に立ったら、後輩に作業の依頼をする機会も出てくると思います。人に作業を依頼した時には、「ありがとう」「ごくろうさま」の一言を当たり前に言えるようにしましょう。できれば自分がどんな風に助かったのか、実情や気持ちを付け加えて言うとさらに効果が倍増します。
これは親しき仲にも礼儀ありの精神に基づきますが、実際にこういったさりげないあいさつや感謝の意すらもない開発現場はピリピリとした刺々しい雰囲気がするものです。
「ありがとう」「ごくろうさま」のたった一言があるだけで、相手も「やってよかった」と言う気持ちになります。また人からのアドバイスは素直に聞き、自分に誤りがあるとわかったら「すみません」と言える人になりましょう。
「だって」や「でも」といった言い訳前提の反語は絶対禁止ですが、何も言わずに不貞腐れるのも非常にチーム内の空気を悪くしてしまうので要注意です。このような、何気ない一言がチーム内のコミュニケーション、ひいては情報の風通しを良くしてくれるのです。
気心が知れてくる雑談などの会話もできるようになってくるのでしょうけど、逆に雑談は仕事の集中力を妨げ、作業の生産性を下げてしまいますので、そこまでチーム内の空気が弛緩するのはよろしくありません。しかし、朝の「おはようございます」、帰りの「お先に失礼します」などといった挨拶や感謝の「ありがとう」など、たった一言をきちんとするだけでも、チームの雰囲気はグッと変わってくるものです。
プラス思考で物事をとらえる
「こんな仕事、もうしたくない」とか「あの人のあんな所が嫌だ」等と物事のマイナス面だけを見ていると、自分の殻に閉じこもってしまってコミュニケーションも同時に滞ってしまいます。
少しでも「イヤだ」と思うことがあったら、その事柄をマイナス思考でとらえるのではなく、ものは試し程度にプラス思考でとらえるようにしてみましょう。
たとえば、仕事を「イヤだ」と思っているのは何が原因なのでしょうか。
単純な好き嫌いだけで言っているのであればその考え方自体を改めた方が良いかもしれませんが、その仕事が大きすぎて自分には荷が重すぎるのであったら
「自分は責任のある仕事を任されている。
期待に添えるように頑張ろう」
とプラス思考で考えてみましょう。そう思ってみて、それでも受けいれられないようであれば、もっと他に理由があるのかもしれません。
たとえば、イヤな人がいるのは何故でしょうか。
その人の嫌な面ばかりが目についているのではありませんか？
少し、客観的になって見方を変えてみてはどうですか？
その人の『良い』面も認められるようになりましょう。「イヤだ」と思っていた人に対する考え方が変わるはずです。
自分ならではの意見を持つ
素直に人の言うことを聞く人は、職場で歓迎されます。
しかし、ただ人の意見に従って動くだけの「Yesマン」では、チームのコミュニケーションの和に入ることはできません。みんなの意見を聞いたうえで、自分なりの考えを持つようにしましょう。そして会議などの場では自分の意見を積極的に発言するように心がけましょう。
自分の意見をきちんと述べられれば、チームのコミュニケーションをスムーズにすることができます。
チーム活動の基本マナーを守ろう
チームで活動するためには守らなければならない基本マナーというものがあります。この基本的な行動指針ができていなければ、チーム活動を円滑に行うことができません。
では、チーム活動を円滑に行うための基本マナーとはどのようなものがあるのでしょうか。
チームで決めたルールは守る
チーム活動において、チーム内の決めごとを守らないのは最大のマナー違反です。チームを構成する要であるルールを守らないというのであれば、それはもうチームと呼べません。
もしもメンバーがルールを守らないのであれば、チームで作成しているシステム全体の品質や納期に影響を与えてしまうことでしょう。
たとえば、
「プログラムの使用を自分勝手な判断で変更する」
「レビューを事前に行わない」
などがあります。いずれもチームのルールを守らなかったばかりに、システム全体に影響を与えかねないものです。チームのルールについては「自分ひとりくらい守らなくても大丈夫だろう」と言う考え方は絶対に捨てましょう。優先座席の席を譲るとか、赤信号を渡ってしまうとか、そう言ったレベルの問題とは根本的に異なります。
１つ問題が発覚すると、お客さまからは
この会社は、ルールを守らせるという当然のことすら徹底させていない
この会社は、信用できないかもしれない
と思われてしまいます。なぜなら、１人でもそういう事をしてしまうような杜撰なチーム編成で仕事をしている会社だと思われるからです。たった１人の勝手な行動が会社そのものの信頼にも影響するのです。
相手の立場に立って物事を考えよう
相手の立場に立つことがチーム活動の出発点です。
私たちはつい主観的で自分中心的なモノの見方をしがちです。
常に意識して
「今、相手の立場だったら、どう思うかな」
「自分が相手の立場だったら、どんなことするかな」
と考えることが大切となってきます。
たとえば、自分の作業のやり方についてプロジェクトリーダーから指摘を受け、作業のやり直しをしなければならなくなったとします。
自分中心的な考え方をすれば、
『自分はアレで良いと思う。前のプロジェクトでもアレでやったし』
『今から直せと言われてもスケジュール遅れるし、面倒くさい』
と考えてしまうことになるかもしれません。
しかしプロジェクトリーダーの立場に立ってみたらどうでしょう。
プロジェクトリーダーは
『ここでやり直しは正直痛いけど
ここでやり直しておかないと次の工程からは他社も絡んでくるし
もっと大きな問題になってしまう…』
と考えているかもしれません。『自分は…』と考える前に、『相手は…』と考えることが集団活動における第一歩なのです。
助け合いの精神を持とう
チームのメンバーと言うのは困った時に一番頼りになる存在です。
メンバー同士はお互いに「困った時は助け合う」という精神を持ちましょう。メンバーが何かミスをした時に相手を一方的に責めるのは絶対に良くありません。作業は個人単位で行っていても、責任はチーム全体にあります。メンバーの１人が困っていたら、メンバーとして助けるのは当然のことです。メンバーはお互い困った時には相談しあい、チームとして素早く問題を解決することがプロジェクトの仕事を成功に導きます。
また、助け合いは「助け合う」からこそ成立するGive And Takeの精神で行いましょう。
よく「あの人はちっとも協力してくれない」と言う話を聞きますが、待っているだけでは相手の協力は得られません。他人に助けを求めるばかりで、自分からは一度も手を差し伸べようとしたことがない人もよく見かけます。
まずは自分から協力しようと言う姿勢を表しましょう。
さらに、いつもいつでも一方的に助けてもらっているばかりではただ『甘え』ているだけの状態と変わりありません。協力してくれる人も自分の仕事を持っていて決して暇なわけではないのですから、なんでもかんでも助け合いと言う名のもとに、他人に頼ることを覚えるのは止めましょう。
人の話はよく聞こう
チームのコミュニケーション不足は人の話をしっかりと聞かなかったことによるものが多いようです。人の話をしっかり聞かないことによって、作業内容が正確に伝わらず、作業が終わる頃になって「そうじゃなかった！」と言う事態が起きてしまうことも珍しくありません。
そのような事態を引き起こさないためにも、人の話は正確に聞くようにしましょう。
また、リーダーは関係者全員に伝えているつもりなのに、チーム内のある人の質問を起点に質疑応答の場に変わってしまった場合等は、実際に質問している人以外のみなさんは『自分には関係ない』と思って聞き流していることも多々あります。
自分に直接語りかけていない話でも、共有すべきメンバー間で話している内容は極力『自分にも関係するかもしれない』と思って聞くようにしましょう。
このほんの少しの注意力の違いが後の工程になって、数人月（100～200万円以上）の無駄な作業に影響を与えてしまうことも珍しくありません。
とはいっても、人の話も『ただ聞けば良い』と言うものでもありません。
相手の言いたいことをわかろうとする姿勢が重要です。
みなさんも自分が一生懸命説明しているのに、相手が黙ったままでなんのリアクションも返さなければ『もうこれ以上説明しても無駄かな』という気分になるはずです。私もなります。
話す相手が話しやすいような聞き方をするようにしましょう。
たとえば、
・うなずく
・相槌を打つ
・相手の話を促すように「それから？」と言ってみる
など、様々な方法があります。
「こんなことは言わなくてもわかっているだろう」とか「便りが無いのは元気な証拠」といって、自分の意志を言語化することを億劫に感じてしまう人もいるかとは思いますが、そうした『空気を読む』といった従来の日本人的な発想は思わぬコミュニケーション障害を生み出すことにつながります。集団活動を著しく阻害してしまう行為となりかねませんので、絶対に避けるようにしましょう。
優れたリーダシップ
配属されて１年が経ったらもう先輩です。『新人だから』と言う言い訳はもう使えません。『新人』という肩書きは、一生のうちでたった１年間だけ使うことが許される特別なものです。
先輩ともなれば、スキルの高低に関わらず後輩の指導もしなければならなくなるかもしれませんし、その何年後かにはリーダー、あるいはサブリーダーとしてグループ内をまとめていかなければならなくなるかもしれません（そうなっていなかったら組織内でもお荷物扱いされている可能性もでてきます）。
では、グループ内をまとめるための優れたリーダシップとは、どのようなものでしょうか。
共通の目標を持たせる
まとまりのあるグループは、必ずと言っていいほど共通の目標や目的を持っています。共通の目標があるグループは結束が固くなり、作業への目的意識が強まります。また活動の一つひとつに統一感のようなものを感じます。
そのために、優れたリーダーは、必ずと言っていいほどグループ内に共通の目標、目的を持たせるように働きかけます。
たとえば、システム開発作業を行うプロジェクトチームであれば、チーム内で開発するシステムの共通のイメージを持たせるようにします。
「こんなシステムをいつまでに、どのくらいの予算で作るんだ」
「今回はこんなルールで進めていきたいと思う」
という共通の認識がチーム全体の目標となり、完成に向けてチーム全体で団結することができるようになるからです。野球やサッカーなどの団体スポーツを見れば明らかですよね。勝利するための目的や目標意識、戦略、戦術などチーム内で共有され、一人ひとりが意識を高め、チームワークへ貢献する努力をしないことにはまず勝つことは厳しいでしょう。
また、ルールや基準などを整備することも非常に有効です。
歩道、車道や信号など、ルールや基準となる元があるから、目的地まで安全に進めることができます。人の往来も自由、車の出入りも自由で、信号もなく、ルール（法規制）もないような場所では何１つ安心して進むことができません。
目標や目的と言った、ベクトルを指し示せないリーダーは、ただただ無法地帯でお山の大将を気取っているだけのようなものですから、必ずと言っていいほどチームを失敗に導きます。
共通の情報を伝達および共有する
システム開発作業は一人ではできません。というか、多くの仕事は一人で成立するものではありません。
チーム全員で一致団結してシステム開発作業をスムーズに行うためには、チームが「情報を共有する」必要があります。そのシステム開発に関する情報や業界の動向についてリーダーがチーム内に情報を提供し、チームが共通の認識を持てるようにしましょう。
チームが共通の目標を持つことで、チームの土台を作り、チーム全体で目標達成することができるようになります。
MBAのカリキュラムの中に「リーダー論」というものがあります。結論から言うと「これがリーダーだ！」と呼べる画一的な方法論はありません。リーダーの数だけスタイルがあると言ってもいいでしょう。そしてそれぞれに長所や短所があったりします。また、リーダーとは先天的になるものではなく、後天的に育っていくものであるというのも確立された事実でしょう。ゆえに、誰もがリーダーになれる可能性があるし、その人流の素養というものがあるはずです。スタイルさえ選ばなければ必ず何かしらのリーダーとして確立されることでしょう。
役割を与える
チーム内の役割分担は明確にしておきましょう。
できれば兼任はさせない方がいいでしょう。兼任を増やすと、チーム内の役割の境界線があいまいになり、結果的に「できる人に仕事を集め、できない人が楽をする」という図式へとシフトしていきます。すぐにはならなくても、長い時間をかけて徐々にそういう風土・文化が醸成されていきます。
あいまいな役割分担のまま作業を行っていると、
『自分だけが大変だ』
『これはやらなくても誰かがやるだろう』
と言う歪んだ気持ちになってしまいます。このような気持ちになってしまっては、メンバー同士に隙間が生じてしまいますし、作業の確実性もなくなってしまいます。
そんなことにならないために、チーム内のメンバには各自責任を持ってやらなければいけない役割を与えましょう。それができないうちはチームとして非常にいびつな状態であると言えますし、そのチームのリーダーにおいてもとてもまともなリーダーシップを発揮できているとは言えません。
しかし、だからといってチーム内の誰かが困っている時に
『自分の範囲はここまでだから』
と協力に否定的な姿勢を持つのはいけません。その活動がチームで取り組むものである以上、個人主義に走るチームメンバーは、チーム内のコミュニケーションを著しく阻害するだけでなく、困っている人の部分を補うことができずにシステム開発が失敗に終わってしまう可能性まで出てきます。
先ほども述べましたように「助け合いの精神を持つ」ことはとても重要なことです。大事なのは助け"合い"であって、一方的にもたれかかって甘えるだけの図式にしないことです。「助け合いが大事だ」と言って、自分は誰も助けようとしない…というのはチームを歪ませる最大の要因の１つとなりうることは理解しておきたいものです。
問題が発生しない限りにおいては役割分担を明確にし、問題が発生したら一致団結して解決にあたる。この最低限の臨機応変は絶対必要です。
意見の言える雰囲気作りをする
チームを率いるものは、チーム内の雰囲気を何でも言い合える風通しの良いものにするよう心がける必要があります。
何か決定事項がある時にはチーム全員で議論を尽くし、お互いに納得して作業に取り組めるようにします。チームの全員に『作業をやらされている』と思わせてはいけません。『自分たちで決めてやっているのだ』と言う参加意識を持たせるようにしましょう。
そのためにも日頃からの何でも意見の言える雰囲気づくりを心掛け、報告、連絡、相談を徹底させましょう。
指導・監督を怠らない
チームを率いるものの大きな役割は開発現場においてメンバーの指導と監督を行うことです。「タスクを丸投げしておけば後は勝手にやってくれる」と考えているうちはリーダーにもマネージャーにもなり切れていません。
もちろんマイクロマネジメントを推奨しているわけではありません。
任せるべき仕事は任せればいいでしょう。
しかし、委譲しているのはタスクに対する「役割」と「権限」であり、そのタスクの達成に対する責任は自分自身が持っているのだという責任感まで委譲していいものではありませんし、放棄していいものではありません。
責任まで委譲、放棄してしまえば、それはリーダーでもマネージャーでもなくなってしまうことを意味します。ただの「無関係者」です。
良くある失敗例としては、
リーダーやマネージャーがメンバーと一緒になって作業に熱中し、
全体の進捗や品質の監督ができていない
というケースです。プレイングマネージャーにはよく見受けられる光景ですよね。タスクとしては必要なことなのかもしれませんが、一方でリーダーやマネージャーとしての責任というものがあることも忘れてはなりません。両立できないのであればプレイングマネージャーになんてなるものではありません。
チームを率いるものになるというのであれば、いかなる理由があってもリーダーシップを持った役割を果たす責任を放棄しないようにしましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。