伝えたいこと
退職エントリーに代えて、退職に際してメンバーに伝えたことを、文章として整えて残しておきます。
この記事の主題はひとつです。信念を持て。そしてその信念は、固定された正解ではなく、経験を通して見つけ、磨き、更新していくものだということです。
入社から退職までの9年間、いくつかの内製システムの開発・運用に、リーダーとして関わってきました。
私が考えるリーダーの役目は、リーダーシップとマネジメントの両方を使い、メンバーの力を引き出し、組織の目標に貢献することです。
(参考:リーダーシップとマネジメントの違いについては別の記事でまとめています)
組織(チーム)とマネジメントとリーダーシップ - ぱと隊長日誌
ただ、その役目を果たす過程では、迷う局面が必ず来ます。利害が衝突する、正解がない、時間がない、辛い。そういう場面で最後に支えになるのは、ノウハウ以上に「自分は何を大事にするのか」という「信念(軸)」でした。
そして今はAIの進化が著しく、仕事の前提が大きく変わり続けています。だからこそ「やり方」はアップデートしつつ、「何を大事にするか」という信念(軸)は手放さないでほしい。そう思います。
私の信念
参考までに、私が大切にしている信念を紹介します。
1. 真摯であれ
プロとしての矜持を持ち、誠実に向き合うこと。誠実な行動は、信頼を少しずつ積み重ねます。信頼があるからこそ、新しいチャレンジを後押ししてくれたり、失敗したときに手を差し伸べてくれたりします。
ここで言う「真摯」は、具体的な作法というより精神に近いものです。自分が取ろうとしている行動や発言は、プロとしての矜持に基づくものだろうか。その問いを、節目節目で自分に向けられるかどうかが大切だと思っています。
(関連:過去にもう少し踏み込んで書きました)
「真摯さ」とは何か - ぱと隊長日誌
志あるチームであれ - ぱと隊長日誌
2. 情報は可能な限りオープンにする
言い換えるなら、情報を握って人を動かさないということです。
もちろん、情報の全てを何でも共有すればよいわけではありません。オープンにしないことが正しい情報もあります。私が「ここはオープンにしない」と判断するのは、たとえば次のようなものです。
- 「ここだけの話」など、秘密にすることを明示的に求められた話
- 主観的な見方に基づく他者批判
- 個人の信頼関係をもとに打ち明けてくれた話
それ以外は、できるだけ共有し、判断材料を揃える。私はそれを心がけてきました。
私がこれを強く意識するようになったのは、情報共有がうまく回らない状況を見た経験があったからです。
情報が十分に共有されないと、メンバーは「何が起きているのかわからない」不安を抱きやすくなります。一方で、リーダー側も「情報が上がってこない」と感じる。そうして互いに様子を見るようになり、気づけば悪循環になりかける。だからこそ、自分のチームが同じ状況に陥らないようにしたいと思いました。
そこで私は、まず自分から情報を出すことを徹底しました。
マネジメントレイヤーが何を考えて、どう動いているのかを遅延なく伝える。
自分の失敗も隠さずさらけ出し、振り返った結果を共有する。そしてそこで終わりにせず、みんなの意見を求めてさらに磨きをかける。
悪いニュースでも報告してくれたら感謝する。責めるのではなく、一緒にネクストアクションを考えて動く。
このやり取りを繰り返すことで、「言っても大丈夫」「言ったほうが前に進む」という空気ができ、結果として、自分がギバー (giver) を続けていれば、周囲もギバーとなり、自然と必要な情報が集まってくる状態を作れました。
実際、悪いニュースほど早い段階で共有されるようになり、解決に向けたネクストアクションを、より早く打てるようになりました。また、大小問わず good job を見つけて取り上げて褒めることで、改善案やその結果の共有が増え、メンバー同士が協力し合う度合いも高まりました。失敗の共有を恐れなくなったとも感じています。
メンバーの行動や成果で気づいた良い点は、朝会などで取り上げて共有するようにもしていました。
(参考:レビューでも気づいた良い点はほめるようにしています)
レビューでほめて後輩を育てる - ぱと隊長日誌
さらに、情報をオープンにする姿勢は、チームの中だけではなく、チーム外のステークホルダーやユーザーに対しても同様にしました。
日頃の信頼関係という前提があったとはいえ、オープンにすることで、システム担当者だけでは解決が難しい課題に対して、協力を申し出てもらえる場面がありました。ユーザー側の業務を変えたり、負担が増えるような話でも、不平不満を言わず受け入れてくれました。時には、こちらから言い出す前に提案してくれたことすらありました。
3. ビジネスをシステムで支える
私たちシステムエンジニアは、システムのプロです。だからこそ、システムの観点で何が適切かを見極める力が重要だと考えています。
ここで言いたいのは「とにかくシステムを作れ」ではありません。システムは手段であり、目的はビジネスの価値(売上・顧客体験・リスク低減・業務継続など)を守り、伸ばすことです。
つまり、プロとして求められるのは「作れること」だけでなく、
- そもそもシステム化が最適か(運用・ルール・教育で満たせないか)
- どの品質を優先するか(早さ、正確さ、保守性、コスト)
- 誰が困っていて、何がボトルネックか
を見極め、必要な手段を選び取ることだと思っています。
4. 意見の違いを認めて前へ進む (agree to disagree)
ステークホルダーやメンバーと議論すれば、信念や前提の違いでぶつかることがあります。そのとき大事なのは「勝つこと」ではなく、組織全体として何が最適かを探し、必要なら落としどころを作って前に進めることです。
私はこれを、自分への“おまじない”として「agree to disagree」と呼んでいました(厳密な英語の用法とは違うかもしれません)。
たとえば、アーキテクチャや手法の選定は、定量的に比較できれば理想ですが、必ずしもそうはなりません。各自の経験やプライドで固執が生まれることもある。それでも、どちらかに決めなければ課題解決は進みません。
また、チーム間で対立が起きることもあります。各チームには抱えている業務や背景があり、安易に承諾できない事情がある。けれど、ビジネスの価値を高めたいという点では一致していることが多い。
だから私は、議論が熱くなったときほど、まずこう問い直していました。
「我々が目指していることは何か?」
ここで主語を「我々」にするのがポイントです。
そのうえで、次の順番を意識していました。
- 双方の意見が対立している点と、合意できている点(ゴール)を切り分ける
- 合意できている点(ゴール)を中心に議論する
- 双方が納得できる着地点を見出す
そして、着地点を作ったあとは態度を決める必要があります。
もし自分の方針に寄せたなら、成功したら互いの成功として喜ぶ。失敗したら素直に認め、繰り返さないための振り返りを実施する。
もし相手の方針に寄せたなら、成功したら素直に称賛する。仮に失敗しても相手だけを批判せず、自分も責任を共有する。
いずれであっても、最後までやり抜く覚悟を持つこと。そうやって初めて、「合意」は前へ進む力になります。
信念は絶対ではありません。竹のように、しなやかさが必要な場面もあります。そして、たとえ譲歩することがあっても、それは前に進むための建設的な折り合いであり、「信念を捨てること」とは別物だと私は考えています。
おわりに
ここに書いた信念は、私のものです。誰かにそのまま当てはめたいわけではありません。ただ、迷う局面で立ち戻る「信念(軸)」があると、判断の速度も、折れにくさも変わります。
そしてその信念は、一度作って終わりではありません。経験を通して発見し、言葉にし、更新していく。
これから先、環境も技術もさらに変わっていくはずです。だからこそ「やり方」をアップデートしつつ、「何を大事にするか」は手放さないでほしい。そんな気持ちでまとめました。