どのようにしてマネージャーとしてのスキルを得てきたか

9246 ワード
チーム開発 マネジメント チーム開発 テキストリンク

この記事は、Pepabo Managers Advent Calendar 2016 の12日目の記事です。 11日目は、kwgcさんの「スニーカーについて」でした。

以下のような項目についてお話ができればと思います。

  • 現在の立場について
  • どのような経歴からマネージャー職になったか
  • 足りないと思ったスキル
    • 会計
    • 面接
    • コーチング
    • ファシリテーション
    • プロダクト開発
  • それをどのような手段で身につけてきたか
    • 本を読む
    • 計画 実践 問題の発見 改善 (PDCA)
    • 先輩マネージャーを見る
  • 問題だったプロセスや気付き
    • とにかく行うMTG
    • 共通認識・理解
  • どのように解決したか、改善したか
    • MTG
    • 目的を決め、意思決定者を決める
    • 共通認識・理解
    • 徹底的に話す
  • 新たに見つかった足りないスキル
  • 最近考えていること
  • 最後に

現在の立場について

プロダクトに関わるマネージャーです。現在担当しているプロダクトは写真や動画をオンライン上のアルバムでみんなと安心して共有できる「30days Album™」とハンドメイドの作品を手軽に展示・販売・購入できるハンドメイドマーケット「minne」になります。訳あって2つのプロダクトを見ています。マネージャーという役職になったのは2015年の10月頃です。なのでマネージャー歴は1年くらい、ペパボ5年目になります。

※「プロダクト」と「サービス」という言葉を使いますが、「プロダクト」はプロダクト開発に関わる要素が強いことを示したいときに使います。「サービス」は「プロダクト」を含むより広いものとして扱いたいときに使います。

どのような経歴からマネージャー職になったか

マネージャーになるまではエンジニアでした。情報工学系の大学を卒業後、ペパボが新卒採用を初めて2年目、新卒エンジニアの採用を初めて行った年の2012年に入社し2015年の9月頃までの3年間ほどはエンジニアとしてお仕事しておりました。入社して配属されてからずっと先ほどご紹介した「30days Album™」の開発です。今、エンジニアという職種で活躍されている皆さんと同様、日々新しい技術を学習したり、勉強会、カンファレンス等に参加するような人間でした。3年目にはペパボのエンジニア職位制度におけるシニアエンジニアという職位になりました。（エンジニア職位制度についてはエンジニアの働き方>エンジニアに関する制度をご参照ください）そしてその後、4年目にその時の上長にマネージャーをお願いしたいと言われ、マネージャーになります。（急な展開でマネージャーになりますが、マネージャーという職に対して上長には少し興味があることを伝えていました。）とても簡単に説明していますが、こうして1サービスのマネージャーになります。チーム規模は、プロダクト開発を行う自分も入れて5人ほどのチームです。

足りないと思ったスキル

まずペパボにおけるマネージャーという職がどのような仕事をするのかがわからないと必要なスキルがわかりません。幸いにも（後でよかったと思っています）マネージャーが複数人いるサービスではなく自分一人のみだったため、必要な仕事は全て自分で行う必要があり、必要なスキル要素を把握し、足りないと思ったスキルを学習するサイクルを回せる環境でした。またこれまでのマネージャーの仕事内容からある程度必要なスキル要素は予想することも可能でした。以下が自分に足りないと思ったスキルです。

※「スキル」という単語をあえて使っています。より人間行動に関わる技能が多いと感じたためです。技術的要素が多い場合も統一のためスキルを使う場合があります。

  • 会計
  • 面接
  • コーチング
  • ファシリテーション
  • プロダクト開発（後から追加）

会計

予算実績管理と簡単な経理処理を行う必要があり、これについて調べると会計に関する知識が必要だとわかり自分には足りない思ったスキルです。エンジニアとしてこれまで生活してきたので会社としての「カネ」に関する知識をそもそもそれほど身につけていませんでした。（開発で触れる場合がありますがより深く追求して見てはいませんでした。）

面接

採用を行う立場になります。そのため面接を行うスキルは当然必要と判断しました。

コーチングとファシリテーション

実際にマネージャーとしてチームを動かそうとするとうまくいかないことだらけでした。いつも当たり前に行っていた（参加していた）MTG、面談などがうまく動きません。人に関するスキルが足りなかったのです。マネジメントについて調べてみると、どうやらこの2つが必要そうだとわかりました。

プロダクト開発

どのようにしてプロダクトは開発されるのか。その根本をあまり考えたことがありませんでした。プロダクトを作り出していかなければいけない立場になったときに気づきました。（この部分については多くのことを考えて実施し、わかってきたことがあるのですがこの文章では多く語っていません。）

それをどのような手段で身につけたか

基本は以下の3つかなと思います。

  • 本を読む
  • 先輩マネージャーを観察する
  • 計画 実践 問題の発見 改善 (=PDCA)

本を読む

以下は足りないスキルを身につけるために読んだ本です。他にも実際は多くの文献などを見ていますが特に自分にマッチした本になります。

（以下で紹介する本のリンク先はアマゾンになります。アフィなしですので安心してクリックしてください。）

会計

面接

  • 良い人材を見抜く採用面接ポイント
    • 「採用面接」に関する本で実践的な項目が含まれてそうだなと思いピック。面接官としての心構えの部分は参考になるかなと思います。ただ面接は実践での学習が多いです。

コーチング

ファシリテーション

プロダクト開発

先輩マネージャーを観察する

実際にできてる、やってる人をみるのが手っ取り早いです。数字を触る人に画面を見せてもらう。面接に同席する。面談に同席する。MTGで進行役を観察する。会議の発表の仕方を見る。ペパボには様々なマネージャーがいるので学ぶところは近くに多くあります。

計画 実践 問題の発見 改善 (=PDCA)

本を読む、先輩マネージャーを観察して学習したことを実践します。初めてでうまくできなくてもやらなきゃいけない立場なのでやるしかない！計画ができるものは事前に計画し、実践、そして実践してみてうまくいかなかったところは次に改善して実践する。ほぼPDCAサイクルのような形で毎回試して身につけていきました。これからもずっとですね。

ただマネジメントにおいて「改善」は、すぐに大きくやる必要があると思います。自分がうまくいかない時間はチームのスタッフに不安や苛立ちを与えていることになるので問題を見極めて、問題に対する最善の改善策を見つけるようにします。これがマネージャーとして一番大事なところかと。付き合ってくださっているチームメンバーには感謝！

問題だったプロセスや気付き

  • とにかく行うMTG
  • 共通認識・理解

とにかく行うMTG

なぜかMTGを行えば解決するだろうという思考がありました。みんなで集まって話せばなにか解決すると。しかし現実はただ余計に問題を発生させる機会を作っているだけになっていました。

共通認識・理解

自分が伝えたと思っていることが相手にうまく伝わっていないことが多々ありました。issue上やチャットツール上のやりとりだけでいい感じに進むだろうと思っていました。伝わっていない、進んでいないはスタッフの表情やアウトプットによってわかります。

どのように解決したか、改善したか

とにかく行うMTG

やったことはこの2です。

  • MTGの目的を決め、MTGが始まる前に伝える
  • 意思決定者を決める

どちらも当たり前のことなんですが意外とできてなかったりします。MTGを行うということはスタッフの時間を消費します。消費する時間を無駄にしないために事前に目的を伝え自分が消費するべき対象なのかを理解してもらいます。もちろんマネージャーはスタッフに対しあなたの意見が必要だということを示す必要があります。また事前に目的を共有することで開始までに準備をすることができるので、ある程度の答えを持ち寄った状態からMTGを開始することができます。目的を決めることによってこの時間でアウトプットしなければならない成果が明確になり、目的に向けて全員が取り組むことができるようになります。MTG中に目的を見失わないようファシリテーションするのも必要です。これら当たり前のことと思ってMTG参加していたんですが行う立場になると意識して行わなければいけないことに気づきました。

民主主義は万能ではない。

以下のスライドがとても参考になりました。

共通認識・理解

これの解は徹底的に会話することしかないかなと思います。絵を描いたりポストイットを使ったり、なんでもいいので考えていることをアウトプットして会話して共通理解を気づくこと。自分の認識が合っているか確認すること。「ユーザーストーリーマッピング」の0章に共通理解について書かれているのですがそこにはこう書かれています。

共通理解があるとは、互いに相手がイメージしていることと、その理由を理解していることだ。

全員の理解がバラバラだとわかるのも上記のような効率的な会話をしたときと。そして以下のようにも書かれています。

ひとりの人間が正しいか間違っているかの問題ではない。私たち全員が別々の重要な側面を見ているということだ。

新たに見つかった足りないスキル

社外とのやりとりですね。ここは今まで自分があまり経験する環境じゃなかったのですが必要になり挑戦していったところになります。エンジニアとしては避けたいところかと思います。自分もそうしてきたのです。ただやってみるとサービスの可能性を自分自身の動きによってさらに広げられることに気づけます。そしてビジネスとしてプロダクトを提供していく上で欠かせない点がわかってきます。直近、挑戦してみてできるようになり自信を持てたスキルであります。

最近考えていること

長々と書いてきてそろそろ力尽きています。（笑）ここちゃんと書こうとしたのですが簡単にしようと思います。（書く項目を決めてから書いてるので書かねばという使命感。また別の機会があれば。）

  • 人数が増えてきたプロダクト開発チームにおける現場について（チーム、リーダーシップなど）
  • ヴィジョンについて（探し中）

最後に

1年と少しマネージャーという職に就いてから自分なりに試行錯誤したことの一部をそのまま書いてみました。このドキュメントがマネージャーという職、またそれに近い役割について興味を持たれている方、自分と同じような立場で今、試行錯誤をしている方の参考になれば幸いです。

ペパボのスタッフがつくるサービスは以下からご覧いただけます。
https://pepabo.com/services/

明日13日目はgloverさんです。

JSPのpage命令
lua仮想マシン関数呼び出し命令OP_CALL、OP_RETURN