nozayasu

仕事全般/マネージメントで考えたこと

そこにスペシャリストの必要性はあるか

多様な人材が必要とされる中でも、スペシャリストを特に確保したいと位置付ける企業も多いのではないでしょうか?

ここで言うスペシャリストはエンジニアに対するもので、局所的な高い技術的課題解決力のある人と自分の中で定義しています。

この定義は以前に、エンジニアを理解するためのパタンの1つとして表現しました。

nozayasu.hatenablog.com

数多の企業が確保したい人材であることは、事業を作る過程に何らかの必要性が存在することを示唆していると考えられます。

その一方で必要性を提示し続けれずに、ミスマッチとなる体験を聞くことも少なからずあるのが実情です。

この実情は、ひとえに期待値のすり合わせ不足が要因にあるのでは?と感じるようになりました。

そこで今回は、スペシャリストへの期待値考察を通して、どんな必要性が存在するのか?何をすり合わせたほうが良いのか?をイメージできるように、自分の考えを整理したいと思います。

スペシャリストがもたらすもの

単に高品質の仕事をこなす人材であることが、スペシャリストの魅力ではありません。

事業に影響を与える範囲が大きいことこそが、魅力の本質ではないかと捉えています。

表層的な期待値と深層的な期待値という2つの観点で、その魅力と必要性の度合いを主観で探ってみます。

表層的な期待値

経験値に対する期待値とも言い換えられます。

スポットで在籍する場合と、フルで在籍する場合での違いを考えながら整理します。

スポットで在籍する場合

技術顧問や業務委託、外注等といったものも含んでいるものとします。

以下のような期待値を持ちます。

  • 技術的課題を深くイメージできる立場からの意見により、いつ事業に技術的投資するかの判断基準の幅が広がる
  • 対外的な評価を得ている方も多く、広報面の魅力が増える
  • 共に働く環境があることで、メンバーのロールモデルや成長への内発的動機付けに繋がる

フルで在籍する場合

スポットで在籍する場合の内容に加えて、深く内部にいてもらえることで、以下のような期待値を持ちます。

  • 高い実行力を定常的に確保できることで、事業推進力が高まる
  • 実現性の高い技術選択肢が増えることで、事業戦略の幅が広がる

読み解けること

表層的な期待値からわかることは、スペシャリストの実行力が定常的に欲しいかで、フルである必要性が変わることです。

優秀な人材ほど流動性が高くなってきている傾向がある中で、本当にフルで在籍してもらうほどに求めているか?何をしてほしくて求めているか?

雇用形態や拘束時間への必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。

立ち上げて間もない企業にとって、スペシャリストにフルで在籍したいと思ってもらえる条件を提示しきれない場合。

たとえスポットでの在籍であっても、企業との関係性を持ってくれるスペシャリストが増えてくれることに意味がある。と判断できるケースもあるだろうと思います。

深層的な期待値

「高品質の仕事」という曖昧な表現に隠れた、事業フェーズや人数規模等の状況で変化する、実務に対する期待値とも言い換えられます。

事業フェーズ毎の違いを考えながら整理します。

立ち上げ時期

とにかく色々なものが足りていなく、試行錯誤をしながらプロダクトの方向性を確かめていく時期と捉えます。

何かを解決すればそれで確度が高まるという課題が見つかっていなければ、投資判断を引き出しきれずに、短期視点での泥臭い仕事も多いフェーズでしょう。

プロダクトの課題解決となるかどうかで、優先度も頻繁に変わることが予想できます。

この時期では、以下のような期待値を持ちます。

  • プロダクトの価値検証の速度と精度を高めるため、メンバーが試行錯誤に没頭できる運用基盤を技術で実現してくこと
  • 未来に実現しにくくなりがちな事柄の検討、短期的によしとして長期的に払う技術的代償の認識合わせを先導していくこと

調整時期

プロダクトの価値の方向性をある程度見出せており、拡大時期を見据えての一定の投資判断を引き出せるようになる時期と捉えます。

大きめの次期開発を進めつつ、日々の調整や販促サポート、技術的負債を返すことも検討事項に上がってくるため、関わる人が増え出すフェーズでしょう。

この時期では、以下のような期待値を持ちます。

  • 拡大期にスピード感を落とさないため、メンバー増加に耐えうる開発基盤作り
  • 一定規模の運用を支えるため、可用性を担保しながらの技術的課題解決を先導していくこと

拡大時期

プロダクトの価値が一定規模で認められ、積極的に投資をして事業規模をスケールさせる次期と捉えます。

スケールによる負荷対策や品質を保ち続けていくため、アーキテクチャ刷新や大規模リファクタリングといった、難易度が比較的高めの技術的課題が検討事項に上がるフェーズでしょう。

関わる人も数倍になっていくことが予想できます。

この時期では、以下のような期待値を持ちます。

  • 顕在化した大きめの技術的課題を、率先して解決していく技術力と実行力
  • メンバー育成や運用体制の効率化

成熟時期

プロダクトの成長スピードが鈍化し、投資回収等、ある程度堅実な運用をしていく次期と捉えます。

拡大期に比べると顕在化する技術的課題が少なくなってきて、プロダクトのさらなる価値を求めてR&Dの動きが出てこない場合には、再度泥臭い仕事も増えてくるフェーズでしょう。

この時期では、以下のような期待値を持ちます。

  • 利益率増加のために、コストカットを技術で実現する
  • 未知の事業課題を、技術で明らかにしていくこと

読み解けること

深層的な期待値からわかることは、スペシャリストの特性と事業フェーズ毎の期待値が、どれだけ合致しているかで必要性が変わることです。

持ち合わせる特性や好む責任の範囲が人によって違う中で、今実務的に求めたいことを実行できるか?得意としているか?

事業フェーズ毎の必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。

立ち上げ時期を好むスペシャリストにとって、調整時期や成熟時期で活躍を求めた場合。

たとえ技術的な専門性の範囲から採用要件に合致していても、今はお互いにとって良い関係を築けない。と判断できるケースもあるだろうと思います。

何をすり合わせるのか

企業にむけて

スペシャリストに対する期待値に、どれだけの条件(金額面や裁量面)を提示できるか?

これが利害関係一致の土台部分であるため、雇用における基本だと思います。

その上で、他に考えていきたいことも見えてきました。

  • 雇用形態や拘束時間への必要性を分解して考えること
  • 事業フェーズ毎の必要性を分解して考えること

分解していくことで期待値が過大になるのを抑制し、求めることに対しての条件提示を細かく考えられる。

このすり合わせができることで交渉の幅が広がり、よりよい関係に繋がると考えます。

スペシャリストにむけて

金額面や裁量面は最ものこと、付加価値のやりがい(スペシャリストの成長に意味のある技術的課題が存在する等)になり得そうな環境を提示できるのか?

これが利害関係の強い結びつきに繋がるのではないかと考えます。

とはいえ投資できないフェーズでは、期待値はあるものの望むような条件を提示できないケースも理解はできます。

なにが提示できないのか、どういう提示ならばできる可能性があると考えているのか。

このすり合わせを細かくすることで、企業と個人間での公平感に持てれば、よりよい関係に繋がると考えます。

まとめ

スペシャリストの魅力や思考性、企業の投資判断や事業状況を検討事項として、どんな関係性を作れるのか?

何らかの要因があって、結果として合致しそうな条件や環境を提示できないのだとしたら、そこにはスペシャリストへの期待値はあっても、必要性は存在しないということなのでしょう。

今は絶賛立ち上げ時期であり、泥臭い仕事はそれなりにある。実際に技術的課題解決として任せたいのはこの部分。裁量面ではある程度好きにやってもらえるように環境を用意したい。今提示できる条件はこれくらいです、事業が拡大期になったのであれば、特定の技術的課題を任せることと、そのフェーズとしての必要性を考慮した条件の再提示を約束する。といったようなすり合わせをする意味をイメージできました。

お互いの期待値と不足点を整理し、正直に話した上で落とし所を見つけるフロー、大事にしていきたいですね。

おしまい。

エンジニアの個性を理解するために必要なこと

エンジニアの個性とはなんでしょうか?

一緒に働いているメンバーであっても、ひいては自分自身のことであっても、表現することが難しいと感じています。

そんな最中、採用に携わってきた方に頂いた言葉がとても強く印象に残りました。

これまでずっと企業の採用に携わってきて、特にエンジニアやプログラマの人は、他の職種の方に比べてこだわりポイントみたいのが多種多様かつ明確な人が多いと感じていました。

この言葉を受けて明確なこだわりがあってこそのエンジニアらしさであり、そのこだわりのベクトルがエンジニアの個性たるものなのではないかと考えることができました。

エンジニアの個性が少し具体化したように感じます。しかしまだ多様なこだわりのベクトルは曖昧です。

このベクトルの部分を、エンジニア以外でも認知しやすい表現に落とし込めるのであれば、組織とエンジニアのミスマッチが減るのではないか。 エンジニア間の期待値理解、エンジニアのモチベーション起因把握に役立つのではないか。

そんな想いを胸に、エンジニアの個性を今より少しでも深く、認知できるための何かを探ることが今回の趣旨です。

エンジニアの個性を探るための手がかり

サーバーサイドやフロントエンドといった、扱う技術領域による分類は個性でしょうか?

技術領域の違いも、個性であると思います。

技術領域は、組織内におけるエンジニアのパタン・ランゲージ*1になり得ているため、個性の表現に値すると考えています。

また事業価値を成長させていく過程で、チーム開発において繰り返し起きる課題(事業に直接的な課題だけではなく品質低下・レガシーシステム・モチベーション低下等の、開発を継続する上での包括的な課題のことを考えています)を解決するエンジニアというものが存在します

この部分こそが、エンジニアの個性を表現する上での、重要な要素ではないかと感じています。

しかしこの部分は、技術領域や役職による分類だけでは、うまくイメージしきれていません。

そこでエンジニアの専門性・役職・活動・思考といったものをパタンとして名前をつけ、エンジニアの個性がパタン間の関連で表現されると捉え、今より少しでも深くエンジニアの個性を認知できるための手がかりにしていきたいと思います。

パタン

一般に知れ渡っている概念や、役職として定義されているものも含めて、エンジニアが業務上貢献している側面と性質に、主観ではありますが名前付けをしていきたいと思います。

スペシャリティパタン

  • フロントエンド(サービスの表現に対して技術的解決をできる能力を持つ)
  • バックエンド(サービスの処理に対して技術的解決をできる能力を持つ)
  • インフラ(サービスの安定稼動に対して技術的解決をできる能力をもつ)

テクニカルパタン

  • プログラマー(局所的に技術的解決をできる能力を持つ)
  • ゼネラリスト(広範囲に技術的解決をできる能力を持つ)
  • スペシャリスト(局所的に高い技術的解決をできる能力を持つ)
  • エキスパート(広範囲に高い技術的解決をできる能力を持つ)

マネージメントパタン

  • リーダー(局所的に組織的解決をできる能力を持つ)
  • マネージャー(広範囲に組織的解決をできる能力を持つ)
  • ディレクター(広範囲に高い組織的解決をできる能力を持つ)

チャレンジングパタン

  • イオニア(新しい技術を活用する)
  • エバンジェリスト(新しい技術を浸透させる)
  • イノベーター(新しい技術で課題を解決する)

カバーリングパタン

  • コラボレーター(職務領域にとらわれず企画やセールス等の支援もする)
  • メンター(エンジニアに適切なフィードバックを与える)
  • メンテナー(エンジニアの継続的なアウトプットや効率性の支援をする)

インフルエンスパタン

  • リアクター(発信された技術や想いに反応を示す)
  • パフォーマー(社内外に技術や想いを発信する)
  • タレント(社外に発信した技術や想いで評価される)

思考パタン

  • サービス思考(ユーザー価値がある事業、好きな事業に貢献したい)
  • 技術思考(新しい技術領域、好きな技術領域を通して貢献したい)
  • 成長思考(責任を負える、適切なフィードバックを得られる環境にいたい)
  • 協働思考(友人、尊敬する人といった自分の好きな人と働きたい)
  • 独立思考(自分の生活、個人の時間を大事に働きたい)
  • 評価思考(評価、業務貢献度による対価を正しく与えてほしい)

パタンの可能性

今回あげたパタンは、多様な組織に属するエンジニアに見られる、普遍的なものとも捉えられます。

このようなエンジニアの個性パタンを定義することは、組織としてエンジニアの評価軸・課題設定・フォローアップ・チームビルディング・採用方針といったものにも応用が利く可能性があると感じています。

もう少し具体化した例をあげていきます。

パタンを通してロールモデルとの差分を課題設定にする

f:id:nozayasu:20170405022608p:plain

ロールモデルと設定しているエンジニアは、バックエンドにおけるスペシャリスト。 技術思考と成長思考に裏打ちされた、イノベーターな側面とタレントな側面もある。

一方現状自分はバックエンドにおけるゼネラリストであり、ロールモデルと比較するとスペシャリストとしての活動量がたりていない。 またスペシャリストとしての探究心を保つために、定期的なフィードバックを得られるようにパフォーマーとしての活動も必要かもしれない。

大枠としてロールモデルとの差分を認知しやすくすることで、どうロールモデルに近づくか?自分らしく課題と向き合い目標をたてるか?指針としての可能性があるかもしれません。

パタンを通してエンジニア採用の方向性の理解を深める

f:id:nozayasu:20170405023249p:plain

ある程度自立しているエンジニアでかつ、よりチーム開発を円滑にしてくれる様なエンジニアがほしいという裏側にある想い。

現在のチームにはゼネラリストでかつ、コラボレーターとして活躍している主要なエンジニアがいる。

さらにコラボレーターの側面を持ったエンジニアを採用して、そこの掛け合わせによってチーム開発の円滑さを高めるのか?

メンテナーの側面を持ったエンジニアを採用して、エンジニアチームのアウトプットを向上させる形で、エンジニア主導の円滑さを高めるのか?

採用したいエンジニア像を、イメージするための問いかけになる。

エンジニア採用の方向性として、エンジニアチームと採用チームとの相互理解に繋がる可能性があるかもしれません。

終わりに

単純にパタンの組み合わせで成り立つだけでなく、関連性の強いパタンと弱いパタンがあると思います。随時新たなパタンも生まれることと思います。

そんなパタンの関係性を捉えて、チームとして掛け算になるよう調整をとることが、マネージメントの腕の見せ所なのかもしれません。

今回の話は、エンジニアの個性をより深く捉えるための表現方法の模索が主旨でした。

エンジニアの個性を理解するために必要なこととして、愚直に向き合い続ける姿勢を持つこと。エンジニアらしさに沿ったアプローチをとること。少なくともこの2点を、自分の中で大事にしていく考えを作れました。

エンジニアを精神的に一人にさせる様なことを、少しでも減らせるように、継続的に考えていきたい課題です。

おしまい。

*1:暗黙知の部分に名前をつけ、認知しやすい状態にするという意味でパタン・ランゲージの考え方を参考にし、パタンという言葉を使っています。そのためコンテキストや問題、背景となる因果関係、解決方法、結果、例などから構成される本来のパタン・ランゲージほどに考えきれてはいません。

感情を日報にする

日報に何を書くでしょうか?

作業報告、成果報告、課題報告といったものが一般的な内容ではないかと考えています。 やることリストと捉えて、自己のタスク管理とする人もいるかもしれません。

今回は一般的なものとは少し違う形で日報をつけはじめたら、頭の中の不安が減ってきた。何を不安に感じて、なぜそれが減ったのかを整理しておこう。というのが趣旨です。

今回取り上げる日報を、便宜的に感情日報と呼ぶことにします。

感情日報に何を書かないのか、感情日報に何を書くのか、感情日報を続けてみてどうなったのか?という構成で進めていきます。

感情日報に何を書かないのか

進捗や成果、課題等は基本的には書きません。

日々の進捗や成果報告は、チームにおける進捗管理を確認できることで満足できます。

日々の課題報告は、朝会やチャット上ですぐにフィードバックが得られることで満足できます。

感情日報は、いわゆる日報が担う役割については求めていないことになります。

感情日報に何を書くのか

その日の行動による所感を文字に起こし評価することで、日々の感情のゆらぎを表現します

なぜそんなことをするのかを、背景含めて書いていきます。

チームとしての進捗や成果共有、課題の解決においてはそこまで不自由していない。 それでも自分の中で、まだ表現できてない何かがあると感じていました。

単純にそれは小さな不安であり、忘れては思い出しを繰り返すことで、心の中で大きく積み重なっていきます。

このままではよくないと感じて、何が足りないのかを考えていくと

  • 今日は楽しく働けただろうか?
  • 今日は何か貢献できただろうか?
  • 今日は自分らしく振る舞えただろうか?

このようなことと日々向き合えていない状態を、自分は不安視しているのだと理解しました。

自分らしく振る舞えていたか?ということは、人によっては少し幼稚に思えるのかもしれません。 しかし自分には、日々のタスクと向き合い続けるために、不安を取り除くための大切な要素です。

これはつまり何かというと、自分がありたい姿でいれているのか?という問いなのです。

この問いに対する変化を客観視できるようにすることが、感情日報の役割です。

感情日報の構成

所感を文字に起こす

思うがままに、その日の行動から感じたことを文字に起こします。

例). とある日に書いた所感

全体的な方針決めをしていった
issueかくのむずかしい
でもこういう環境を整備してくのは嫌いじゃないなとおもった
issue作りとかフローの提案して、思った形で一旦進められることになってよかった
何かを聞かれたときにすぐフィードバックするの大事
ガガガっと決済ほしいときには、事前準備がすごい大事
人の思考の拘束時間を短く、違和感をすぐなくすように!の精神で動くのがキモだ

所感を評価する

文字に起こした所感を手がかりに、その日の感情を評価します。

以下の問に対する評価を5段階で行っています。()内の補足は評価の軸を表しています。

  1. 自分らしく振る舞えていた?(行動の選択権の有無、意志の表明の有無)
  2. 高揚感があった?(緊張の有無、好奇心の有無)
  3. 充足感があった?(尊重の有無、フィードバックの有無)
  4. 達成感があった?(貢献の有無、責任の有無)

続けてみてどうなったのか

日々の感情のゆらぎをつけていくと、自分の浮き沈みの傾向、感情と感情の関係性等を捉えられるようになります。

  • 不安に感じてたけど、案外楽しい感情の日が多い
  • 充足感を持ったときほど、貢献したとも感じてる
  • ある項目は評価3が続いて浮き沈み自体がない期間がある

変化を見れるようになったことで、もっと自分に刺激を与えようか?沈んでる原因はなんだろう?を考える時間が増えました。 考える時間が増えた結果として、自分のありたい姿に繋げる行動のイメージが膨らみました。

漠然としていた不安を、自分の考えられる粒度に変えられたことが、不安の減少になったのでしょう。

まとめ

  • 自分の感情を評価することを、日報のフォーマットを使うことで定期的な仕組みにする
  • 評価する行為や評価結果を通して、自分らしく振舞うために何をするかのイメージを作る

以上、感情日報でした。

チームの文化とは何なのか?

チームの文化は何を与えてくれるのでしょう。

ある文化のなかで働くということは、価値観や慣習を共有しながら働くことであり、チームにおける暗黙知を与えてくれる。 共通の暗黙知をメンバーがお互いに持っていることで、コミュニケーションの基礎となりチームの意思決定を早める。

つまりはチームを円滑に機能させるための必要条件十分条件ではない)なのではないかと思っています。

  • そもそも文化とはどんな概念なのか?
  • 意識的にチームの文化を作るとはどういうことなのか?
  • なぜチームの文化を良いものにする必要があるのか?

という3つでチームの文化を考えてみたいと思います。

そもそも文化とは?

文化(ぶんか、英語: culture、ラテン語: cultura)にはいくつかの定義が存在するが、総じていうと人間が社会の成員として獲得する振る舞いの複合された総体のことである。社会組織(年齢別グループ、地域社会、血縁組織などを含む)ごとに固有の文化があるとされ、組織の成員になるということは、その文化を身につける(身体化)ということでもある。人は同時に複数の組織に所属することが可能であり、異なる組織に共通する文化が存在することもある。もっとも文化は、次の意味で使われることも多い。
* ハイカルチャーのように洗練されたもの
* 象徴的な思考や学習による信念やふるまいのパターン
* ある社会組織に共有されている価値観

文化 - Wikipedia より引用

なにやらすっと入ってきにくい言葉が並べられていて、うっ…となるので自分の言葉に噛み砕いていきます。

チームを通して人と人が関わることで抱く想いや価値観、言葉や行動の積み重なりがそのチームにおける文化と呼ばれるようになる。

こう解釈すると悪しき文化も良き文化も、自分達で積み重ねた結果でしかありません。これは自分達の歴史とも言い表わせるのではないでしょうか。

過去の文化はある時点まで積み重ねた行動の結果
今の文化は現時点まで積み重ねた行動の結果
未来の文化はこれから積み重ねていく行動の結果

チームの文化というのは時間軸上のある断片のようなものとも捉えられます。 その断片は、チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。

流動的な性質をもった概念であり、その時々の条件を受け止めて継続的なフィードバックをすべきものだと理解しました。

文化の輪郭が少しつかめた気がします。

この考え方をもとに、意識的にチームの文化を作るとはどういうことなのか?を考えていきたいと思います。

意識的にチームの文化を作る

組織的な取り組みの構造を理解する

チームの文化を作る上で、どのような組織的な取り組みが良い効果をあげているのかは、著名な方々や企業が数多くの事例を示してくれています。

数多ある取り組みのなかの1つに共感し、所属チームでも同じように取り組んで良い文化を作っていこう!と考えた時に、果たして同じような効果は得られるものでしょうか?

ここでチームの文化が、もう一度どんなものであったかを思い返します。

チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。

これはつまり、チーム毎の構成要素には様々な違いがあることに他なりません。

違いがあることを前提に持つと、自分達が同じような効果を得るには、取り組みの構造を捉えることが大事になってきます。

その取り組みは、何をチームに与えるのだろうか?なぜ良い方向に働くのだろうか?結果として自分達の望むチームの文化形成に寄与するだろうか?

構造を理解することで、今のチームに与えるべきものだろうか?チームに落とし込む際に大事な観点はなんだろうか?という問いが明確になるからです。

「チームのあるべき姿を言葉にすること」という例を取り上げながら、組織的な取り組みの構造を考えることをやってみたいと思います。

チームのあるべき姿を言葉にすること

チームのあるべき姿・価値観を表すための取り組みとして、ミッション・ビジョン・バリューを設定しよう!というのをよく目や耳にします。

なぜこのような取り組みをするのでしょうか?

過去に一度考えたことのあるテーマで、その時の所感としては

日々の業務レベルにおいて判断基準の1つになり得るものである。

エンジニアが経営理念について考えた話 - nozayasu

というものでした。

チームのあるべき姿を設定することで、メンバーに行動の判断基準を与える
メンバーに行動の判断基準を与えることで、メンバーやメンバー間に健全なフィードバックを促す
一定の基準に基づいたフィードバックの積み重なりが、結果としてチームの文化を望むものへと緩やかに調整する

というような構造を自分のなかで解釈できました。

共通の理想像は、チームの継続的なフィードバックにおける指針となり、日々の積み重ねの方向を無意識下に調整してくれるのでしょう。

実際にチームのあるべき姿を言葉にする際には、チームにおける行動の判断基準になりえているか?フィードバックを生んでいるか?を観点として持つことができました。

ルールや慣習に向き合う

組織的な取り組みの構造を解釈し、チームに落とし込むために必要な観点を持つことをしてきました。

どんなに良い取り組みも、定着することなく中途半端で終わってしまってはチームの文化形成には繋がらないでしょう。次は定着させるために何ができるのか?ということを考えていきます。

イメージを湧かせるために「ユーザーファーストに徹すること」を例にしてみましょう。

ユーザーファーストを組織的な取り組みとして実現するために、職種の垣根を超えてユーザの声を日々の行動や施策に活かすことを推奨する。

この時、チームでは何が起きるでしょうか?

エンジニアが営業同行して直接ユーザーの声を聞きにいく、営業がSQLを駆使してユーザーの行動ログを分析する。ユーザの声をより深く知るために、職種や職能の垣根も超えてどんな向き合い方ができるのか?をメンバーは模索するかもしれません。

しかしこれはあくまで、メンバーの意欲に依存する形です。定着を目指す場合には、ある程度のルール化を検討する必要があると考えています。

ルールにするということ

具体的なルールとは「月一回エンジニアは営業同行をすること」といったものです。強制力を持つルールは、メンバーを行動させることに直結するため、取り組みを定着させることに強い影響力を持つと思います。

行動を起こさせるではなく、行動をさせるという言葉を使いました。ルールというものは個人が納得感を持っているかは関係なく、行動という結果を引き出すような力も持ち合わせるため、それが苦痛であると受け取られた場合強い反感を買うことでしょう。

メリットとデメリットを考えた上で、どのような場合にルールにすべきなのでしょうか?自分のなかの基準を考えておこうと思います。

  1. チームの理想とする価値観を共有するため、それが望ましい強制である場合
  2. 立場・職種・職能を超えたフィードバックや指摘をしやすくなるよう、メンバーに公平性を与えたい場合

1について

たとえルールの設定者側が望ましいと思っても、最悪の場合それを理由に辞められるかもしれない。ということはあり得るだろうと思っています。

なので、なぜそのルールが望ましいと思っているのか?をチームやメンバーに繰り返し言葉にすることを、合わせて行うべきと考えています。

2について

チームに取り組みを定着させるためには、メンバー間での監視が機能することが必要です。人間は忘れる生き物であり、ミスをする生き物だと捉えています。だからこそ、フィードバックを日常的に行えることが定着に強い意味を持ちます。

しかしフィードバックというのは、職種や立場を超えて行うことに心理的障壁が伴うものであるというのが一般的です。 そこでルールです。ルールという共通の基準を逸脱したか?で判断できる状態を与えることは、フィードバックをするという行為の心理的障壁を和らげるだろうと考えています。

慣習の扱いを決めるということ

チームにはルールのように明言されていないが、メンバーが同じようにとる行動である慣習と呼ばれるものが存在します。

ある行動を他者が真似する形で生まれたもの、メンバー特性によって生まれたもの、ルールの副作用で生まれたものといったような自然発生するものです。

慣習は自然発生したものであるがゆえに、チームの文化にとって望ましいものであるとは限りません。扱いとして、認める・認めない・黙認するという3つの選択肢が考えられます。

価値観にマッチしているか?メンバーの自由度を妨げないか?何か問題が起きているか?という観点で、いかに扱うべきかを判断する必要があると考えます。

特に黙認する選択肢をいれることが大事だと思っていて、慣習を認める・認めないと明言することはルールを作ることと同義であり、メンバーに前述したようなストレスをもたらす可能性のある行為です。直近問題がないのであれば、あえて黙認することにも意味があると感じています。

なぜチームの文化を良いものにするのか?

チームの文化というものは、良くしたことで事業の利益に直接影響するものではないかもしれません。

また事業がうまくいってるときには、得てしてチームの雰囲気も自然といいものです。 逆に言えば、事業が苦難と対峙したときほどチームの雰囲気が悪くなります。

ここで考えなければいけないことは、チームの雰囲気が良いこととチームの文化が良いことは別であるということ。チームの雰囲気が良くても組織的負債は貯まっていく可能性があるということ。

なぜチームの文化を良くするのかと言われれば、それは事業を継続させより発展させたいから。

事業が苦難と対峙した時にどう切り抜けるか、チームが苦難にきちんと対峙できるようにしておく必要がある。

そのために普段からチームの文化のことを考えていなければいけない。組織的負債を溜め込み過ぎないようにしなければならない。

たとえ事業がうまくいかず雰囲気が悪くとも、それでも必死にチームとして事業に向き合っていれてるのであれば、そこには良いチームの文化があるのだと。そんな風に僕は思うのです。

Japan Product Manager Conferenceから感じ取った、プロダクトマネージャー19の職責と11の心構え

pmconf.jp

全体的な所感

今回参加したJapan Product Manager Conferenceは、プロダクトマネージャーという言葉が表すものはなんであるのか?という問いかけに尽きるなと思いました。

実務経験から得た知見や結果の考察、思考法やフレームワークをどのように取り入れているか、理想とする姿と現場としての課題感。様々な観点でのセッションがあった中で、会全体を通してプロダクトマネージャーの職責を言語化する、心構えを共有するという熱意みたいなものを感じ取れたからです。

以上の様な全体的な所感を前置きとしつつ、僕が感じ取ったプロダクトマネージャーの職責と心構えを整理します。さらにプロダクトマネージメントというものに対して、二日間何を考えたのかという構成で話をしたいと思います。

僕は前提としてプロダクトマネージメントというものは、事業領域や構成メンバー等によって独自文化を持つものである。それ踏まえて抽象化できるものや、一般論として話せるものもあるという考えを持っています。なので今回は、事業領域等を超えて一般化できることと感じたものを整理します。

プロダクトマネージャーの職責

http://3.bp.blogspot.com/-Lre98PlTKKM/Vf-aHNlsDXI/AAAAAAAAyDQ/erI62bdTvds/s800/businessman_workaholic.png

課題探索

  • プロダクトに懐疑的であり続けることが職責である
  • プロダクトが解決する本質を探索することが職責である
  • プロダクトの課題設定をすることが職責である

戦略立案

  • プロダクトの理想像を言語化するのが職責である
  • プロダクトの定性的な目的設定をすることが職責である
  • プロダクトの定量的なゴール設定をすることが職責である
  • プロダクトの成果を出すことが職責である
  • プロダクトの好意・認知・配荷を向上をさせることが職責である
  • プロダクトのリスク・阻害要因を取り除くことが職責である

構造化

  • プロダクトの課題・目的・ゴール設定を理解・実行できる単位に細分化することが職責である
  • プロダクトタスクの優先度付けすることが職責である
  • プロダクトタスクを継続実施するための必要情報全てを整理することが職責である
  • プロダクトの成果を理解できる単位に分解・翻訳することが職責である

組織作り

  • チームメンバーの特性を理解することが職責である
  • チームメンバーの課題や経験を引き出し、チームとして循環・還元させることが職責である
  • チームメンバーのオーナーシップを支援するのが職責である
  • エンジニア、セールス、マーケティング、デザイン、サポート、あらゆる部門と健全なコミュニケーションをとることが職責である

成果分析

  • プロダクトが課題を解決できているかを分析するのが職責である
  • プロダクトの成功/失敗を判断することが職責である

プロダクトマネージャーの心構え

http://1.bp.blogspot.com/-BcUJyoZPQns/Vt_t2lfEDUI/AAAAAAAA4pc/t9i1I_hoCXA/s800/business_tayoreru_man.png

  • 権限ではなく戦略やビジョンを振りかざすべきである
  • 自分やチームにゆとりをもたらす仕組みを整備すべきである
  • 考えを徹底的に言語化して伝えるべきである
  • 建設的な議論や問いかけをするための言葉を選んで使うべきである
  • コミュニケーションのハブであろうとすべきである
  • 公平性があるプロダクトより愛されるプロダクトを考えるべきである
  • 面倒なことほど取り組むべき課題だと考えるべきである
  • ルーチンワークは仕組みに置き換えれないかを考えるべきである
  • 追加開発は、追加スケジュールとセットになるものだと考えるべきである
  • エンジニア目線とユーザ目線は、対立するものではなく補完し合うものだと捉えるべきである
  • 世界を見据えたプロダクトを考えるべきである

プロダクトマネージメントというものと二日間向き合って

カンファレンスの内容は、とても刺激をもらえ影響を受けるものが多かったです。

また開催期間中の伊藤直也さん言葉にとても考えさせられました。

改めて、プロダクトマネージャーに担ってほしいことはなんでしょうか?

思想家でしょうか?戦略家でしょうか?評論家でしょうか?プロダクトに関わる全てでしょうか? 僕はプロダクトを通して責任を負っていく役割だと考えるようになりました。 責任を負う過程というのは、人に足りないものを埋める動きをさせ、把握する範囲が広がっていき、思慮深くある必然性をもたらすのだろうと感じています。

加えて、数多ある職責の中でも個人的には物事を構造化できるスキルや経験値が重要視されると考えるようになりました。 難しい課題や大きな目標に対して、自分達が理解・実行可能な単位に分解できるかどうかが日々の成果に影響する。
売り上げ目標1億に対する成果10万をいかにして生むのか、予実をとれる単位が細かいほど大きな目標の予測値信頼度があがる。
大きな目標を達成するべくして達成することが、プロダクトマネージャーの責任を果たすと言うことなのかもしれない。
といったことが二日間を通して自分の中に残りました。

最後に少し話を変えて本を読む行為というものを考えてみます。本を読み続けていると書籍毎に点で理解してきたことに対して、一気につながって物事の流れや構造体をぐっとイメージできる瞬間があります。
経験される方も多い感覚かもしれません、あっこれは別の書籍でも近しい内容に触れたことがあるぞ共通解なのかな?だとするとあっちの矛盾はこっちで解決になるのかもしれない。のような体験です。

本質を探る行為というのは、例にあげた本で体験できる様な感覚。多角的な視点を用いて、もやもやしていた物事の構造体をイメージできるようにする行為であると考えています。

責任を負い、思慮深くなり、把握する範囲が広がる。副次的に物事を多角的な捉えかたをできるようになり、結果として構造体をより深く理解・説明をできるようになる。この流れをイメージできたことが、僕の中で一番の収穫でした。

運営の皆様、登壇者の皆様、会場でお話しをさせてもらった皆様、ありがとうございました。

工数見積もりとはラブレターである

前置き

システムを実装する上での工数見積もりで、どんなことを把握したいですか?
僕は個人にできるかぎり依存しない、事業価値を届けるために必要なコストを把握したいと思っています。

工数見積もりとは誰が行うものでしょうか?担当するエンジニア個人でしょうか?それともチームに属するエンジニア全員でしょうか?
僕はデザイナーや企画も巻き込んでチーム全員と関わりながら行うものであると考えています。

関係者全員で、絶対的な時間の見積もりではなく、相対的な規模感での見積もりをしていく。この辺りは所謂アジャイルな開発の思想に影響を受けているように思っています。

このような考えのもと、工数見積もりというものを通して

  • 何がしたくて何がしたくないのか
  • 各ポジションとどんな風に関わっていくのか
  • 一番考えるべきことは何だと思っているのか

みたいなポイントで自分の考えをまとめていこうと思います

何がしたくて何がしたくないのか?

工数見積もりでしたいことはなにか?

  • ユーザーにとって必要なものであることがイメージできること
  • イメージ通りの機能を作りあげるために必要なものを整理すること
  • 規模感の把握

工数見積もりでしたくないことはなにか?

  • 実際にできあがったものが意図していないものになること
  • 作業に入ろうとしたときにまだ動きだせない状態であること
  • 未確定要素によって規模感すらだせないこと

こうやって改めて考えてみると、情報の整理からくるタスク分解と規模感を把握だけでなく、タスクの完了状態が与える影響がどんなものかもこの段階で意識したいのだなと思いました。
また着手時にすぐ動き出せるように、未確定要素を極力なくす調整もこの段階で一番とっていきたいと思えました。

各ポジションとどんな風に関わっていくのか

デザイナーや企画側に対して

デザイナーや企画側に対してはフィードバックをする、レビューの面もあると思っています

  • どんなことをしたいのか伝わってくるか?
  • 自分がユーザとしたら価値があると思えるか?
  • タスク分解をイメージできるだけの情報があるか?
  • やりたいことへのシステム的な解決はもっと良い方針がないか?
  • これをやらないで別のことやったほうがよかったりしないか?

実装する側だから気づける点と想い、実装前段階ですり合わせていくことで出戻りを少なくしていければと思っています。

同じエンジニアに対して

同じエンジニアに対しては、いかに思いを伝えて共通のイメージを持つかが大事だと思っています。

  • 他人がこの作業をするのならどんな情報が必要か?
  • 新たに配属された人でもイメージできるだけの情報になっているか?
  • 作業の実現アプローチは妥当なものか?
  • 実現するための不明点はないか?

同じエンジニアだからこそ、スムーズに開発がスタートできるよう負担を軽減することになればと思っています。

一番考えるべきことは何だと思っているのか

やることの見積もりをするのはもちろんなのですが、僕は加えて一部やらない判断を提案していくことや、既にあるもの削除していくための見積もりこそ大事ではないかと考えています。

それは事業に対してエンジニアが一番主張できるポイントが、何を作らないのか?だと思っているからです。
やらないことが増えると、保守するコードが減ることになります。運用時のフットワークが軽くなります。

全ての企画を作るとこれくらいかかるけど、同等のこんな機能ならこれだけでできるよ?
企画のやりたいイメージをいかに、シンプルな機能だけで実現できるのか?そこを考えるのも面白いとこなんじゃないかなと思っています。

そういう意味で工数見積もりとは、事業を企画することに大きく関わる作業だと言えるだろうと考えています。

まとめ

作業担当する誰かに送る、精一杯の想い。色んな下準備をして、受け取る人に気に入ってもらえるように作る。さながらラブレターなんじゃないかと思っています(今回これがいいたかっただけかも)。

愛を持って工数見積もりをしてみませんか?きっと愛は届く!きっと。

おしまい。

チームのUXをマネージメントする

チームで仕事をすると言うのはどの様なことでしょうか?
メンバーはチームを通して何を感じ、他のメンバーに何を感じさせるのでしょうか?

今回はチームにおけるUXという視点で、何をマネージメントをすることができるだろうか?を考えます。

チームで仕事をする際のUXとは?

まずは僕の考えるチームのUXは何かを定義します。
チームを通して何を考え、どんな行動をして、どれだけの対価を得たり払ったりしたか。と言うことだと考えていて

  • アドバイスをして、信頼を得ること。
  • 成果が出て、自信を得ること。
  • 失敗して、信頼や自信を失うこと。

例えばこのようなことがチームで仕事をする際のUXだと捉えます。

チームのUXをマネージメントするとは?

チームと言う体裁があったとしても、メンバーはあくまで利己的に行動を決定するものだろうなと考えています。
もう少し噛み砕くと共通の目標があってチームは結成されるわけですが、漠然と走っていくとメンバーは個人の利益を最大化させる行動を無意識に優先するだろうと思っています。

チームとしての利益という視点での行動をメンバーから引き出すこと、これがチームのUXをマネージメントするということだと考えています。

引き出すために何をするのか?

books.google.co.jp

この本であげられている様な心理的安全をチームにもたらせるように先導していくことで、チーム利益のための行動が、個人利益のための行動と同等の価値を持つようにしていきたい。そのために何をするか?ということを考えていきます。

  1. どんなチームが理想なのか、どんなチームにしたいのかを伝える
  2. チームがメンバーに何を期待しているのかを理解できるようにする
  3. 実際に行動に起こすという体験をできるように手助けしてあげる

それぞれを見ていこうと思います。

どんなチームが理想なのか、どんなチームにしたいのかを伝える

僕の大好きなスライドを紹介して、まずイメージを持ってもらえればと思います。

speakerdeck.com

ここで伝えたいことは、スライドの中に書いてある内容が正だ、これが僕の理想だということではありません。(個人的には好きで影響うけてます)

チームとしてどんなメンバー同士の関係性でありたいのか、どうあることがいいことだと考えているのか。それをメンバーに伝え、示すことが大事だと考えています。

もちろん理想を話すことはメンバー間で折り合えない部分もあると思っていて、それはそれで良いと思います。折り合えないよということがわかることで、対応できる余地が作れると考えるからです。苦手なら苦手なりの、付き合いかたを考えましょうか?となれれば僕としては儲け物です。

今後のチームとしての行動指針を一緒に考えていこう?という意思表示と、実現するためになにができるか考える、自分だったらもっとこうだと考える体験をメンバーとすることを狙いにしています。

チームがメンバーに何を期待しているのかを理解できるようにする

最近見て考えることが多かったワークショップの資料を紹介しつつ、こちらもまずイメージを持ってもらえればと思います。

speakerdeck.com

「知っているだけで解決できる問題が世の中にはたくさんある」この言葉をなるほどな、そうだなーと思いました。僕個人としてチームメンバーに期待すること、思っていても正直あんまり言葉にしたことなかったです。

僕はこのスライドをみて、これって開発フェーズ毎と役職や職種って視点で分けて考えると、もっと具体的な業務レベルでの期待感の共有になるかもなと思っています。

企画立案時には、エンジニアは企画者にどんなことを期待してるのか。その逆はどうなのか。実装時には企画立案時とは別の期待がメンバーに生まれるのか。ユーザエクペリエンスマップのペルソナをチームメンバー、フェーズを開発のフローに当てはめてみてワークショップ等企画してみることで、チームの相互理解が深まるのではないかと思っています。

チームメンバーがお互いに期待していることを把握することで、今のタイミングではこんな行動してほしいのかな?と考える体験をすること、プラスの対価を得る行動はこうなのかもな?と感じてもらうことを狙いにしています。

実際に行動に起こすという体験をできるように導いてあげる

これは最近よく感じていることで、不安や困ってることを言える雰囲気作る、心理障壁を減らすってことを実践していくには、メンバー個々人が実際に想いを口に出す体験を何度したかが大事だと考えています。

やはり自分にとっての印象を悪く捉えられそうなことを口に出すのは、抵抗感があるものです。新規参入したメンバー等であればなおさら。

なので最初は聞き出す努力がいる

丁寧に自分で口に出すって行動までを引き出してあげることが、何でも言える雰囲気を育てていくことに繋がるだろうと考えています。開発してて困ってることある?といった聞き方ではなく、この開発だったらこんなとこ困りそうに思うんだけど大丈夫?
と言った様な少しつっこんだ聞き方をすることで、個人としてマイナスの対価を得ると思われがちで嫌厭される行動を、起こしやすくしてあげられないかを狙いにしています。

まとめ

チームとしての利益という視点での行動をメンバーから引き出すために、心理的安全をチームに熟成させたい。それをこんなアプローチでやっていきたいと思っています。どうしてそうしたいと考えてるのか?と言う観点で書いてきました。どこか参考になるところがあれば幸いです。

おしまい。