こんにちわ、LITALICOのCTOをやっている@yuyaichihashiです。
この記事は『LITALICO Advent Calendar 2022』のカレンダー1最終日の記事です。
昨年にも増して様々な職種の人たちがバラエティに富んだ記事を書いていますので、ぜひ他の記事も覗いてみてくださいね！
はじめに
どういう記事か？
マネジメントについての書籍は良書がたくさんあり、具体的な手法や取り組みについて、今年の弊社のアドベントカレンダーでも良い記事を書いてくれているマネージャーが何人もいます。
そこで、具体的な手法ではなく、自分がマネジメントの仕事をする上での物事の考え方や、それにもとづいた姿勢や心構えについて、言語化してみました。
そういった内容ですので、多分に個人的な見方や解釈を含んでおり、間違っても何かの正解のようなものではなく、読まれた方々が自分なりの考えを深めるヒントになることがありやなしや、といったものであることをご了承ください。
ちなみに、自分でも、これから書くことを完璧に実践できているかというと、そんなことはありません。
(できています、なんて言ったら、LITALICOのみんなに総つっこみをもらいます。こういう心がけでいるんだなと、優しい眼差しで見守ってください笑)
注意事項
直接スタッフを部下に持つ1チームのマネージャーから、複数チームを束ねるマネージャー、さらに複数の部署を束ねるマネージャーなど、様々なレイヤーのマネジメントを役割とする人を総称してマネージャーとして扱います。
自分自身は、1チームのマネージャーであった時期はもう10年以上前ですので、視点は上位レイヤーに偏っていると思いますが、どのレイヤーのマネージャーでもヒントになる部分はあるのではないかと思って書いています。
また、網羅性は考慮せず、重要度が高いものからピックアップ、などもしていないため、また別の機会に色々と後出しするかもしれません。
構成
どうも書いていると、マネージャーに限ったことではないものも多々あるため、厳密に分類しづらいものもありますが、2つの記事に分割しました。
標準装備編は、マネージャーではない方も参考になることがあるかもしれません。
- マネジメントのアティチュード (標準装備編)
- マネジメントのアティチュード (マネージャー用アタッチメント編)
本記事は「標準装備編」です。
＊ 「マネージャー用アタッチメント編」はこちら
マネジメントのアティチュード (標準装備編)
コントローラブルかアンコントローラブルか意識する
常に、あらゆることについて、それが自分にとってコントロールできることなのか、コントロールできないことなのかを選り分けて、コントロールできることだけを思考するようにしています。
これには2つの効用があると考えています。
- コントロールできないことに心を砕き、無駄に思考リソース(有限ですし、疲弊します)を奪われたり、ストレスを受けない
- コントロールできることを使って、間接的にコントロールできないことも含めて望ましい結果に導くことができる
後者は、特に、取り組むものが大きく複雑になるほど、自分にコントロールできることは部分的になってくるので、重要さを増していくと考えています。
事実か推測か意識する
常に、情報は、それが事実なのか、推測なのか、事実だと考えられる根拠は何で、どれくらいの可能性なのか、脳内に流入してくる情報を、なるべくストリーム処理するように意識をしています。
これは、できるだけ精度高く判断したり、行動を決めるために大切だと考えています。
抽象と具体を反復横跳びする
抽象化は強い武器です。
抽象度を高めていくと、一見、別のものとしか思えないものでも、それまでの自分の知見や経験を応用して、自分にとって未知の知識分野でもある程度取りかかれたりします。
僕はエンジニアですので、システムを扱う上で培った知見を抽象化し、応用して、組織やビジネスや会計や法務やあれやこれやを理解し、今の仕事をできるようになっています。
一方、抽象化はとても危険な諸刃の剣だとも考えています。
抽象化とは捨てる行為としての側面があります。
本来あったものをどんどん捨てていくことで、あなたと私を同じ人間である、と言ってのけるのです。
でも、あなたはあなた、私は私、その違いはとても大切なことです。
抽象化という武器を使う時は、その過程で何を捨てたのかを、常に忘れないように意識しています。
同じ人間として扱うことで、得られるものは大きいですが、あなたをあなたたらしめるもの、私を私たらしめるものを忘れてはいけません。
いくつかのパターンに分類するなども抽象化の一つです。
パターンとパターンの間に無限のパターンが存在することを忘れないように意識しています。
ソフトウェアの設計をする上でもそうです。
設計も抽象化する行為の一つですが、常に具体(実際に発生し得る、あらゆる操作やデータなど)を考えるようにしています。
抽象と具体を行ったり来たり、交互に両方の視点で設計の確からしさを確認することが大切だと考えています。
目的と手段のチェーン
目的と手段を混同しない、というのはよく言われることですが、思っている以上に、気づけば罠にはまっていたりすることがあります。
そこで、そのつもりはないのに、気づけば手段を目的化してしまっていたり、なかなかそのことに気づけない時、僕は以下のように確認をしています。
- 目的と手段は独立した1つのペアではなく、もっと大きい目的から連なる、目的と手段のペアがチェーン状に連なるものだと考える (ある目的は上位の目的の手段、最上位はビジョン)
- 目の前にしている目的と手段の1ペアの目的が、上位のペアの目的に対して手段たり得るか確認する
と言うと大仰な言い方ですが、何でやるんだっけ？(目的の確認)に、それは何でだっけ？(上位の目的の確認)という質問を追加するくらいのことで、たいていは十分だと思います。
ただ、けっこう大きく複雑なことを扱っている時や、長期間議論を重ねてきて、おかしなルートに入ってしまっている時など、一旦、何段か上位に振ってから、チェーンを辿って下りてみるのが有効なことがあると考えています。
常に自分を疑う
自分というのは、よく間違えるものだと考えています。
0か1か明確なものや、作業手順を間違えたとか、この観点の考慮が設計で漏れていたとか、そういう間違いは気づきやすいし認めやすいですが、主観がゆえに間違いに気づきにくいものや、正しさがいくつもあるのに、自分の考えだけが正しいと思ってしまったりすることがあります。
(つまり、この記事に書いていることも、はたして…)
ですので、以下のようなことを常に意識するようにしています。
- 情報の理解が合っているか？
- 自分の考えや言動にどういう認知バイアスがかかっているか？ (かかっている前提です、脳の機能ですので。)
- その判断は正しいか？
- 相手に伝えたつもりになっているけど、本当に伝わっているのか？
- 相手の話を理解したつもりになっているけど、本当に理解できているのか？
- 誰かのことを理解しているつもりになっていないか？ (そんなおこがましいことはあり得ないですよね)
思考する、深く、広く、長く
思考する力は、技術スキルを習得するのより時間はかかるかもしれませんが、後天的に鍛えられるものだと考えています。
人によって、思考の癖というか、得意不得意はあるように思いますが、自分の得意不得意を理解したり、鍛えて伸ばすことはできると思います。
ちなみに僕は、(特に言語によって)記号化されたものを記号として記憶したり、記号を主/意味を副として記憶するのは不得意です。
意味を理解することは得意ですので、意味を理解した上で、意味を主/記号を副として記憶することで、ある程度、記号の記憶をカバーしています。(検索は記号をキーに引けますが)
瞬発的な思考も不得意です。
時間を使って思考を深める方が得意ですので、日頃の思考でストックされている中から反応するか、時間が取れるように持ち帰ったりします。
後から(ひっくり返すようなことにはあまりなりませんが)追加で回答することもあります。
いずれのタイプにしても、思考力を鍛えるには、日頃から、自発的に、ちょっとした壁で行き止まらずに、思考をし続けるという、地味で継続的な努力が、思考力を伸ばすと思います。
体を鍛えるのと同じだと思います。
日頃から思考する癖を付けるには、
- 見聞きしたものについて、そのまま受け止めず、なぜ？と好奇心を持ってみる
- 答えが無さそうなことについて、あれこれ考えてみる
- 楽しめないと定着しないので、自分が興味を持てることについて考える
などを意識してみると良いかなと思います。
慣れないうちは、一つのことについて、思考をどんどん広げたり深めたりするのは難しく、すぐ行き止まってしまったりすることもあると思いますが、そんな時は、
- 要素に分解する、相関/因果関係を探す、分類を考える、など構造化してみる
- ステップを刻んで1段2段となぜ？を深めてみる
- 抽象化の度合いを色々変えてみる
- 仮説を設定して先に進めてみる
- 要素を疑ってみる
- マクロに見たりミクロに見たり視点を変えてみる
- 条件や仮説を極端に振ってみる
- 全く別のもの、別のジャンルに照らしてみて、違う視点を得る
などなどの工夫をすると良いと思います。
また、思い切って、しばらく寝かせてみるのも良かったりします。
コールドスリープさせるのではなく、ちょっと傍に布団を敷いて寝かせておくイメージです。
生活の中で見聞きしたり考えたりしていることが、ふいに結びついてヒントになることがあったりします。
型は知るべきだが、そのままハマることはない
実装、設計、開発プロセスから、プロジェクトマネジメントやチームマネジメントなど、どんなものにも、方法論や技法、ベストプラクティスやアンチパターンなどの型があります。
当たり前ですが、先人たちの数多の経験や知恵の結集ですので、学び、常に参照し、活用すべきものだと思います。
ただ、それらは、ある程度の抽象化がなされたものですので、基本的に、今、自分の目の前にある状況にピタッとハマることはないと思っています。
たとえば、SQLのアンチパターンとか、コンピュータの処理に近いものは、考慮する前提条件も限定的でハマりやすいですが、設計のように前提条件や選択に影響する要素が多いものであったり、人や組織の営みである開発プロセスやマネジメントなどは、表面的に型をなぞってもハマらないことが多いと思います。
抽象化の項目でも触れましたが、抽象化の過程では、具体的な詳細が捨てられていきます。
先人たちの多数の経験や試行錯誤から、成果があった時の共通要素を抽出しているので、実際に、個々の経験でどういう状況であったのかという前提条件や、細部の行動や選択などは捨てられています。
ですので、当然、今、自分が目の前にしている状況を踏まえて、使う型を選択し、状況にあったカスタマイズをしないと、うまくはいかないと考えています。
そのためには、なぜその型はそういう型になっているのか、型が有効である前提条件としてどういう要素が考えられるのかなど、型を深く理解することと、今、自分の目の前にある状況を、適切に分析することが必要だと考えています。
ただ、理解を深めるためにも、そういう意識を持って、まずは真似てみるところから始めて、うまくいったりいかなかったりする経験を通じて、型の理解していくことができれば良いのだと思います。
神を細部に宿らせるには
神は細部に宿る、という言葉がありますね。
細部にまでこだわることで良いものを作れる、良い仕事ができるわけですが、一方で、近視眼的になって、細部にばかり目を奪われても、良いものや良い仕事はできないと考えています。
たとえば、UIデザインにしても、機能設計にしても、ユーザーはその画面や機能を使って何を実現したいのかなど、目的を明確に意識した上で細部をこだわることで、はじめて神は宿ってくれるのだと思います。
ベストではなく、ベターを積み重ねる
今の状況を作り出しているあらゆる要素、今の自分やチームにできる/できないあらゆること、ユーザーであれ同僚であれ、相手がいることであれば、相手が何を考えているのか/これから取る選択肢をどう受け止めるか、それらの中で取りうる無数の選択肢…。
ベストを目指そうと、どこまでも考えていると行動ができなくなってしまいます。
取り組んでいることによってバランスは違いますが、現実的な範囲で考え、よりベターだと思える選択をし、行動をする。
そうすることで物事が進み、状況が変化します。
そしてまた、ベターな選択/行動をし、という積み重ねが大切だと思います。
そもそも、ベストなんてものがあるのでしょうか？
これがベストだ！と思えても、きっとそれは幻想なのではないかと思います。
もちろん、多角的な観点でものごとを考え、評価し、選択や行動をすることは大切で、バランスの話だと思います。
全く考えないのは、ベストの前にベターですらありません。
また、少なくとも個人的には、この捉え方は気持ちも楽になるなぁと思います。
あの選択はベストだったのか？あの行動はベストだったのか？と考えると辛くなりますが、その状況の中でのベターな選択/行動と考えると、建設的に振り返り、先に進めることができています。
ルールは改善し続けるもの
法令であれ、会社のルールであれ、チーム内のルールであれ、完璧なルールというのは無いと思います。
ルールに不備を見つけたり、不都合を感じた時、ルールを無視したり破ったのでは、ルールの意味が失われるだけではなく、そのルールを共有する集団に、何の利益ももたらさないと思います。
ルールに課題を感じたら、ルールを破るのではなく、改善することを提案し、共に検討するべきだと考えています。
その時、そもそも、そのルールはどういった課題を解決したいから存在しているのかから考えると、良い改善案を考えやすいですし、自分がそのルールから外れてやろうとしていることの方に問題がある場合も気づきやすいと思います。
相手のことを想像しよう
同じチームで働く仲間、社内の様々なチームの人たち、様々な取引先、顧客やユーザー、採用の候補者などなど、関わる人たちは様々ですが、できるだけ相手のことを想像するように意識しています、相手の立場や環境も含めて。
子供の頃、よく、自分がもしその人だったらどう思うの？みたいな教えられ方をしましたが、これは間違いではないですが、足りないと思っています。
自分がやられて嫌なことは他人にもしない、というアンチパターンへの適用は、当たらずとも問題はほぼ発生しないので、有用だと思います。
ただ、自分がその人だったらどう思う？どう考える？という手法は、自分の考え方や感じ方(それも、今、自分が置かれている立場や環境での)を相手にまで拡張して、押し付けることでしかないのではないかと考えています。
本当に相手のことを考えるというのは、(本質的にはわかりようもないのですが)可能な限り、相手のことを想像するということだと思います。
そのヒントとしては、その人が今置かれてる状況や、環境や立場などにあるのではないかな、と思います。
- その人の職務に求められていることやチームのミッション、その人が今どういうチャレンジをしているか、社内キャリアの中のどういう状態にあるのか、etc
- その採用候補者の方が、何度も転職を経験しているのか初めてなのか、どういう転職の背景を持っているのか、急ぐのかじっくり時間を使いたいのか、転職活動が進むにつれての状況の変化、etc
- その取引先のビジネスモデルや市場環境やポジショニングがどうなのか、その人は取引先の中でどういう役割で、社内で何を求められているのか、etc
などなど、実際には、その時の相手の気持ちを想像したい目的によって、もっと細かく、多角的に、感情面に影響する要素含め、できるだけ想像してみるようにしています。
短期のベクトル、長期のベクトル
それぞれの職種やチームには、それぞれのミッションがあります。
ですので、短期的な時間単位で見ると、各々のベクトルは別々の方向を向いていて、利害が一致せず、時にはぶつかり合うこともあります。
でも、それは当たり前のことだと思います。
それぞれの専門性に応じたミッションがあり、どれも必要なものです。
けっして、その人が意地悪であったり、そのチームがプロダクトの成長の足を引っ張ろうとしているわけではありません。
プロダクトのビジョンや会社のビジョンといった長期的な時間単位で見れば、みんな同じ一点を向いたベクトルを持っているはずです。
そのことを意識してコラボレーションすることが大切だと考えています。
掻い摘んだ情報で批判しない
「何であのチームはこんな企画を考えたんだろう？」
「何であのチームはこんな仕組みにしたんだろう？」
もちろん、みんなでより良くするために意見を出すのは大切ですし、違う立場からだから気付けることもたくさんあると思います。
だからこそ、それがただの批判になってしまったらもったいないですし、お互い批判し合っていても、自分も相手も、ましてやユーザーにとっても、誰もうれしいことはないですよね。
ですので、以下の点を念頭において、自分の振る舞いに注意をしています。
- それに取り組んでいる人たちが、一番そのことについて多くの情報を集め、長時間考えを重ねている。自分はその事について、一側面だけ目にしたり、情報を聞き齧って、少し考えてみただけ。
- 自分たちのやっていることが一番解像度高くわかっており、相手のやっていることの解像度は低い。そのため、お互いに自分たちの都合についての方が、細かく多角的に素早くイメージできる。
- 自分たちが、常に不完全なところがあり、改善に取り組んでいるように、相手もまた同じ。チームメイトは応援し、他チームの人は批判するのはおかしい。
"今"にはそこに至る歴史がある
新しい会社に転職した時、新しいチームに異動した時など、何でこんなこともできていないんだろう、などと思ったことはありませんか？
また、それを、その会社やチームにいる人たちの能力や取り組む姿勢などに問題があると勘違いしたことはありませんか？
他人は愚かではありません。
なぜ今そうなのかには、それまでのいろんな歴史や状況の積み重ねがあります。
それを知る姿勢を持ち、ここまで会社や事業を成長させてきたことへのリスペクトを持ち、その上で、自分の経験やノウハウから、より良くできることを提案し、一緒に取り組むことが大切だと思います。
また、そもそも、自分のこれまでの経験でできあがった物差しでの判断が正しいとも限らないと思います。
ドメインや組織構造や様々なコンテクストであったり、会社やチームが大切にしていることなどを理解していくと、実はその方が理に適った状態なのかもしれない、少なくとも、自分があるべきだと思った状態よりメリットになる部分があるかもしれないということは意識しておく必要があると思います。
おわりに
いかがでしたでしょうか？
個人的な要素が強いので、読まれた方にとって、どこまで参考になるのかわかりませんが、何かのヒントになることがあれば幸いです。
繰り返しになりますが、自分がいつでもこの通りにできているわけではありません。
ただ、こういった自分なりの考えを持つこと自体が、大切なことではないかなと思います。
また、それも固定し切ってしまうのではなく、(自分の芯となるので安易にではないですが)常に新しい気づきを取り入れ、アップデートしていくことも大切だと思います。