TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

2022年の振り返り

これは何

一年に一回くらい振り返りしないともう忘れてしまうのでブログに残します。
個人の振り返りです。とりあえずTwitterの自分の投稿を見返してきました。2022年の合計ツイート数が20ツイートくらいだったので流石に放置しすぎている。
(振り返れるツイートは何もなかった)

引き続きプロダクトマネージャーで働いている

この一年もプロダクトマネージャーとして働きました。役割は変わっていませんが、この一年は特に「課題の解決をどう実現するか」にフォーカスして仕事をしていたと思います。
自分の担当領域は社内向けの機能や負荷軽減を目的とした機能の要件定義をやっていました。解決する課題が明確になっていることが多く、ゴールは明確ですが顧客に影響を与えない形でどう実現するかや何をどこまで実現するかを考えて要件に落とし込むことに重点をおいていました。
その中で、PdMに求められる期待値についても悩むことがあり、特に技術面についてどこまで関わるかの線引きが人によってばらけるところで、自分はどうすれば良いかで迷ってしまうことが多々ありました。ただ、結局のところ一緒に仕事をするチームやプロジェクトで話し合って合意を得るしか解決できないとも思うようになったので、わからないことを聞くという当たり前のことをやるようにしています。

目標はどうだった?

PdMのスキルを言語化して自分のスキルとすることを目標としていましたが、自分がどのようなスキルを持っているかを言語化することはできていません。
目標の達成もそうですが、仕事を通して弱みが多く見えた一年でした。

自分の弱みが言語化された

自分の評価や期待値をチームメンバーに質問して、得意なことや苦手なこと、身につけてほしいスキルをヒアリングする中で弱い部分が言語化されました。仕事においても弱みによって時間をかけてしまうことや他メンバーに頼ってしまうことがありました。その中で特に弱いスキルが「物事の分解と構造化」です。

物事を分解し、構造化して整理する

起きた事象や問題に対して、要素に分解して構造化し並べる作業が特に苦手なことがわかりました。特に問題を大きな粒度で解決しようとして、何をどうすれば良いかわからないと陥りがちになることが多かったです。
前からMECEに分解することが苦手だとは思っていたのですが、あくまでマーケティングでのMECEが苦手だと思っていたのが、どのような事象や問題に対しても苦手で出来ていなかったです。
今何が起きていて、誰がどういうことで困っていて、困っていることを解決するためにはどのような手段があって・・ということを考えるためには、今何が起きているかをまず整理する必要があり、整理するために分解と構造化を行う必要があると考えています。PdMが顧客の課題を解決するために何が必要かを考えるために、分解と構造化のスキルは必要だと考えているため、今はこのスキルを得るために本を読んでいます。

PdMとして働いて考えたこと: PdMは担当する機能によって求められるスキルが違う

PdMが機能の要件定義を作成するとき、誰のどのような課題を解決するためにその機能を作る必要があるのかということを考えると思うのですが
その機能が「顧客の課題を解決するためか」と「技術の課題を解決するためか」によって、PdMに求められるスキルは違って、両方に対応できるPdMはそんなにいないのではと考えるようになりました。 ただ、なんとなく課題を解決するための手段や技術の理解というようなふんわりとしたスキルの言語化はあるものの、説明できるほど言語化はできていないです。
自分はまだどちらもできているとは言えないですし、どちらをできるようになりたいかも考えが固まっていませんが、方針が固まった時には必要なスキルを身につけようと思います。

フルリモートを継続しているが出張にも行った

2022年も一年間フルリモートで働きました。最近はお昼ご飯に悩むことが多く、単純に近所に飽きてしまったということもあるので出社も少し恋しくはなってます。
ただ、2022年は初めて会社に出社しました。対面であって仕事をすることに価値も感じています。やはりオンラインとオフラインは切り替えできる方が良いなと思っています。
ないものねだりしても仕方がないので、2023年もフルリモートでやっていくつもりです。大阪にいます。

2023年はどうする?

まずは「物事の分解と構造化」スキルを身につけ、PdMとして価値を発揮できるよう頑張ります。
PdMという役割で頑張るのもそうなのですが、「自分はproblem solverです」と言えるようになりたいので、問題解決能力を身につけれるよう勉強していきます。

約一年の振り返り

振り返り

転職して一年が経ったこともあり、この一年でやってきたことを振り返ってブログに残します。
もう三ヶ月に一回もブログ書かなくなっちゃったので、せめて年に一回くらいは書かないとねと思って、34歳になったこのタイミングで振り返り記事を名目に書きたいと思います。
この記事を書くためにTwitterの自分の投稿を見返してました。2021年の年始はClubhouseの話題で、全然使わなくなったな。

プロダクトマネージャーをやっている

プロダクトマネージャーチームに加入し、プロダクトマネージャーとして一年間働きました。これまでSIerで要件定義の担当や自称プロダクトマネージャーを名乗っていたことはありましたが、会社から役割を与えられてプロダクトマネージャーをやるのは自分のキャリアで初めてのことで、毎日新しいことを学びながら働いています。
新規機能開発や既存機能の調整、内部仕様の変更などなどプロダクトの開発を進める中で、価値を探して要件をまとめることや、ステークホルダーとの調整を行うことを日々やっています。プロダクトのことを知るためにわからない依頼も積極的にやっていて、知らないことを知るために調べた情報をまとめたりとドキュメントに残すこともやっています。
プロダクトマネジメントの本を読んだり、pmconfに参加するなど、プロダクトマネージャーとしてのインプットも色々とやってきていて、過去勉強会をやっていたようなアウトプットはほぼ出せずの状態です。
ヒアリングの進め方とかで過去の知見が活かされることもありますが、ユーザーストーリーマッピングがいつまでもできる気がしないので、まだまだ学ぶことは多いです。

プロダクトマネージャーについての自分なりの解

プロダクトマネージャーは会社やその時の状況によって任されることが違うと思っていて、今やっていることが他でも通用するかはわからないです。その中で、自分が考えるプロダクトマネージャーとは「決めるための材料を揃えること」だと考えています。
プロダクトの価値を見つけることや顧客にヒアリングすること、作るものをエンジニアと調整して進めることなどプロダクトマネージャーのやることはたくさんの記事や本で見てきたが、いずれも大事だと思うものの、プロダクト開発を進めるためには要所要所で決める必要があると思っていて、その決めるために必要な情報やステークホルダーとの合意を用意し、決める場に持っていくことが最も重要であると思います。
決める場については、決める人がいるならその人に材料を渡して決めてもらえば良いし、いなければ自分を含む誰かが決めれば良い。決めることはさして重要ではなく、決められないなら決めるための情報がないということでしかないと考えています。
今年一年は、この考え方を元にプロダクトマネージャーをやっていきたい。

自分は 0 -> 1 はあまり得意ではない

これはプログラムを書くときもそうだったのですが、何もない状態からプログラムを書き始めることや、資料を作って展開していくことがすごく苦手で、すぐに手が止まることにここ一年で気づきました。
人が書いているものや過去の自分が作ったものをコピーしてからでないと、うまく始めることができず、最近は毎回必ずコピーするところからやるようにしています。Miroとかまっさらな状態から何も作れない。
プライベートで新規事業の相談に乗ったときも、当たり障りのないアドバイスくらいしかできなかった。
自分の弱みを伸ばすか諦めるかはまだ考えていないですが、そういう思考であることは知っておこうと思います。

プログラムはほぼ書かなくなった

この一年でプログラムを書いたのは数えるくらいで、プライベートでも書く時間は確保できなくなったこともあって全然やれていません。
キャッチアップもやれていないので、またエンジニアに戻るためには時間がないと難しそうです。
もともとプログラムは手段と割り切っていたこともあって後悔はないですが、プログラムを書くのは楽しいので何らかの形でやり続けたいです。ただ、今の調子だと時間は取れないので、どうしたもんかという感じであやふやになってます。

二人目の子供が産まれた

2021年の7月に妻が女の子を出産してくれました。産まれてからは元気に毎日過ごしてくれています。
時間に融通のきく働き方をさせてもらっているので、上の子の保育園の送迎のどちらかを自分がやったり、お風呂の時は中抜けして面倒を見ることができるので会社には感謝しています。
一人目の時はリモートでもなかったのと、東京への出張も結構行っていたこともあって、ずっと家にいることで育児で何をやっているのかが見えることで、改めて育児の大変さを感じています。
コロナ禍ではありますが、実家に帰る頻度も増えました。半分くらいは育児を助けてもらうためでもあるのですが、自分は男三兄弟なので家族にとっても初めての女の子ということもあり親孝行になっているのかなと思います。

今でも余裕はない

産まれて2ヶ月ぐらいで上の子がイヤイヤ期になり何をするにも大変になりました。とにかく些細なことで機嫌が悪くなる。
これは一人では面倒が見切れないということで仕事しながらも片方ずつの世話をすることも増えました。そうすると仕事と育児で一日が終わってしまうこともしばしばあり、趣味の時間も減ったりとなかなかしんどいと思ってしまうようなことが続きました。
今は多少マシになりましたが、それでももう数年はやりたいことより子供が優先になるんだろうなと感じています。限られた時間でやれることというのを考えながら生きる必要があるなと思ってます。

フルリモートで1年間働いた

出産とコロナでタイミングが合わず、結果的に一年間一度も出社せずに働きました。自分は出社して働くタイプだと思っていたので、正直できるとは思っていなかったです。
夏くらいにちゃんと環境を整えたのもよかったと思います。揃える前はローテーブルで仕事をしていたので、地べたに座っての勤務は現実味がありませんでした。

こだわり始めると新しいものが欲しくなり、今はカメラとマイクを専用のものを用意したい欲とあったところでそんなに変わらない自制心で迷いながら仕事をしています。

今年はどうする?

まだ今年の目標を決めていないものの、上で書いたようなプロダクトマネージャーのスキルを言語化し自分のスキルにすることをやっていきたいと思います。
プロダクトマネージャーとしての実績と、自分のスキルを説明できるようになれば、自分のやれることができると思います。
この記事を見返して、ちゃんと目指す方向に進めているかを確認しつつ2022年もやっていきでやっていきます。

転職しました

表題の通りです。 一つの節目として、これまでやってきたことをまとめます。

From -> To

From: ウェブリオ株式会社(2015/11〜2021/01)
To: Repro株式会社

ウェブリオでやったこと

エンジニアとして入社しましたが、約5年の間で結果的に多くのことを経験させていただきました。

Node.js, Perl, Java, Swiftを使った開発

Webエンジニアとして入社しましたが、PHPしかできなかった自分でも多くの言語の読み書きができるようになりました。
特にNode.jsは、エンジニアの中だけで技術選定から開発・運用まで経験させていただき、そこからNode.jsに深く関わるようになって、関西Node学園のOrganizarまでやるようになったことは、人生の大きな影響の一つです。またオフラインで勉強会できるようになりたいね。。

開発チームの窓口となって、要件/仕様の調整

エンジニアサイド <-> ビジネスサイドの間に入り、ヒアリングから要件をまとめ開発チームに持ち帰って設計という、機能開発一連でマネジメントしてました。
当時のウェブリオの開発は、営業やマーケターの要望が開発者個人に依頼しており、誰が何を開発しているのかわからないという問題がありました。
そのため、情報を可視化するため窓口を一本化し、開発できるレベルに要件をまとめ開発チーム宛に展開するやり方に変えていきました。タスクやドキュメントの管理場所が変わっていったり、ヒアリングの際にエンジニアに同席してもらって業務知識を得てもらうなどやり方は今でも色々試していっているため、完成させたわけではありませんがその時の最適なやり方を作れたのではと考えています。

コードを管理し続ける経験

前職は受託開発だったため、テストコードを書いたことがなかったりレビューする文化がなかったりしたのですが、自社開発でコードを管理する経験を得ることができました。
特に、可読性・保守性の悪いコードを書いて、その皺寄せが帰ってきた時には、リーダブルコードの重要性を思い知らされました。
リーダブルコードも今では新人エンジニアに必ず勧める本になっています。またこの時に、今の自分が書くコードは、過去の別人が書いたコードだから記憶に頼らないコードを書くということを考えるようになりました。

開発チームのリーダー

2018年の夏から約2年半、開発チームのリーダーポジションを担当させていただきました。元々開発リーダーがいなかったこともあって、自分なりにリーダーとは何をする人か勉強しながらやっていました。
自分が他社のCTOポジションの人と交流がないため、聞いたことや勉強会で質問させてもらったことを元に、何が正解かをずっと考えていたと思います。
CTOやVPoEと呼ばれるポジションとは違って、役割に縛られず開発チームのためになることならなんでもやっていたと思います。

給与レイヤーと評価制度の作成

リーダーをやる上で、一番やりたかったことをやらせてもらいました。目的はエンジニアの評価の透明化と採用をしやすくすることでした。
社内では給与への不満と評価の不透明さを聞くことが多く、採用では応募はあり面接して内定まで進めても、条件面談で折り合いがつかないことも多く、今のエンジニアの市場にマッチしていない課題感がありました。そのため、エンジニアを別の給与テーブルで管理し、何をどこまでできるかでレイヤーを策定する制度を作りました。
チームメンバーへヒアリングして経営会議に稟議書を出して、説明して承認してもらう経験も初めてでした。会社の制度を変えるために必要な動きを経験することができました。

組閣

開発メンバー一人一人と対話する時間を設け、どんな技術に興味を持っているかやどういうものを開発していきたいかをヒアリングしつつ、プロダクトごとに開発チームを配置することをしました。
チームの人数をバランスで決めるのではなく、どうプロダクトを成長させるか、その際に最も適切なメンバーは誰かを限られた人数で調整しチームにアサインしていきました。(慢性的に人は足りませんでしたが。。)
チームに対して、人が抜けたから採用するのではなく、必要なメンバー要件を言語化してその要件を満たせる人材を探すという考え方もこの時に得られたと思います。

考課

メンバーの昇給を決める会議に参加し、メンバー全員の評価に責任を持つ立場を担当しました。このため、期末は大体憂鬱でした。
メンバーの成果を説明する必要があり、そのためには成果を可視化する必要があり、それが苦手なメンバーも多かったため、それに対するサポートも多くやりました。
面談の中で話を聞いていると、本人は成果と思っていないものの他の人が聞いたら成果と言えるものが大体の人は持っており、ヒアリングで引き出してあげる必要性や手段についても経験し学ぶことができたと思います。

採用

新しく開発者を採用するための一連の流れを担当しました。必要な人材の要件出しから、募集要項の作成、採用課題の採点、面接、条件面談とほぼ全て担当していました。
最初はただエンジニアであればと考えていましたが、試行錯誤する中で組閣と同じように全員が同じではないということに気づきアップデートしていきました。
あまり成功体験は持っていないのですが、多くのエンジニアと話をする中で多くの価値観に触れて、影響を受けたこともあったため、自分の成長はあったと思います。
「How Google Works」という本には、「採用は最も重要な仕事」という章があり、採用に関わることは大きな成長が見込めることであり、全ての社員は採用に関わるべきということの説明が書いてあるため、これもいろんな人にお勧めしてます。今後も採用には関わり続けたいと考えています。

できなかったこと

チャレンジしながら、結果的に力不足でできなかったこともあります。

マネジメントと両立したリード開発

リーダーになってから、一番影響を受けた資料が伊藤直也さんの問題から目を背けず取り組むです。元々は「ELASTIC LEADER SHIP」の伊藤直也さんの章で知りました。
どれだけ良い環境を作っても、それで問題が解決するわけではないという観点はとても影響を受けました。
ただ、特にコードにおいて問題点を自分で解決することは、開発リーダーになってからほぼできなかったことです。
コードを書く時間も確保して書いてはいましたが、リソース不足で機能開発をすることが多く、結果的に問題解決がそこまでできなかったことは力不足だったと感じた部分です。

チーム開発におけるメンバーへの成功体験の提供

自分がエンジニアとしてチームメンバーだったときは、機能開発やリプレイスなどでリリースしてからの成功や失敗も含めて体験することができました。
ただ、その経験をマネージャーとしてメンバーに還元できたかというと、それはできませんでした。
プロダクト開発の現場で一緒に開発することができなかったこともあって、会社の資産を有効活用できなかったという点でできなかったことの一つです。

学んだこと(考え方が変わったこと)

入社する前と今まででたくさんのことについて知ることができました。成長を感じられたと思います。

Team Geekはチームでやっていくためのバイブル

最初に見たのはどこだったか忘れましたが、今では自分が最初にお勧めする本です。リーダーとなった時にも改めて読み返しました。
チームで開発をしていくために重要なことや取り組む心構えについて書かれている本で、メンバー全員に読んで欲しい本だと思っています。
HRTの精神は開発チームのバリューにそっくりそのまま入れています。

自分が働くことの価値提供について考える

働くことにおいて、以下のことを考えるようになりました。

  • 自分はなぜこの会社で働いているのか
  • この会社で働くことで、自分に良い影響/学びはあるのか
  • 自分がこの会社にいることで、会社にどのような良い影響を与えられているか

ある人から教えてもらった「会社と社員はWin-Winであるべき」という考え方を自分も真似するようにしています。自分だけが得をしてもダメだし、会社が搾取している状況もNGだと考えています。
働いていて、やりたくないことや自分の成長が感じられないのであれば、その会社に固執する必要はないし、自分が働いていて会社のためにならないのであれば会社のためになるようにするためにどうすれば良いか考えて、お互いにメリットがあるようにすることを常に考えています。

自分はチームを作っていくことをやりたい

自分が一番モチベーションを持てるのは、目標のために、必要かつ最短距離で達成できるチームを作ることで、そのために自分ができることを全てやっている時だとわかりました。
ウェブリオでの経験で言うと、開発チームのリーダーを打診されて、開発チームを現状から打破するときが一番がむしゃらに働き勉強していたと思います。
そのために必要なことはなんでもやってきましたし、なんでもやることは全く苦ではありませんでした。
特にエンジニアという肩書きにこだわることもありませんでした。もちろん開発もしていたいですが、それが目標達成において最も必要かということが先に来るようになっています。
なので、これからの仕事探しは、現時点では基本的に上記のことを考えてやっていきたいと考えています。

まとめ

ここの話は全て職務経歴書にもまとめます。
上記の内容は、まだウェブリオでしか経験していないためN=1でしかありません。他社で同じことをやろうとしても上手くいかない可能性があります。
それでも、これまでやってきた経験を他社でも成果として出せれば、自信になると思っているので、どうにか自分の力に変えていきたいです。
最後に、多くの経験をさせていただいたウェブリオには感謝しかありません。入社して良かったです。
稚拙な文章ですが、ここまで読んでいただきありがとうございました。転職した理由などは今のところ書く予定はないので、Twitter等で質問してください。

「ピーターの法則」読んだ

ピーターの法則」という本を読んだ。法則の名前と法則の説明くらいしか知らなかったが、会社に本があったのと、自分も無能であるのかもとずっと感じつつあったので 一度本を読んでみることにした。

「階層社会では、すべての人は昇進を重ね、おのおのの無能レベルに到達する。」

例外のない法則

ピーターの法則に、例外はない。全ての個人にとって、最後の昇進は有能レベルから無能レベルになる。
もし、十分に時間があり、そして組織に十分な階層があるなら、全ての個人は、その人なりの無能レベルまで昇進し、その後はそこに留まり続けることになる。
じゃあ仕事をしているのは誰かというと、まだ無能レベルにまで到達していない人たちによって行われる。

今日、階層社会に例外はない

社会では、身分・等級・階級に従って構成されているので、ほぼ全ての人が階層社会に生きていると言える。
一会社という観点で見れば階層のないところはあるのかもしれない。だが、大学のヒエラルキーなど、社会という観点で見れば階層は生まれ、ピーターの法則は例外ではなくなる。

引きの昇進、押しの昇進

昇進の方法には、上司から引き上げられての昇進と、自分を高めての押しの昇進とある。
引きの昇進は、パトロンを見つけると良い。自分を引き上げてくれる上司に、引き上げる動機を与えてやれば、自然と昇進する。上司が引き上げられる限界を迎えれば、そのパトロンからは離れるべき。複数のパトロンを見つけ、引き上げられる確率を高める。
押しの昇進は、自分を高めることで成就できるが、引きよりも力は弱い上、押しの昇進でも昇進の最終到達点は変わらない。引きの昇進が期待できるならそちらの方が良い。

創造的無能のすすめ

無能にならないためにやることは、昇進を断ることではない。昇進を断った時点で、周りの人間を不幸にし、結果的に無能と判断される可能性がある。
無能にならないためにやることは、昇進を拒否するのではなく、初めから昇進の話を持ちかけられないようにし、有能のまま留まることである。これを創造的無能と呼ぶ。変人ぶりを発揮したり、一匹狼であったり、外見を演出するなど。
有能レベルに留まり、有益な仕事を成し遂げることが、成し遂げた人にしかわからない満足感を得ることが出来、それが幸せに繋がる。

読んでどう思ったか

これほど、辛い思いをしながら解決策を知るために先にどんどん進もうと思う本は初めてだと思う。
自分の気持ちとしてはこの法則を否定したいのだけど、今の社会をみている限り今のところは否定できず認めざるを得ないと感じている。
自分が有能レベルに留まっているかは「この人は有益な仕事を成し遂げつつあるか」の回答で判定できるので、社会に価値提供できているかで考え、価値のある仕事をし続けるしかないのかなと思った。

同時に、会社において、社員が有能か無能かを決定するのは、外部の人間ではなく、その組織の内部にいる上司とある。これは、仕事内容や上司によって、有能と判定される場所はあるかもしれないということになると思う。活躍できていないことは環境によるものという可能性もあるし、無能だと思われているのは今の上司だけの可能性もある。一つの色眼鏡で全てを決めるのではなく、外を見てやっていこうと思う。

ピーターの〇〇

本を読んでいるとこれが異様に多い。大体覚えていないけど、研究の中で明らかになった事象がすべて書かれている。以下抽出

  • ピーターの愛着
  • ピーターの悪循環
  • ピーターの頭打ち
  • ピーターの急がば回れ
  • ピーターの痛み止め
  • ピーターの受け流し
  • ピーターの逆説
  • ピーターの気休め薬
  • ピーターの結末予知
  • ピーターの処方薬
  • ピーターの特効薬
  • ピーターの難所
  • ピーターの微差
  • ピーターの必然
  • ピーターのふるい落とし
  • ピーターの本末転倒
  • ピーターの予防薬

まとめ

この本を読んで救われたとは思いづらいけど、覆すではなく、受け入れた上で自分が生きていける人生を進んでいきたいと思った。
この本を読んだことも、どこかで生かせれば無駄ではないし無駄にならないようにしたい。

マネージャーになったら身に付けたいファシリテーションスキル

この記事は、Engineering Manager vol.2 Advent Calendar 2019 2日目の記事です。

この記事は、エンジニアのマネージャーになって1年ほど経験した私が、マネージャーに必要なスキルの中から今自分が一番足りていないと思うファシリテーションについて書きます。
まだまだ若輩者のため、この記事へのご指摘はいつでもお待ちしております。

ファシリテーションとは

会議において、段取り・進行など会議を円滑に進めることや、参加者の意見の促進など相手の内面を引き出すことです。
MTGにおける司会者のような役割で、その役割を担当する人のことをファシリテーターと呼びます。
おそらくビジネス用語だと思うのですが、私は最初に聞いた時は全くわかりませんでした。(近くの同僚から聞いた)

なぜ必要か

マネージャーに就任して、当たり前ですがエンジニア内外関わらず人と関わる機会が多くなりました。
その中で、人とのやりとりでリードする立場を期待されることが多くなり、相手とのやりとりの中で最適解を見つけていくためには効果的なファシリテーションが必要だと感じるようになりました。
ファシリテーションスキルがあれば、MTGでも1on1でもディスカッションでもより早くゴールに進めることができます。

ファシリテーションスキルとは

ファシリテートとは「容易にする・楽にする・促進する」という意味です。

ejje.weblio.jp

そして、この言葉は「人は主語にならない」となってます。つまり、モノやコトに対して容易にする・促進するということです。

つまり、ファシリテートするとはただ司会の立場で場を回すのではなく、相手に対して「何か」を促進することです。「何か」というのは、その場によります。
イデア出しのMTGであればアイデアを出させること、目標を設定するのであればその人の内面を引き出してあげること、といったように、です。
前置きが長くなりましたが、ここからファシリテーションのスキルについて書いていきます。

ファシリテーションを意識する

スキルかと言われれば微妙かもしれませんが、一番重要なのは意識することだと思います。
ファシリテーションMTGの場で必要というのは自明ですが、1on1も席での会話も、広義で言えばMTGです。
その時、ただ会話するのではなくファシリテートを意識することで、普段の会話が1段階レベルアップすると思います。ましてや、マネージャーになったからにはあらゆることの調整をする必要があり、
そのための普段のコミュニケーションはとても重要で、どこにでも情報は転がっています。
それらの情報を見逃すことなく拾い上げていくことは、マネージャーにとって重要なスキルだと考えています。

知識を共有する・要約する・噛み砕く

主に相手から意見を出してもらいたい時、意見が出てこないのは質問の投げ方の問題かもしれません。
何より、相手は自分に何を求められているのか、理解していない可能性もあります。
なので、ファシリテートする際には、まず前提をお互いが理解しているかを確認し、もし前提が違う場合は相手に求めている情報を要約し、理解するまで伝えてあげることが大事です。

いきなり意見を求められて、自由に発言できるのは体感でおよそ1割程度です。
残りの9割の人たちは、正解がわかるまで話をしようとはしません。なので、正解があるものを出してあげる必要があり、そのために正解があるというように相手に要約して伝えてあげると、相手もその正解に沿った回答を出してくれて、その後のMTGがスムーズに進む傾向があります。

言われたことの意見を受け止める

相手が言ってくれた意見が、自分の意図したものではなかった場合でも、相手は何かしら自分の考えを持ってその発言をしているはずです。
ただ頭ごなしに否定するのではなく、自分の中に一度落とし込んで、その意見を話した意図を考えることで新しい発見があるかもしれません。
もしかしたら、間違っているのは自分で相手の発言の方が正しいかもしれません。受け止めたことで次の展開が良いものになる可能性は、常に意識する方が良いと思います。

最後に

自分もまだまだできていないですが重要だと思うことを書きました。
マネジメント系のAdventCalendar初参戦なんですが、こんな記事で良いのか不安ですが誰かの参考になれば幸いです。
他にもこういう点もスキルだというものがあればぜひ教えてください。

「ゆとりの法則」読んだ

ブログには書いていないけど、以前にピープルウェアを読んでいて、ピープルウェアとセットだと認識していたので読んでみた。

ピープルウェアが組織の中で仕事をするための本だったのに対して、こちらはプロジェクトを進める手法が書かれた本である
なぜゆとりを持つことが必要なのかと、ゆとりを持たないことで何が起きるのかが書かれている、いわば注意喚起のような本でいくつか印象に残ったところをあげる

本当に早く仕事をするには

この章では仕事を早く終わらせるための間違った方法を解説する

ゾンビ

仕事に執着しやがて燃え尽きてしまった社員のことをゾンビと総称し、ストレスのかかるプロジェクトを見渡すとゾンビになっている人が多いことに気がつく。
ゾンビとなった社員は辞めることが多いが、組織に残り続ける人もいて、そういう人が増えることでプロジェクトは停滞し続けてしまう。
この現象は心当たりがあるがこの見方をしたことがなく、ゆとりを表すバロメーターになるものだと思った。

人員過剰のパラドックス

人手が足りないことはチームのストレスの原因になるが、かといって間に合わない納期に人員を追加して解決する問題でないが、往往にして管理者はそのことを理解しない。
さらに管理者は人手を増やしたことで達成できる挑戦状を叩きつけ、結果恐怖の文化が生まれる。

契約にもゆとりを持つ

ゆとりを持つことは問題が発生した時に対応できる余裕を持つことである。そしてそれはプロジェクトだけではなく、契約の場合も同様である。
二つの契約を並べた時、一方が安ければゆとりを削っている可能性があり、トラブルによって訴訟に発展する可能性がある。自分が売り手の時は容易に想像できるリスクを盛り込んでおく。

誤った目標管理

目標管理は二つの面で誤りである。

  • 目標管理はある状態が続くことを前提にしているが、物事は常に変化する。
  • 目標の指標は必ず単純化されたものであり、その値を最大値に近づけようとして結果的に企業の貢献度が下がることになる。(ディスファンクション)

変化と成長

全く変化できない人は成長もできない。これは自明だが、変化できないのに成長を求める組織を多く見る。この章では組織の変化と成長を実現するというテーマに目を向ける

リーダーシップとフォロワーシップ

意志を生み出すのがリーダーの仕事である。
リーダーは一部のエリートが担うものであり、それ以外の人はリーダーについていくべきというのは、リーダーシップではなくフォロワーシップを植えつけているだけである。
リーダーシップは全員の任務であり、名案を思いついた人に従うのも任務である。リーダーシップは交代制で担うものである。

変化は中間管理層から

変化がトップから起きるというのは間違いである。重要な変化には再生が伴う。企業の再生のためにはトップにはわからないような日常業務との深い関わりが必要である。
変化が底辺から起きるのも間違いである。底辺の人々は再生するための願望もなければ、再生計画を遂行するための力もない。

変化は中間管理層から起きるのである。
変化には再生のためのゆとりと、有意義な変化を計画し実現するための協力が必要である。

まとめ

リーダーシップとフォロワーシップの話が一番印象に残った。自分がリーダーシップだと思ってやっていたことはフォロワーシップだったかもしれないし、リーダーシップはチーム全員が持てるようフォローするのもリーダーの仕事だと認識した。
ゆとりを持つことを、自分の手の届く範囲で周りに伝染させていければと思える内容だったので書評を書いたとともに実践していく。

HARD THINGS読んだ

働くことについて別の視点をいれてみたいと思って読んだ。

HARD THINGS

HARD THINGS

この本は筆者が体験したことを元に、倒産する時が見えているときに何をしないといけなかったを解説してくれてる本で、
最初の3章で会社が倒産するところから売却するところまで実際に何があったか書いてある部分で、それ以降の章は会社で起きたことをよかったこと悪かったことを合わせて書かれているのが読めてよかったと思える部分だった。

必ず起きてしまうネガティブな事象に上手に取り組むための本

良い製品マネージャ、悪い製品マネージャ

この章で良いマネージャとは、悪いマネージャとはが多く書かれている。

良いマネージャは素晴らしい製品を最適な時期に出すために必要なこと全てに責任を持つ。
悪いマネージャは山ほど言い訳をする。

良いマネージャは「WHAT」を明確にし、「HOW」ではなく「WHAT」が実現するまでを管理する。
悪いマネージャは「HOW」を思いついたときに最高の気分に浸る。  

ここにあげた内容は一部だが、この章だけでも読む価値はあると思った。マネージャの良い悪いはわかりづらいと思っていたが、ここに書かれている内容だけでおおよそ見分けはつくのではないかと思う。

大企業の幹部が小さな会社で活躍できない理由

一例では、大企業の幹部は、メール・電話・ミーティングと基本的に待つ体になっている。部下からの報告を待つのである。ベンチャー企業で働くにはミスマッチが起きるからである。
この章で、どの企業でも合う合わないはあるのだと思った。ミスマッチの検出という章で「仕事に就いて最初の一ヶ月に何をしますか?」という質問で自分がどう回答するかはどこで働く場合でも考えるようにしたい。ここでは「勉強」を強調しすぎる人は要注意とある。おそらく何があるかわからないが前提にきているのかもしれないが、わからなくても動いて解決していけるタイプを目指したい。

正しい野心

幹部を採用するときは「正しい野心」を持つ人を採用する。人は世界を見るときに何らかのメガネで見ている。そのメガネが「自分メガネ」なのか「チームメガネ」なのかで、「正しい野心」を持つ人とは「チームメガネ」で見ている人のことである。
過去の経験を話すとき、「自分の職務経歴にプラスになった」というような話をしたとして、状況を自分の経験に結びつけてしか考えられない人は全ての事象を自分本位でしか考えていないことが垣間見える。過去の経験で「自分」を主張しない人はチームを第一に考えていることがわかる。
一般社員の場合は自分のキャリアパスの充実を考えても良いが、経営に携わる幹部の場合は動機が重要である。

最近は実績を積んで自分の話を増やしたいと考えていることが多かったが、そのときに自分がどう成長したかを今までなら話していたと思う。
確かに個人で何をやったかは今でも話すことはあるが、チームにどういう実績を残したかを話せる人は少ないと思うのでそういった話をできるような実績を残すことを意識したい。

まとめ

目標設定の章で「チームに実現不可能な目標を与えれば士気は下がる」とあったが、ここでも孫子が引用されていたことには驚いた。孫子を読んだから気づくことかもしれないが、多くの人が参考にしているのだと思えた。
最後にあった「苦闘を愛せ」という言葉がもっとも印象に残った。世界中の助言と知恵を集めても、困難は困難である。その困難に立ち向かうことこそが困難を解決する唯一の方法なのだと考えた。
辛いと思うことは多くあるが、その辛さを解決するのも自分だけなので、嘆くより動くことをやっていきたい。