エンジニアの個性を理解するために必要なこと
エンジニアの個性とはなんでしょうか?
一緒に働いているメンバーであっても、ひいては自分自身のことであっても、表現することが難しいと感じています。
そんな最中、採用に携わってきた方に頂いた言葉がとても強く印象に残りました。
これまでずっと企業の採用に携わってきて、特にエンジニアやプログラマの人は、他の職種の方に比べてこだわりポイントみたいのが多種多様かつ明確な人が多いと感じていました。
この言葉を受けて明確なこだわりがあってこそのエンジニアらしさであり、そのこだわりのベクトルがエンジニアの個性たるものなのではないかと考えることができました。
エンジニアの個性が少し具体化したように感じます。しかしまだ多様なこだわりのベクトルは曖昧です。
このベクトルの部分を、エンジニア以外でも認知しやすい表現に落とし込めるのであれば、組織とエンジニアのミスマッチが減るのではないか。 エンジニア間の期待値理解、エンジニアのモチベーション起因把握に役立つのではないか。
そんな想いを胸に、エンジニアの個性を今より少しでも深く、認知できるための何かを探ることが今回の趣旨です。
エンジニアの個性を探るための手がかり
サーバーサイドやフロントエンドといった、扱う技術領域による分類は個性でしょうか?
技術領域の違いも、個性であると思います。
技術領域は、組織内におけるエンジニアのパタン・ランゲージ*1になり得ているため、個性の表現に値すると考えています。
また事業価値を成長させていく過程で、チーム開発において繰り返し起きる課題(事業に直接的な課題だけではなく品質低下・レガシーシステム・モチベーション低下等の、開発を継続する上での包括的な課題のことを考えています)を解決するエンジニアというものが存在します。
この部分こそが、エンジニアの個性を表現する上での、重要な要素ではないかと感じています。
しかしこの部分は、技術領域や役職による分類だけでは、うまくイメージしきれていません。
そこでエンジニアの専門性・役職・活動・思考といったものをパタンとして名前をつけ、エンジニアの個性がパタン間の関連で表現されると捉え、今より少しでも深くエンジニアの個性を認知できるための手がかりにしていきたいと思います。
パタン
一般に知れ渡っている概念や、役職として定義されているものも含めて、エンジニアが業務上貢献している側面と性質に、主観ではありますが名前付けをしていきたいと思います。
スペシャリティパタン
- フロントエンド(サービスの表現に対して技術的解決をできる能力を持つ)
- バックエンド(サービスの処理に対して技術的解決をできる能力を持つ)
- インフラ(サービスの安定稼動に対して技術的解決をできる能力をもつ)
テクニカルパタン
- プログラマー(局所的に技術的解決をできる能力を持つ)
- ゼネラリスト(広範囲に技術的解決をできる能力を持つ)
- スペシャリスト(局所的に高い技術的解決をできる能力を持つ)
- エキスパート(広範囲に高い技術的解決をできる能力を持つ)
マネージメントパタン
- リーダー(局所的に組織的解決をできる能力を持つ)
- マネージャー(広範囲に組織的解決をできる能力を持つ)
- ディレクター(広範囲に高い組織的解決をできる能力を持つ)
チャレンジングパタン
カバーリングパタン
- コラボレーター(職務領域にとらわれず企画やセールス等の支援もする)
- メンター(エンジニアに適切なフィードバックを与える)
- メンテナー(エンジニアの継続的なアウトプットや効率性の支援をする)
インフルエンスパタン
- リアクター(発信された技術や想いに反応を示す)
- パフォーマー(社内外に技術や想いを発信する)
- タレント(社外に発信した技術や想いで評価される)
思考パタン
- サービス思考(ユーザー価値がある事業、好きな事業に貢献したい)
- 技術思考(新しい技術領域、好きな技術領域を通して貢献したい)
- 成長思考(責任を負える、適切なフィードバックを得られる環境にいたい)
- 協働思考(友人、尊敬する人といった自分の好きな人と働きたい)
- 独立思考(自分の生活、個人の時間を大事に働きたい)
- 評価思考(評価、業務貢献度による対価を正しく与えてほしい)
パタンの可能性
今回あげたパタンは、多様な組織に属するエンジニアに見られる、普遍的なものとも捉えられます。
このようなエンジニアの個性パタンを定義することは、組織としてエンジニアの評価軸・課題設定・フォローアップ・チームビルディング・採用方針といったものにも応用が利く可能性があると感じています。
もう少し具体化した例をあげていきます。
パタンを通してロールモデルとの差分を課題設定にする
ロールモデルと設定しているエンジニアは、バックエンドにおけるスペシャリスト。 技術思考と成長思考に裏打ちされた、イノベーターな側面とタレントな側面もある。
一方現状自分はバックエンドにおけるゼネラリストであり、ロールモデルと比較するとスペシャリストとしての活動量がたりていない。 またスペシャリストとしての探究心を保つために、定期的なフィードバックを得られるようにパフォーマーとしての活動も必要かもしれない。
大枠としてロールモデルとの差分を認知しやすくすることで、どうロールモデルに近づくか?自分らしく課題と向き合い目標をたてるか?指針としての可能性があるかもしれません。
パタンを通してエンジニア採用の方向性の理解を深める
ある程度自立しているエンジニアでかつ、よりチーム開発を円滑にしてくれる様なエンジニアがほしいという裏側にある想い。
現在のチームにはゼネラリストでかつ、コラボレーターとして活躍している主要なエンジニアがいる。
さらにコラボレーターの側面を持ったエンジニアを採用して、そこの掛け合わせによってチーム開発の円滑さを高めるのか?
メンテナーの側面を持ったエンジニアを採用して、エンジニアチームのアウトプットを向上させる形で、エンジニア主導の円滑さを高めるのか?
採用したいエンジニア像を、イメージするための問いかけになる。
エンジニア採用の方向性として、エンジニアチームと採用チームとの相互理解に繋がる可能性があるかもしれません。
終わりに
単純にパタンの組み合わせで成り立つだけでなく、関連性の強いパタンと弱いパタンがあると思います。随時新たなパタンも生まれることと思います。
そんなパタンの関係性を捉えて、チームとして掛け算になるよう調整をとることが、マネージメントの腕の見せ所なのかもしれません。
今回の話は、エンジニアの個性をより深く捉えるための表現方法の模索が主旨でした。
エンジニアの個性を理解するために必要なこととして、愚直に向き合い続ける姿勢を持つこと。エンジニアらしさに沿ったアプローチをとること。少なくともこの2点を、自分の中で大事にしていく考えを作れました。
エンジニアを精神的に一人にさせる様なことを、少しでも減らせるように、継続的に考えていきたい課題です。
おしまい。
感情を日報にする
日報に何を書くでしょうか?
作業報告、成果報告、課題報告といったものが一般的な内容ではないかと考えています。 やることリストと捉えて、自己のタスク管理とする人もいるかもしれません。
今回は一般的なものとは少し違う形で日報をつけはじめたら、頭の中の不安が減ってきた。何を不安に感じて、なぜそれが減ったのかを整理しておこう。というのが趣旨です。
今回取り上げる日報を、便宜的に感情日報と呼ぶことにします。
感情日報に何を書かないのか、感情日報に何を書くのか、感情日報を続けてみてどうなったのか?という構成で進めていきます。
感情日報に何を書かないのか
進捗や成果、課題等は基本的には書きません。
日々の進捗や成果報告は、チームにおける進捗管理を確認できることで満足できます。
日々の課題報告は、朝会やチャット上ですぐにフィードバックが得られることで満足できます。
感情日報は、いわゆる日報が担う役割については求めていないことになります。
感情日報に何を書くのか
その日の行動による所感を文字に起こし評価することで、日々の感情のゆらぎを表現します。
なぜそんなことをするのかを、背景含めて書いていきます。
チームとしての進捗や成果共有、課題の解決においてはそこまで不自由していない。 それでも自分の中で、まだ表現できてない何かがあると感じていました。
単純にそれは小さな不安であり、忘れては思い出しを繰り返すことで、心の中で大きく積み重なっていきます。
このままではよくないと感じて、何が足りないのかを考えていくと
- 今日は楽しく働けただろうか?
- 今日は何か貢献できただろうか?
- 今日は自分らしく振る舞えただろうか?
このようなことと日々向き合えていない状態を、自分は不安視しているのだと理解しました。
自分らしく振る舞えていたか?ということは、人によっては少し幼稚に思えるのかもしれません。 しかし自分には、日々のタスクと向き合い続けるために、不安を取り除くための大切な要素です。
これはつまり何かというと、自分がありたい姿でいれているのか?という問いなのです。
この問いに対する変化を客観視できるようにすることが、感情日報の役割です。
感情日報の構成
所感を文字に起こす
思うがままに、その日の行動から感じたことを文字に起こします。
例). とある日に書いた所感
全体的な方針決めをしていった issueかくのむずかしい でもこういう環境を整備してくのは嫌いじゃないなとおもった issue作りとかフローの提案して、思った形で一旦進められることになってよかった 何かを聞かれたときにすぐフィードバックするの大事 ガガガっと決済ほしいときには、事前準備がすごい大事 人の思考の拘束時間を短く、違和感をすぐなくすように!の精神で動くのがキモだ
所感を評価する
文字に起こした所感を手がかりに、その日の感情を評価します。
以下の問に対する評価を5段階で行っています。()内の補足は評価の軸を表しています。
- 自分らしく振る舞えていた?(行動の選択権の有無、意志の表明の有無)
- 高揚感があった?(緊張の有無、好奇心の有無)
- 充足感があった?(尊重の有無、フィードバックの有無)
- 達成感があった?(貢献の有無、責任の有無)
続けてみてどうなったのか
日々の感情のゆらぎをつけていくと、自分の浮き沈みの傾向、感情と感情の関係性等を捉えられるようになります。
- 不安に感じてたけど、案外楽しい感情の日が多い
- 充足感を持ったときほど、貢献したとも感じてる
- ある項目は評価3が続いて浮き沈み自体がない期間がある
変化を見れるようになったことで、もっと自分に刺激を与えようか?沈んでる原因はなんだろう?を考える時間が増えました。 考える時間が増えた結果として、自分のありたい姿に繋げる行動のイメージが膨らみました。
漠然としていた不安を、自分の考えられる粒度に変えられたことが、不安の減少になったのでしょう。
まとめ
- 自分の感情を評価することを、日報のフォーマットを使うことで定期的な仕組みにする
- 評価する行為や評価結果を通して、自分らしく振舞うために何をするかのイメージを作る
以上、感情日報でした。
チームの文化とは何なのか?
チームの文化は何を与えてくれるのでしょう。
ある文化のなかで働くということは、価値観や慣習を共有しながら働くことであり、チームにおける暗黙知を与えてくれる。 共通の暗黙知をメンバーがお互いに持っていることで、コミュニケーションの基礎となりチームの意思決定を早める。
つまりはチームを円滑に機能させるための必要条件(十分条件ではない)なのではないかと思っています。
- そもそも文化とはどんな概念なのか?
- 意識的にチームの文化を作るとはどういうことなのか?
- なぜチームの文化を良いものにする必要があるのか?
という3つでチームの文化を考えてみたいと思います。
そもそも文化とは?
文化(ぶんか、英語: culture、ラテン語: cultura)にはいくつかの定義が存在するが、総じていうと人間が社会の成員として獲得する振る舞いの複合された総体のことである。社会組織(年齢別グループ、地域社会、血縁組織などを含む)ごとに固有の文化があるとされ、組織の成員になるということは、その文化を身につける(身体化)ということでもある。人は同時に複数の組織に所属することが可能であり、異なる組織に共通する文化が存在することもある。もっとも文化は、次の意味で使われることも多い。
* ハイカルチャーのように洗練されたもの
* 象徴的な思考や学習による信念やふるまいのパターン
* ある社会組織に共有されている価値観
なにやらすっと入ってきにくい言葉が並べられていて、うっ…となるので自分の言葉に噛み砕いていきます。
チームを通して人と人が関わることで抱く想いや価値観、言葉や行動の積み重なりがそのチームにおける文化と呼ばれるようになる。
こう解釈すると悪しき文化も良き文化も、自分達で積み重ねた結果でしかありません。これは自分達の歴史とも言い表わせるのではないでしょうか。
過去の文化はある時点まで積み重ねた行動の結果
今の文化は現時点まで積み重ねた行動の結果
未来の文化はこれから積み重ねていく行動の結果
チームの文化というのは時間軸上のある断片のようなものとも捉えられます。 その断片は、チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。
流動的な性質をもった概念であり、その時々の条件を受け止めて継続的なフィードバックをすべきものだと理解しました。
文化の輪郭が少しつかめた気がします。
この考え方をもとに、意識的にチームの文化を作るとはどういうことなのか?を考えていきたいと思います。
意識的にチームの文化を作る
組織的な取り組みの構造を理解する
チームの文化を作る上で、どのような組織的な取り組みが良い効果をあげているのかは、著名な方々や企業が数多くの事例を示してくれています。
数多ある取り組みのなかの1つに共感し、所属チームでも同じように取り組んで良い文化を作っていこう!と考えた時に、果たして同じような効果は得られるものでしょうか?
ここでチームの文化が、もう一度どんなものであったかを思い返します。
チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。
これはつまり、チーム毎の構成要素には様々な違いがあることに他なりません。
違いがあることを前提に持つと、自分達が同じような効果を得るには、取り組みの構造を捉えることが大事になってきます。
その取り組みは、何をチームに与えるのだろうか?なぜ良い方向に働くのだろうか?結果として自分達の望むチームの文化形成に寄与するだろうか?
構造を理解することで、今のチームに与えるべきものだろうか?チームに落とし込む際に大事な観点はなんだろうか?という問いが明確になるからです。
「チームのあるべき姿を言葉にすること」という例を取り上げながら、組織的な取り組みの構造を考えることをやってみたいと思います。
チームのあるべき姿を言葉にすること
チームのあるべき姿・価値観を表すための取り組みとして、ミッション・ビジョン・バリューを設定しよう!というのをよく目や耳にします。
なぜこのような取り組みをするのでしょうか?
過去に一度考えたことのあるテーマで、その時の所感としては
日々の業務レベルにおいて判断基準の1つになり得るものである。
エンジニアが経営理念について考えた話 - nozayasu
というものでした。
チームのあるべき姿を設定することで、メンバーに行動の判断基準を与える
メンバーに行動の判断基準を与えることで、メンバーやメンバー間に健全なフィードバックを促す
一定の基準に基づいたフィードバックの積み重なりが、結果としてチームの文化を望むものへと緩やかに調整する
というような構造を自分のなかで解釈できました。
共通の理想像は、チームの継続的なフィードバックにおける指針となり、日々の積み重ねの方向を無意識下に調整してくれるのでしょう。
実際にチームのあるべき姿を言葉にする際には、チームにおける行動の判断基準になりえているか?フィードバックを生んでいるか?を観点として持つことができました。
ルールや慣習に向き合う
組織的な取り組みの構造を解釈し、チームに落とし込むために必要な観点を持つことをしてきました。
どんなに良い取り組みも、定着することなく中途半端で終わってしまってはチームの文化形成には繋がらないでしょう。次は定着させるために何ができるのか?ということを考えていきます。
イメージを湧かせるために「ユーザーファーストに徹すること」を例にしてみましょう。
ユーザーファーストを組織的な取り組みとして実現するために、職種の垣根を超えてユーザの声を日々の行動や施策に活かすことを推奨する。
この時、チームでは何が起きるでしょうか?
エンジニアが営業同行して直接ユーザーの声を聞きにいく、営業がSQLを駆使してユーザーの行動ログを分析する。ユーザの声をより深く知るために、職種や職能の垣根も超えてどんな向き合い方ができるのか?をメンバーは模索するかもしれません。
しかしこれはあくまで、メンバーの意欲に依存する形です。定着を目指す場合には、ある程度のルール化を検討する必要があると考えています。
ルールにするということ
具体的なルールとは「月一回エンジニアは営業同行をすること」といったものです。強制力を持つルールは、メンバーを行動させることに直結するため、取り組みを定着させることに強い影響力を持つと思います。
行動を起こさせるではなく、行動をさせるという言葉を使いました。ルールというものは個人が納得感を持っているかは関係なく、行動という結果を引き出すような力も持ち合わせるため、それが苦痛であると受け取られた場合強い反感を買うことでしょう。
メリットとデメリットを考えた上で、どのような場合にルールにすべきなのでしょうか?自分のなかの基準を考えておこうと思います。
- チームの理想とする価値観を共有するため、それが望ましい強制である場合
- 立場・職種・職能を超えたフィードバックや指摘をしやすくなるよう、メンバーに公平性を与えたい場合
1について
たとえルールの設定者側が望ましいと思っても、最悪の場合それを理由に辞められるかもしれない。ということはあり得るだろうと思っています。
なので、なぜそのルールが望ましいと思っているのか?をチームやメンバーに繰り返し言葉にすることを、合わせて行うべきと考えています。
2について
チームに取り組みを定着させるためには、メンバー間での監視が機能することが必要です。人間は忘れる生き物であり、ミスをする生き物だと捉えています。だからこそ、フィードバックを日常的に行えることが定着に強い意味を持ちます。
しかしフィードバックというのは、職種や立場を超えて行うことに心理的障壁が伴うものであるというのが一般的です。 そこでルールです。ルールという共通の基準を逸脱したか?で判断できる状態を与えることは、フィードバックをするという行為の心理的障壁を和らげるだろうと考えています。
慣習の扱いを決めるということ
チームにはルールのように明言されていないが、メンバーが同じようにとる行動である慣習と呼ばれるものが存在します。
ある行動を他者が真似する形で生まれたもの、メンバー特性によって生まれたもの、ルールの副作用で生まれたものといったような自然発生するものです。
慣習は自然発生したものであるがゆえに、チームの文化にとって望ましいものであるとは限りません。扱いとして、認める・認めない・黙認するという3つの選択肢が考えられます。
価値観にマッチしているか?メンバーの自由度を妨げないか?何か問題が起きているか?という観点で、いかに扱うべきかを判断する必要があると考えます。
特に黙認する選択肢をいれることが大事だと思っていて、慣習を認める・認めないと明言することはルールを作ることと同義であり、メンバーに前述したようなストレスをもたらす可能性のある行為です。直近問題がないのであれば、あえて黙認することにも意味があると感じています。
なぜチームの文化を良いものにするのか?
チームの文化というものは、良くしたことで事業の利益に直接影響するものではないかもしれません。
また事業がうまくいってるときには、得てしてチームの雰囲気も自然といいものです。 逆に言えば、事業が苦難と対峙したときほどチームの雰囲気が悪くなります。
ここで考えなければいけないことは、チームの雰囲気が良いこととチームの文化が良いことは別であるということ。チームの雰囲気が良くても組織的負債は貯まっていく可能性があるということ。
なぜチームの文化を良くするのかと言われれば、それは事業を継続させより発展させたいから。
事業が苦難と対峙した時にどう切り抜けるか、チームが苦難にきちんと対峙できるようにしておく必要がある。
そのために普段からチームの文化のことを考えていなければいけない。組織的負債を溜め込み過ぎないようにしなければならない。
たとえ事業がうまくいかず雰囲気が悪くとも、それでも必死にチームとして事業に向き合っていれてるのであれば、そこには良いチームの文化があるのだと。そんな風に僕は思うのです。
Japan Product Manager Conferenceから感じ取った、プロダクトマネージャー19の職責と11の心構え
全体的な所感
今回参加したJapan Product Manager Conferenceは、プロダクトマネージャーという言葉が表すものはなんであるのか?という問いかけに尽きるなと思いました。
実務経験から得た知見や結果の考察、思考法やフレームワークをどのように取り入れているか、理想とする姿と現場としての課題感。様々な観点でのセッションがあった中で、会全体を通してプロダクトマネージャーの職責を言語化する、心構えを共有するという熱意みたいなものを感じ取れたからです。
以上の様な全体的な所感を前置きとしつつ、僕が感じ取ったプロダクトマネージャーの職責と心構えを整理します。さらにプロダクトマネージメントというものに対して、二日間何を考えたのかという構成で話をしたいと思います。
僕は前提としてプロダクトマネージメントというものは、事業領域や構成メンバー等によって独自文化を持つものである。それ踏まえて抽象化できるものや、一般論として話せるものもあるという考えを持っています。なので今回は、事業領域等を超えて一般化できることと感じたものを整理します。
プロダクトマネージャーの職責
課題探索
- プロダクトに懐疑的であり続けることが職責である
- プロダクトが解決する本質を探索することが職責である
- プロダクトの課題設定をすることが職責である
戦略立案
- プロダクトの理想像を言語化するのが職責である
- プロダクトの定性的な目的設定をすることが職責である
- プロダクトの定量的なゴール設定をすることが職責である
- プロダクトの成果を出すことが職責である
- プロダクトの好意・認知・配荷を向上をさせることが職責である
- プロダクトのリスク・阻害要因を取り除くことが職責である
構造化
- プロダクトの課題・目的・ゴール設定を理解・実行できる単位に細分化することが職責である
- プロダクトタスクの優先度付けすることが職責である
- プロダクトタスクを継続実施するための必要情報全てを整理することが職責である
- プロダクトの成果を理解できる単位に分解・翻訳することが職責である
組織作り
- チームメンバーの特性を理解することが職責である
- チームメンバーの課題や経験を引き出し、チームとして循環・還元させることが職責である
- チームメンバーのオーナーシップを支援するのが職責である
- エンジニア、セールス、マーケティング、デザイン、サポート、あらゆる部門と健全なコミュニケーションをとることが職責である
成果分析
- プロダクトが課題を解決できているかを分析するのが職責である
- プロダクトの成功/失敗を判断することが職責である
プロダクトマネージャーの心構え
- 権限ではなく戦略やビジョンを振りかざすべきである
- 自分やチームにゆとりをもたらす仕組みを整備すべきである
- 考えを徹底的に言語化して伝えるべきである
- 建設的な議論や問いかけをするための言葉を選んで使うべきである
- コミュニケーションのハブであろうとすべきである
- 公平性があるプロダクトより愛されるプロダクトを考えるべきである
- 面倒なことほど取り組むべき課題だと考えるべきである
- ルーチンワークは仕組みに置き換えれないかを考えるべきである
- 追加開発は、追加スケジュールとセットになるものだと考えるべきである
- エンジニア目線とユーザ目線は、対立するものではなく補完し合うものだと捉えるべきである
- 世界を見据えたプロダクトを考えるべきである
プロダクトマネージメントというものと二日間向き合って
カンファレンスの内容は、とても刺激をもらえ影響を受けるものが多かったです。
また開催期間中の伊藤直也さん言葉にとても考えさせられました。
改めて、プロダクトマネージャーに担ってほしいことはなんでしょうか?
思想家でしょうか?戦略家でしょうか?評論家でしょうか?プロダクトに関わる全てでしょうか? 僕はプロダクトを通して責任を負っていく役割だと考えるようになりました。 責任を負う過程というのは、人に足りないものを埋める動きをさせ、把握する範囲が広がっていき、思慮深くある必然性をもたらすのだろうと感じています。
加えて、数多ある職責の中でも個人的には物事を構造化できるスキルや経験値が重要視されると考えるようになりました。
難しい課題や大きな目標に対して、自分達が理解・実行可能な単位に分解できるかどうかが日々の成果に影響する。
売り上げ目標1億に対する成果10万をいかにして生むのか、予実をとれる単位が細かいほど大きな目標の予測値信頼度があがる。
大きな目標を達成するべくして達成することが、プロダクトマネージャーの責任を果たすと言うことなのかもしれない。
といったことが二日間を通して自分の中に残りました。
最後に少し話を変えて本を読む行為というものを考えてみます。本を読み続けていると書籍毎に点で理解してきたことに対して、一気につながって物事の流れや構造体をぐっとイメージできる瞬間があります。
経験される方も多い感覚かもしれません、あっこれは別の書籍でも近しい内容に触れたことがあるぞ共通解なのかな?だとするとあっちの矛盾はこっちで解決になるのかもしれない。のような体験です。
本質を探る行為というのは、例にあげた本で体験できる様な感覚。多角的な視点を用いて、もやもやしていた物事の構造体をイメージできるようにする行為であると考えています。
責任を負い、思慮深くなり、把握する範囲が広がる。副次的に物事を多角的な捉えかたをできるようになり、結果として構造体をより深く理解・説明をできるようになる。この流れをイメージできたことが、僕の中で一番の収穫でした。
運営の皆様、登壇者の皆様、会場でお話しをさせてもらった皆様、ありがとうございました。
工数見積もりとはラブレターである
前置き
システムを実装する上での工数見積もりで、どんなことを把握したいですか?
僕は個人にできるかぎり依存しない、事業価値を届けるために必要なコストを把握したいと思っています。
工数見積もりとは誰が行うものでしょうか?担当するエンジニア個人でしょうか?それともチームに属するエンジニア全員でしょうか?
僕はデザイナーや企画も巻き込んでチーム全員と関わりながら行うものであると考えています。
関係者全員で、絶対的な時間の見積もりではなく、相対的な規模感での見積もりをしていく。この辺りは所謂アジャイルな開発の思想に影響を受けているように思っています。
このような考えのもと、工数見積もりというものを通して
- 何がしたくて何がしたくないのか
- 各ポジションとどんな風に関わっていくのか
- 一番考えるべきことは何だと思っているのか
みたいなポイントで自分の考えをまとめていこうと思います
何がしたくて何がしたくないのか?
工数見積もりでしたいことはなにか?
- ユーザーにとって必要なものであることがイメージできること
- イメージ通りの機能を作りあげるために必要なものを整理すること
- 規模感の把握
工数見積もりでしたくないことはなにか?
- 実際にできあがったものが意図していないものになること
- 作業に入ろうとしたときにまだ動きだせない状態であること
- 未確定要素によって規模感すらだせないこと
こうやって改めて考えてみると、情報の整理からくるタスク分解と規模感を把握だけでなく、タスクの完了状態が与える影響がどんなものかもこの段階で意識したいのだなと思いました。
また着手時にすぐ動き出せるように、未確定要素を極力なくす調整もこの段階で一番とっていきたいと思えました。
各ポジションとどんな風に関わっていくのか
デザイナーや企画側に対して
デザイナーや企画側に対してはフィードバックをする、レビューの面もあると思っています
- どんなことをしたいのか伝わってくるか?
- 自分がユーザとしたら価値があると思えるか?
- タスク分解をイメージできるだけの情報があるか?
- やりたいことへのシステム的な解決はもっと良い方針がないか?
- これをやらないで別のことやったほうがよかったりしないか?
実装する側だから気づける点と想い、実装前段階ですり合わせていくことで出戻りを少なくしていければと思っています。
同じエンジニアに対して
同じエンジニアに対しては、いかに思いを伝えて共通のイメージを持つかが大事だと思っています。
- 他人がこの作業をするのならどんな情報が必要か?
- 新たに配属された人でもイメージできるだけの情報になっているか?
- 作業の実現アプローチは妥当なものか?
- 実現するための不明点はないか?
同じエンジニアだからこそ、スムーズに開発がスタートできるよう負担を軽減することになればと思っています。
一番考えるべきことは何だと思っているのか
やることの見積もりをするのはもちろんなのですが、僕は加えて一部やらない判断を提案していくことや、既にあるもの削除していくための見積もりこそ大事ではないかと考えています。
それは事業に対してエンジニアが一番主張できるポイントが、何を作らないのか?だと思っているからです。
やらないことが増えると、保守するコードが減ることになります。運用時のフットワークが軽くなります。
全ての企画を作るとこれくらいかかるけど、同等のこんな機能ならこれだけでできるよ?
企画のやりたいイメージをいかに、シンプルな機能だけで実現できるのか?そこを考えるのも面白いとこなんじゃないかなと思っています。
そういう意味で工数見積もりとは、事業を企画することに大きく関わる作業だと言えるだろうと考えています。
まとめ
作業担当する誰かに送る、精一杯の想い。色んな下準備をして、受け取る人に気に入ってもらえるように作る。さながらラブレターなんじゃないかと思っています(今回これがいいたかっただけかも)。
愛を持って工数見積もりをしてみませんか?きっと愛は届く!きっと。
おしまい。
チームのUXをマネージメントする
チームで仕事をすると言うのはどの様なことでしょうか?
メンバーはチームを通して何を感じ、他のメンバーに何を感じさせるのでしょうか?
今回はチームにおけるUXという視点で、何をマネージメントをすることができるだろうか?を考えます。
チームで仕事をする際のUXとは?
まずは僕の考えるチームのUXは何かを定義します。
チームを通して何を考え、どんな行動をして、どれだけの対価を得たり払ったりしたか。と言うことだと考えていて
- アドバイスをして、信頼を得ること。
- 成果が出て、自信を得ること。
- 失敗して、信頼や自信を失うこと。
例えばこのようなことがチームで仕事をする際のUXだと捉えます。
チームのUXをマネージメントするとは?
チームと言う体裁があったとしても、メンバーはあくまで利己的に行動を決定するものだろうなと考えています。
もう少し噛み砕くと共通の目標があってチームは結成されるわけですが、漠然と走っていくとメンバーは個人の利益を最大化させる行動を無意識に優先するだろうと思っています。
チームとしての利益という視点での行動をメンバーから引き出すこと、これがチームのUXをマネージメントするということだと考えています。
引き出すために何をするのか?
この本であげられている様な心理的安全をチームにもたらせるように先導していくことで、チーム利益のための行動が、個人利益のための行動と同等の価値を持つようにしていきたい。そのために何をするか?ということを考えていきます。
- どんなチームが理想なのか、どんなチームにしたいのかを伝える
- チームがメンバーに何を期待しているのかを理解できるようにする
- 実際に行動に起こすという体験をできるように手助けしてあげる
それぞれを見ていこうと思います。
どんなチームが理想なのか、どんなチームにしたいのかを伝える
僕の大好きなスライドを紹介して、まずイメージを持ってもらえればと思います。
ここで伝えたいことは、スライドの中に書いてある内容が正だ、これが僕の理想だということではありません。(個人的には好きで影響うけてます)
チームとしてどんなメンバー同士の関係性でありたいのか、どうあることがいいことだと考えているのか。それをメンバーに伝え、示すことが大事だと考えています。
もちろん理想を話すことはメンバー間で折り合えない部分もあると思っていて、それはそれで良いと思います。折り合えないよということがわかることで、対応できる余地が作れると考えるからです。苦手なら苦手なりの、付き合いかたを考えましょうか?となれれば僕としては儲け物です。
今後のチームとしての行動指針を一緒に考えていこう?という意思表示と、実現するためになにができるか考える、自分だったらもっとこうだと考える体験をメンバーとすることを狙いにしています。
チームがメンバーに何を期待しているのかを理解できるようにする
最近見て考えることが多かったワークショップの資料を紹介しつつ、こちらもまずイメージを持ってもらえればと思います。
「知っているだけで解決できる問題が世の中にはたくさんある」この言葉をなるほどな、そうだなーと思いました。僕個人としてチームメンバーに期待すること、思っていても正直あんまり言葉にしたことなかったです。
僕はこのスライドをみて、これって開発フェーズ毎と役職や職種って視点で分けて考えると、もっと具体的な業務レベルでの期待感の共有になるかもなと思っています。
企画立案時には、エンジニアは企画者にどんなことを期待してるのか。その逆はどうなのか。実装時には企画立案時とは別の期待がメンバーに生まれるのか。ユーザエクペリエンスマップのペルソナをチームメンバー、フェーズを開発のフローに当てはめてみてワークショップ等企画してみることで、チームの相互理解が深まるのではないかと思っています。
チームメンバーがお互いに期待していることを把握することで、今のタイミングではこんな行動してほしいのかな?と考える体験をすること、プラスの対価を得る行動はこうなのかもな?と感じてもらうことを狙いにしています。
実際に行動に起こすという体験をできるように導いてあげる
これは最近よく感じていることで、不安や困ってることを言える雰囲気作る、心理障壁を減らすってことを実践していくには、メンバー個々人が実際に想いを口に出す体験を何度したかが大事だと考えています。
やはり自分にとっての印象を悪く捉えられそうなことを口に出すのは、抵抗感があるものです。新規参入したメンバー等であればなおさら。
なので最初は聞き出す努力がいる。
丁寧に自分で口に出すって行動までを引き出してあげることが、何でも言える雰囲気を育てていくことに繋がるだろうと考えています。開発してて困ってることある?といった聞き方ではなく、この開発だったらこんなとこ困りそうに思うんだけど大丈夫?
と言った様な少しつっこんだ聞き方をすることで、個人としてマイナスの対価を得ると思われがちで嫌厭される行動を、起こしやすくしてあげられないかを狙いにしています。
まとめ
チームとしての利益という視点での行動をメンバーから引き出すために、心理的安全をチームに熟成させたい。それをこんなアプローチでやっていきたいと思っています。どうしてそうしたいと考えてるのか?と言う観点で書いてきました。どこか参考になるところがあれば幸いです。
おしまい。
エンジニアが経営理念について考えた話
前置き
経営理念ってなんでしょう?ミッション・ビジョン・バリューってなんでしょう?様々な会社が掲げています。社内に浸透させようとしています。
僕は今まで5社ほど勤めてきたなかで、正直一度もキチンと意識して働いたことはありませんでした。それは僕自身が必要としてなかったからなのか、会社としての伝え方の問題なのか、最近ふと考えてみたという話です。
経営理念って何?
経営理念とは、組織の存在意義や使命を、普遍的な形で表した基本的価値観の表明。
平たく言えば、「会社や組織は何のために存在するのか、経営をどういう目的で、どのような形で行うことができるのか」ということを明文化したものである。
これによって経営者は、基本的な考え方を内外に伝えて共有化したり、社員に対して行動や判断の指針を与えたりすることができる。理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる。すなわち経営理念は企業文化を形成する主要な要素である。
経営理念の内容は、行動規範的なもの、経営の成功のための鍵や経営姿勢を示すもの、企業の存在意義を示すものなどいろいろな形で表現される。一般的には、社会、顧客、および社員の三者に関する理念が設定されることが多い。
経営理念が難しいのは、適切な設定をしても時代とともに形骸化し、現実と乖離してくることである。どれだけ優れた経営理念やビジョンであっても、その変更のタイミングを見極め、時代に合わせて方向を再設定、再定義して、新たな道を踏み出さなくてはならない。
経営理念とは | ビジネススクールならグロービス・マネジメント・スクール より引用
なるほどなるほど。
とても大事なことなんだな、ということは理解できました。
と同時に僕はこうなんじゃないか?と思う点がいくつかあったので、章に分解して整理してみたいと思います。
理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる
理念自体に共鳴できる人はどれだけいるのだろう?単純な疑問をこの一文から持ちました。 というのも今まで理念に共鳴するからここで働きたい、と思えたことが僕自身なかったからです。
それはなぜなのか、というのを自分の中で解釈すると「自己の会社や組織は何のために存在するのか」という視点で普段想像や仕事の一端を見ていなかったからだろう。と言うところに落ち着きました。自分が普段考えていないことに対して、共鳴するということは起こりにくい。
ではそんな僕が経営理念として共鳴しえるものはなんだろうか?と改めて考えてみると、自分の考える1個人としての社会的な存在理由にぴたりと合致するケース。もしくは内容自体が重要ではなくだれが言葉にしたのか、魅力をもった人物が作った言葉には自分から寄せていって共鳴したいと思えるかもしれないなと考えます。
実際僕はどこで働きたいかよりも誰と働きたいかで職場を選択してきたので、自分が働く上で大事にしているものが改めてそういうことなんだろうなと再認識しました。
とこんな流れで考えた結果、理念自体に魅力を感じる人はいないことはない。けれど組織にいる理由の大半は個人レベルでの魅力、プロダクトに対する魅力に共鳴したからなのかもしれない。相対的にみて理念自体に共鳴する人は少ないんじゃないだろうかという考察に至りました。じゃあ僕の考える経営理念の必要性って?というところは別の章やまとめにて。
考え方を内外に伝えて共有化
僕はここを重要な一文だと捉えました。内外っていったい何を指すのでしょうか?
僕は内が組織や社員、外が社会や株主といったものを指しているだろうとそれぞれ考えています。
ここでさらに踏み込んで考えなければいけいないことは何でしょう?僕は内と外で期待するものが違うだろうという点を考えなければいけないのではないかと思っています。内外をひとくくりにできるような言葉ってどんなもの?むしろそれぞれに向けた言葉を別で用意すべきものなのではないか?
そもそも経営理念ってどんな風に考え始めるのか?と想像してみると、経営理念には創業メンバーの強い起業動機、社会に向けた意思表示の面がやはり大きいと感じています。つまり外向きに寄せた言葉を設定することが多いなと思っていて、そもそも内向きにも響くようにとするのは難しいのではないか?という疑問を持ちました。
その解釈持って、経営理念を表す際にミッション・ビジョン・バリューと複数用意されているのはどうしてか想いを巡らせると、なるほど向き先の違う言葉を定義してるのかな?という見方をすることができました。
また最近知った言葉でインナーブランディングというのがあるので取り上げるのですが、こういう内向きに対しての明示的な言葉が存在することからも、向き先に合わせた言葉の作り方が意味を持っている。内外に伝えるというのは単に同じ言葉で表すことではないな、と考えるようになりました。
インナーブランディングは、インターナルブランディングやインターナルマーケティングとも呼ばれ、社員に企業ブランドの価値や目指す姿を理解させる啓蒙活動が起源です。消費者などに対して自社のブランド価値を啓蒙するアウターブランディング(エクスターナルブランディング)と共に、ブランド構築活動を構成する重要な要素のひとつです。
社員に対して行動や判断の指針を与えたりすることができる
エンジニア目線で見た場合、経営理念に一番重要なのはここだろうと思ってます。組織としての正解はなにか?現場での判断に困ったときに基準となるものはどんな想いなのか?それが明確であることは、最も会社が社員に浸透させる意味を感じれます。
経営理念の元、僕はこの企画や実装を採用することが正解だと判断しました。なんてことを社員が言うことを願っているのかな?と想像することもできます。
このへんの解釈で、僕の中にすっと入ってきた言葉を引用しておきます。
大事なのは、 その企業が目指しているものを従業員に理解してもらうことで、 従業員の仕事に方向性と目的を与え、さらに従業員が意思決定をするときの ”判断基準”になるように落とし込み、それによって企業を成長させることなんですね。
As I Am. | 有名企業から学ぶ;ミッションとビジョンの違い より引用
判断基準になるレベルまで落とし込むことを目標にし、結果として企業としての成長を得たいのだな。なるほどなーと腹落ちしました。
まとめ
自分の考えをまとめると経営理念というのは、経営者や企業としての内外にむけた意思表示である。
社員目線でみると、日々の業務レベルにおいて判断基準の1つになり得るものである。
外向きには企業としての存在理由、内向きには組織の行動指針として必要なものである。
各社想いや狙いがあって作るものであるとは思うけれど、僕個人としては誰に向けた意思表示なのかという観点を明確にして設定されていたほうが、浸透しやすくなるのではないだろうかという考察になりました。
経営理念なんて理解しなくても、仕事はできるのかもしれないし僕はできてきました。
けれど判断基準になりうるものだというのを解釈できると、理解する必要性があると考え方を変えることになったのはよかったです。
チームで働く上で、同じ価値観・判断基準というかが皆で共有されていると、スムーズな連携がしやすくなることを実感しています。
経営理念ってくくりで受け取ると大層なことに感じますが、このことって事業単位、数人のチームにおいても共通に言えることだと思ってます。一緒に集まってなにかを作っていくって時には、チームとしてそれをどんなものにしたいかって意思表示を明確にしておき、個々人の判断基準になるくらい浸透させること。考え方の粒度や視点の違いはありますが、大事にいきたいですね。
ということで経営理念に共鳴して働きたい!となる人は考えた後も稀だろうと思ってますが、経営理念を社員に浸透させる意味は理解できました。
経営理念の理解は大事、理解してきましょう。
おわりに
組織論とか、チームが機能する仕組みづくりとは?
みたいなのが最近の勉強のテーマなのでそういうの好きな人とか、マネージメント層・経営層の方で話聞いてあげてもいいよってかたは是非機会を作らせて下さい。