プログラム設計やソフトウェア関連のコンサルティングなど、コンピュータ周りの業務を幅広く手掛ける、世界に「０」をONする会社、株式会社コンピュータ技研(略称C.T.L)。次世代を担う若手社員が 「ミライに挑戦する、ミライを創る、ミライへONする」をスローガンに掲げ「自身の成長」と「社内貢献」のために「Next C.T.L」を運営しています。
こんにちは、入社4年目の岩藤です。
今年の6月、現場リーダーになりたての時にとあるブログを書きました。
現場リーダーを務めるまでの過程と、務めてからの3ヶ月間を振り返るという内容です。
リーダーを務めるまでの不安や葛藤、前向きに考えれるようになった過程を赤裸々に書いています。
どのような葛藤を乗り越えてきたのか、良かったら先にそちらを読んでみてください。
さて、今回は1年間リーダーをしてきて学んだことを振り返ろうと思います。
この記事で伝えたいことは、以下の5つです。
目次にもなってますので、気になる章からでも読んでみてください。
この記事は若手社会人の方に向けて書いております。
リーダーを目指す方だけでなく1人のメンバーとして働いている方、そして今後のキャリアに悩んでいる方にとって、気づきがあるかもしれません。
（本記事ではリーダーの下で働く方を、メンバーと表現します）
人それぞれの背景がありますので共感出来る内容は少ないかもしれませんが、ご自身の数年後をイメージして読んでみてください。
①チームとしてのスタンスを示し、チームの為には衝突を恐れない
私はリーダーの仕事の一つは、“決断すること”だと思っています。
そのうえでスタンスを示し、時には衝突を恐れずに主張をしなければならない場面が訪れます。
具体的な例を挙げましょう。
私は現在、運用業務を担当しています。
既に範囲も手順も決められている仕事には都度都度の決断は発生せず、基本的には迷うことはありません。しかし、手順に無い作業依頼やお客様相談、前例のない不具合事象に遭遇することがあります。
その際はリーダーの出番です。
トラブルをハンドリングして進むべき方針を決め、落とし所を探すことが求められます。
実際に、他のチームから作業負荷が高い運用作業の依頼が来た場面がありました。
衝突を恐れて「はい喜んで」と受け入れていては、チームメンバーの作業負荷が大きく上がってしまうことが予想されます。
そこでチームとしてのスタンスを明確に示し、「我々の作業範囲と稼働を考慮して、ここまでは出来ます。これ以上は出来ません」と主張をしました。
そうすることで一緒に折衷案を検討することとなり、事なきを得ました。
多くの会社と一緒に働くSEの現場リーダーとして、他社(他者)との衝突を恐れずに主張することが大切だと学んだ経験でした。
同じ現場にはC.T.Lや協力会社といった身内だけではなく、多くの他社さんがいます。
そして、仕事を発注してくださるお客様がいます。
各会社で理念が異なり、スタンスが異なります。
誰しもが自分の都合の良いように考えて仕事をしていますので、意見の衝突は起きて当然です。
リーダーはチームを守るために、前に立って主張をしていく必要があると考えています。
②メンバーの意見を傾聴し、チームで決断をする
自分の意見を持ちながらもメンバーの意見を集約し、1本の軸の基でチームの決断をする。
私はこうした進め方が理想と考えているため、1人で決断せずに、頻繁にメンバーに意見を求めました。
時にはチーム内でも意見がぶつかったり、私の意見が誤っていた場合があります。
強いリーダーならばその場合にブレない姿勢を示すことも必要でしょうが、私は強いリーダーではなく“サーバントリーダー”になりたかった。
そのため勘違いや知識不足といった自分に非があるものについては即訂正し、謝罪をしました。
“サーバントリーダー”とは
支配型なリーダーシップとは対となるスタイルで、
「まず相手に奉仕し、その後相手を導く」という支援型なスタイル
また、想像してみてください。
あなたが1人のメンバーで、リーダーと意見がぶつかった際に、リーダーが「私が正しい」と強い姿勢を貫いたらどのように感じますか？
「せっかく意見を言っても採用されない。言っても仕方ないじゃないか！」、そんな負の感情を抱きませんか？
そうなると今後意見を求めても、主張してくれなくなる可能性があります。
思っていても言えない状況は不健全です。
そのため変に意固地にならずにメンバーの意見に耳を傾けて、チーム全体で議論をして答えを導き出すべきだと私は思います。
チームで導いた意見にはメンバーも責任を感じ、自分事として主体的に対応してくれます。
リーダーだけではなくメンバーにも、精神的な責任感を分散していくことが理想だと考えています。
また、細かい話ですが、メンバーから相談や質問が来た際は一度手を止めて、体ごと相手に向けて話を聞くことを意識しています。
忙しい時はなかなか難しいですけどね。
③協力者を作る。まず身内から、そしてお客様へ
リーダーを務めるうえでの心配事として、私は技術力不足を感じていました。
現在の現場には配属されてから1年ほどしか経過しておらず、ある程度のプログラミングは出来ても現場特有の知識が不足していた状態です。
そこでリーダーを務めることが決定してから一番始めに実施したことは、
私より先に現場で業務をしていた後輩、そして協力会社の方にこのお願いをしたことです。
私には足りていないところだらけです。皆さんの知識と経験を基に、助けてください。
するとメンバーの皆さんから積極的に意見を出したり、決断するために必要な情報収集を自主的に実施してくれるようになりました。
協力会社の方は10歳上、そして20歳上の2名です。
年上の方に協力者になってもらうことが出来た経験になりました。
そしてお客様に対しては日常的な会話をすることやレスポンスの早さを意識し、万が一決断に迷っていた際は早めに懸念点を伝えるようにしました。
そうすることで目をかけてくれ、私に不足していた部分のアドバイスを頂けるように。
「ガムシャラに頑張っている」ということで、協力者になってくれました。
ありがたい話です。
話は変わりますが、チーム内にタイプの異なる方に居てもらうことも大切だと感じています。
タイプが異なると見る観点が異なり、自分は持っていなかった観点で意見を貰えます。
リーダーに観点が欠けていると、誤った答えを導き出してしまう恐れがあります。
そのためチーム内から別観点の意見、時には反対意見を貰えることは、非常にありがたいです。
④過去事例から、決断する観点を学ぶ
私が前リーダーから仕事を引き継ぐ際、主に業務内容を説明されました。
「毎月第1週は○○の仕事をして、第2週には△△の仕事をします。それぞれのやり方は◻︎◻︎です」といったイメージです。
しかし、この説明の仕方はメンバーに向けたものなら十分でしょうが、リーダーに向けたものとしては不十分です。
リーダーは決断をする立場であり、今後の決断を自分自身がしなければなりません。
決断に必要なのは、「何を重視するか」という観点です。
なぜその時にリーダーはその決断をしたのか、
その決断によって何が起こったのか、現場の過去事例には観点が眠っています。
そのため観点を前リーダーにとことん質問しました。
その甲斐があって、決断に迷った際は過去事例を基に観点を確認し、決断出来ています。
そして今強く感じていることは、自分の決断が後の過去事例となるということです。
「あの時岩藤さんがこう決めたので」を盾（理由）として、同じ決断を後のリーダーがするかもしれません。
そう考えると、安直な決断は出来ません。
決断する上で意図は明確に説明し、過去事例やこれまでの示してきたスタンスからは外れない決断をするべきです。
また、過去や他チームのインシデントに対して「いま自分のチームで起きなくて良かった」なんて安心するのではなく、貴重な勉強材料として読み込むことをオススメします。
ミスは誰でもするが、ミスの種類や仕方が大事です。
人為的なミスなのか、内在的に隠れていた時限爆弾のようなミスなのか。
そして「まぁ大丈夫か」といった慢心によるミスか、防ぎきれないミスなのか。
ミスの種類や仕方によって対策の立て方が違うと思います。
自分の現場でも細かいミスは起こってきており、その多くが人為的で注意が不足していたことによって起こるミスで、防げるものでした。
同じミスを繰り返さないように、過去事例から学んでいきたいと思います。
⑤メンバーとリーダーには求められる視野・視座が異なる
私は3年目までは、1人のメンバーとして働いていました。
そして4年目の現在はリーダーを務めています。
その過程で、プレイヤーとリーダーの見える景色が、“範囲”と“時間”の2軸で異なると感じています。
メンバーが見ている”範囲”
私が1年目の頃は、会議では知らない単語が飛び交い、周りに喰らい付いていくのがやっとでした。
そして2年目になると依頼される作業が増え、3年目では自社からは1人で案件参画して他社さんと仕事をするようになります。
そんなメンバーが見ている“範囲”とは、“目の前の作業”です。
例えば正常に動作するツールを作ることや、ユーザーからの不具合問い合わせを解消するといった、技術レベルです。
そしてプレイヤーが評価される要素は、目の前の作業を完了することになります。
リーダーが見ている”範囲”
私は4年目でリーダーになると、新人を含めた後輩2名と10歳以上も年上の協力会社さん2名を率いるようになります。
時にはお客様や他チームから作業依頼が来ます。全ての作業を私がやっていては時間が足りません。
リーダーになってからは、各作業をメンバーに振ることが仕事のひとつになりました。
そんなリーダーが見ている“範囲”とは、“作業全体”です。
例えば必要な作業を洗い出したり、午前中にプレイヤーに振った仕事は円滑に進んでいるか確認・フォローすること。
さらに、作業を他の方も出来るように説明・教育することも仕事の一つです。
特に作業を振るにあたっては、メンバー間の作業量の偏りが生まれないように「作業の難易度」と「メンバーのキャパ」を客観的に把握することが必要なため、視野の広さが重要です。
そしてリーダーが評価される要素は、作業全体が円滑に進むことになります。
メンバーが見ている”時間”
そして見ている”時間”にも違いがあると感じています。
メンバーが見ている時間は主に、“目の前の作業の締め切り”です。
担当している作業はいつまでなのか、それまでに今日はどこまで進めておこうかと考えて着手しています。
リーダーが見ている”時間”
リーダーが見ている時間は主に、“作業全体のスケジュール”です。
作業全体の締め切りはいつか、そのためにプレイヤーが持つ各作業はいつまでに完了するべきかを把握する。もしも遅れが発生しそうであれば改善策を考えることがあります。
そのためには作業一つ一つを細かく見るのではなく、広く見通しておくことが必要です。
メンバーとリーダーに見えている範囲と時間に違いがあるため、このようなコミュニケーションエラーも起こります。
- 上司に資料のチェック依頼をするタイミングが定時ギリギリ。メンバーはチェック依頼で仕事が終わりだと思っているけど、リーダーは依頼されてから仕事が始まるため、残業確定となってしまい怒られる。
- 自分の範囲内は100点の出来なのに、他プレイヤーが進捗が悪いのを放置。そしてチームとしてミスが起こる。
私はリーダーとして全体を見る中で、「これを放置するとトラブルになりそうだ」というリスクの予見ができるようにもなってきました。
その際は、事前にトラブルの種になりそうなものは摘み取っていきます。
具体的には、必要な作業を適切なメンバーに振ること。
そして先方(時にはお客様)に観点を伝えて確認すること。
一歩引いて全体を見ることによって、メンバーの頃とは違った広い視野が磨かれた経験になりました。
最後に
ここまで偉そうに語りましたが、常に上手くいったわけではありません。
やはり単純なミスもするし、後輩にカバーしてもらうことも多かったです。
それでも現場ではC.T.Lのトップとして、リーダーとして仕事が出来た1年間の充実感は濃いものになりました。
私は入社当初から「責任感ある仕事に就いたい、特にリーダーになりたい」と主張し続けていました。
そんな中で実績が一つも無い中で4年目でリーダーを任せて頂けたのは、全ては偶然でした。
先輩が次々と異動して、私が現場の最年長になったためです。
現場撤退も選択肢の一つの中で、「岩藤が主張しているからやらせてみよう」と信じてくれた上司には感謝しかありません。
私はこの記事を通して、皆さんに問いかけたいことがあります。
それは、メンバーとリーダーどちらの道を進みたいか考えて欲しい、ということです。
メンバーとリーダー、どちらもSEにとって重要なポジションです。
どちらの方が偉いという差はありません。
どちらもプロのSEで、役割が違うだけです。
メンバーとしての道を極めたい方はとにかく一つ一つの作業に誰よりも詳しくなり、知識の深みを意識することが大切かと思います。
そしてリーダーとしての道を極めたい方は作業の意図や背景を理解して他者に説明出来るようになり、知識の広さを意識することが大切だと思います。
弊社C.T.Lに複数のポジションがあり、それぞれの道が提示されています。
プレイヤーはProfessionalという分野の、coreに当たります。
リーダーはManagerという分野の、sunやmoonに当たります。
最後に一言。
「あなたはメンバーとリーダー、どちらの道を進みたいですか？」
拝読ありがとうございました。
