技術力評価のトライアルをチーム内でやってみたまとめ

はじめに

先日 Voyage さんの 再演: 技術力評価は難しい？ に参加してきました。 それをみて弊社でもやってみたいと思ったので、とりあえず上長に許可を取りチーム内でトライアルとしてやってみました。

とりあえず条件はこんな感じ

  • 評価者: 私 + 被評価者が望むなら他の評価者をいれてもよい(ただし自分で調整する)
    • 実際は誰も他のヒトの調整がなかったので私1人でした
  • 被評価者: 10名
  • 社内 gitlab の計画リポジトリに「技術力評価」というラベルを貼って pull-request (どうでもいいですが gitlab はなんで merge-request なんだろう)
    • トライアルなので評価して欲しい項目/特に評価者のことを考えて「自信がある pull-request / プロダクト」のリンクや社外発表を記載してもらった
  • 時間の都合で30分の面談 (Voyage さんは最低2名で1時間半)
  • 面談終了後 merge-request のコメントに講評を書いて、上長に連絡
    • トライアルなので今回は「参考」と言うかたち、「評価のバイアスがかかるかもしれないくらいにしておいてね」とのこと
  • 技術力評価トライアル完了後にアンケートを回収 (アンケート項目については後述)

評価に際して

  • キャリアマップ
    • キャリア・アンカーをベースとして、技術に対する指向、姿勢を 3 (技術獲得・技術活用・技術管理) x 3 (挑戦・自律・安定) で分類したもの
  • 「採点」が目的ではなく、成長につながるような指摘やサジェスチョンをすることを主眼にした
    • 「ここができていないので、こういう風にやるとよい/このヒトが得意だから師事するとよい」とか「これはできてるんだけど、こういうこともできるとすごく信用できるようになる」とか

評価観点

  1. 価値観点
    • QCD / 技術起点の新規価値 / 迅速改善フレーム / 市場インパクト
  2. グレード
    • トレーニー/一般/上級/リーダー
    • これは初期、明記してなかったけれど、面談が進むに連れて評価観点に入れた

技術力評価をやってみて(評価者観点)

  • 面談の時間は30分なら大したことはない
  • 事前のレビューがとにかく大変
    • なんだかんだ1人あたり最低30分、長い場合だと1時間半とかかかる
    • merge-request の場合は、コミットメッセージ自体・内容を表現しているかとか、実際のコードを見ればよいので楽
    • プロダクトの場合は、その全体像を把握するところから始まるので目を通す範囲がでかい
    • 自分が得手ではない言語の場合はパッケージ管理とかそういうところから始まるし、見たことがないモジュール (テストフレームワークとかもある) の使い方を調べて可読性や利得(テストを書くべきかどれくらい書くべきか)を見たり、そもそも言語の地域方言とか慣習を調べるところから始まるのが相当コスト高い
    • 中にはミドルウェアが含まれているものとかがあったりして、そうなるともう地獄
    • 大変だけど、これこそが納得力の源泉でもあると感じてる。あえてやるなら、1人で10人とか見ないような座組を考える
  • 最初、価値観点だけを想定していたんだけど、2年目の新人とかもいるとそういう観点ではまだ評価できないことが見えてきたので、グレードに応じてコメントするようにした

技術力評価結果アンケートの項目とまとめ

項目 1をつける項目 平均スコア 5をつける項目
今回の技術力評価の満足度を教えてください 不満足 3.9 満足
技術力評価自体の取り組みは継続してほしいですか 希望しない 4.2 希望する
評価者は適切でしたか 不適切 4.1 適切
評価者の所属について 自部署を希望 3.4 他部署を希望
評価は納得性がありましたか 納得していない 4 納得できた
評価者の人数は何人がよいですか 2
面談時間はいかがでしたか 短い 2.6 長い
フィードバックは成長につながると感じますか 感じない 4.2 感じる
事前の面談シートの記載量はいかがでしたか 少ない 2.8 多い
公開で実施することはいかがでしたか 非公開を希望 4.6 公開を希望
定量的な評価(例えば点数)を希望しますか 定性的 3.1 定量的

まとめ

  • 取り組みとしては満足している、また継続を希望されていることがわかったのでやってよかった
  • 評価者は2人希望していて自部署と他部署1名ずつの希望されていた
    • 協力者(評価ができるヒトリストを作る必要があるなぁ
  • 事前のレジュメ記入量/面談時間については適切 (m-r で送り、30分間の面談)
  • この中で最も最高点だったのが「公開でのやり取りを希望する」というのが非常に驚きだし、心理的安全性が担保されてる一つの現れとして見えてとてもうれしい
  • 定量的な数値も欲しいと感じている。これはやっぱり難しいところだけど希望する人がいるので、なんか考えることが宿題
  • 「評価者もまた評価されている」という言葉通り、すっごい怖かった。けど、アンケートの結果をみて胸をなでおろした

  • 技術力評価に納得いってないってメンバがいたんだけど、その後にもう一度フィードバックをして、納得行くまで話すことができた。トライアルはこういうのがホント大事だと思っているので、そこまで含めて、トライアルやってよかったと思う。

今後について

  • キャリアマップをもっと活用して技術獲得・技術活用・技術管理それぞれの指向に対して、それぞれグレードを定義したい
    • 例えば技術活用の場合は「タスク(ストーリ)を任せられる」「プロダクトを任せられる」「俯瞰的なプロダクトアーキテクチャができる」とか、なんかそういうやつ
  • 評価者のリストを集めたい
  • 評価者を評価する座組も欲しい

再演: エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ に参加しました

connpass.com

参加しました。

エンジニアの技術力評価は難しい? @makoga

  • 自分のアウトプットをテキストにまとめる技術
  • 1時間半で説明する技術
  • 「どういう会社にしたいか」を経営層とディスカッションした(事業・サービスの理解度、プロジェクトごｔの要件・制約の理解度)
    • グレードの高いエンジニアは「理解度が高い」
      • これを文化として根付かせたい
  • 短期的なアウトプットをもとめると優先度が下がりがちな「セキュリティ」「テスト容易線」は重要視したい
  • 点数とテキストの両方で評価結果をテンプレ化
    • ルールで縛ることも考えるが、「ルール守ってるんですが」のような思考停止をさせないことが大事

2年やって

  • 実現力と改善力
    • 実現力: スコープ定義/システム構築/プロジェクトマネジメント
    • 改善力: システム的な改善/ビジネス的な改善
  • 用語から文章に変更した
    • 「妥当か？」とか
  • コードレビューから「事業を支える技術」という本質的な議論ができる場になった
  • 評価をオープンにすることで評価者が真剣に取り組むようになった「評価者もまた評価されている」
    • 点数をやめて、納得するようにコメントを書くようにした

制度を改善するコツ

  • 企業文化や戦略に基づきながら改善
  • ケツ持ちを明確にする (CTO が死ぬ)

パネルディスカッション

  • @t_wada (モデレータ)
  • @teppeis
  • @mirakui
  • @makoga

まとめ

新規フェイズ(0➜1)なのか、成長フェイズ(1➜10)の組織なのか、運用フェイズ(10➜1000)の組織なのかで全然違うと思うし、組織が抱えるスペックが育成なのか力を発揮するフェイズなのかにも依存するから、自組織と向き合ってフィッティングしていく能力が求められると思う

組織が「ヒトを投資対象としてみるか」「コストとしてみるか」が大きな分岐点で、人材育成に対して「費用対効果」を問うか、「当然すべき手続き」として捉えるかでその姿勢を見ることはできると思う。有りがちなのが組織としてではなく、声のでかい既得権益を持ったおじさんがそれを問うてくることがあって、そのおじさんをなぎ倒す方法はまた一つじゃないから難しい。

その一つの方法として「な、これだけ改善しているんだから、価値あるんだよ」を定量的に見せるのはわかりやすい方法だとは思う。 本質的に、 @katzchang さんがおっしゃっていた「成長を促す行為と実際に促された」ことだけを定量化すればいいとは思う。

(「項目くらい採点基準が明確じゃない人事評価」にもかかわらずそもそも「その技術的な観点での採点の基準て適切なの？」ってのを聞いてくるおじさんはいろいろなぎ倒したい所存

オープンなことは組織成員が許容できるのであれば、本当に素晴らしい効果があると思う。 たぶん、今後考えていかないといけないのは、「では、どのようにすれば、オープンなことを許容できる組織になるか」だと思うし、1つの指針としては心理的安全性だったりだとは思う。 この心理的安全性を実現する方法自体もまた、組織のフェイズ・規模・スペックに応じて変わってくるから、適切なメソドロジを蓄積していくことが、人事・マネージャの仕事だと考えている、というところで勉強になった。

完全に技術系のキャリアタイトルで混乱している

技術者のキャリアパスを考える上で昨今様々なタイトルが取り上げられ、議論されているのですが、さて、自社で適用しようとすると、完全に混乱しています。 もちろん、自分がやっている内容は理解しているのですが「はて、仮に自分にタイトルを付けるとするといったい何者なんだろう？」となってしまっています。

2017/02/21 12:40 追記 職位を作る実際の手続きの中の1つである職務章程の整理を考えだしたときに止まらなくなったものです。

タイトル

  • VP of Engineering
  • CTO
  • CIO
  • Engineering manager
  • Product manager
  • Technical Lead

関連する非技術者タイトル

  • Project manager: プロジェクトの責任者
  • Line manager: 組織の責任者

ランク

  • Chief
  • Principal
  • Senior

Wikipedia や各種資料からの情報

Project manager

  • 系統的な経営管理能力は勿論、透徹とした質問を発し、暗黙の前提を発見し、プロジェクトチームの意見をまとめ上げる wikipedia
  • プロジェクトの実行に影響を与えるリスクを認識することと同時にそのリスクをプロジェクト期間を通じて公式・非公式に見積もらなければならない
  • やること
    • プロジェクトの総合的な責任者である事も。プロジェクトの進行およびプロジェクトの成果に責任持つ。
    • 決められた範囲内や予算内でプロジェクトの進行の為にメンバーと論議し利益を上げる為の明確なビジョンを造り、目標達成に向けてプロジェクトを進行させていく。
    • 誰が何をやるかといった指導を行うだけでなく浮き上がって来た課題の整理整頓も行うが、いかに用意周到に事前の検討を行ったとしてもすべてを正確に識別して対応策を用意する事は実質上不可能である事を前提にし、損害を出さないよう速やかに自ら対応策をその都度実行していかなくてはならない。
    • 論議そのものはプロジェクト全員が行う作業であるのでマネージャの専有業務ではないがその際に知りえた情報を自分だけに留めず、その都度プロジェクト全体で情報を共有する様にする役割をも持ちプロジェクトのメンバーからの意見を汲み上げ円滑に進められる様にプロジェクトの改良をしながら成果を出す事が求められる。
  • 英語版wikipedia
    • 明確かつ有用かつ達成可能なプロジェクト目標の定義と伝達
    • プロジェクト目標を達成するために必要な労働力、必要情報、様々な合意、材料、技術などのプロジェクト要件の調達
    • コスト 、 時間 、 範囲 、品質であるプロジェクト管理三角形の制約を管理する

Line manager

  • 利益事業部門の責任者であり、組織の主目的の達成のために、意思決定、目標決定などを実施する 参考
  • 垂直（コマンド・チェーン）および/または特定の製品ライン上で権限を保持します。 特定の機能領域または事業部門で企業目標を達成することを担当 wikipedia
  • 従業員のエンパワーメント、トレーニングと開発、モチベーション、組織開発、チーム構築、メンタリングなど、組織の主要機能を担う
  • 組織の目標や目標を達成する機能を担う
  • ラインマネージャの役割と課題
    • チームの役職に就くための才能を募集し、雇う。
    • 新しい人材の訓練と支援を提供する。
    • ジョブのローテーションを確実にし、割り当てのカバレッジギャップを最小限にするために、 従業員をクロストレーニングします。
    • すべてのチームメンバーにコーチングとパフォーマンスのフィードバックを提供します。
    • 機能的または部門的目標の理解と伝達の伝達。
    • 個人およびチームのメトリックとパフォーマンスとターゲットの監視。
    • 是正措置の必要性の特定
    • すべてのプロセスの品質基準を保証する。
    • 全体的なチームと個人のパフォーマンスを評価し、パフォーマンスレビューを提供します。
    • 組織内の他のラインマネージャーとの連携。
    • 生産性やその他のパフォーマンス指標に関するレポートを経営陣に提供する。

VP of Engineering

  • 製品の開発と納入、チームの募集を担当しており、チームの最善の開発者である必要 Joyent
  • 製品の開発と提供を担当する
  • チームの募集
  • 非常に技術的な役割（通常これは技術的ではなく、より多くの人が志向していると考えられています）。 彼らはすべての開発者が彼らが行くことができると感じるモデル市民です

CTO

  • 新技術の開発を監督することによって組織の問題を解決する wikipedia
  • 技術に関連する以下のような役割を持つ wikipedia
    • 短期間の（戦略的な）技術的方向性決定
    • 研究開発のビジネス的な監督
    • 企業内でのソフトウェアの利用
  • Joyent
    • 技術的な先見性があり、イノベーションはどこから来ているのかを中心
    • ビジョンと文化を検証するために必要な技術的なものでなければなりません（つまり、企業のビジョンが実際に達成できることを保証する）
    • 技術文化を設定する
    • 技術と外界との関係を理解する必要がある
    • 主に外向きで営業サポート
    • 製品の配送を所有していない
    • 残りの会社と理事会が何が起こっているかを知ることを保証する

CIO

  • 既存のテクノロジー（特にITの性質）を取得して適応させることによって組織の問題を解決する wikipedia
  • 情報戦略やIT投資計画の策定などに責任を持つ wikipedia
  • 情報システム部門の責任者とは独立して設置し、チェック機能を持たせることで情報の漏洩を防ぐことが望ましい
  • 個人情報保護法や頻発する情報漏洩事件への対処のみならず、平素から、「行政手続における特定の個人を識別するための番号の利用等に関する法律」に基づく企業における個人番号管理の責任者として機能する。会社法、金融商品取引法に準拠した内部統制を構築・運用するうえで中核的な役割を担うことになる。

Engineering manager

  • エンジニアリングの技術的問題に精通し、経営の組織的、管理的、計画的な能力を結集して複雑な企業を構想から完成まで監督する [wikipedia]
  • オペレーションマネジメント、オペレーションリサーチ、サプライチェーンマネジメント
  • テクノロジーの管理
  • 新製品開発と製品エンジニアリング

Product manager

  • 参考 Japan Product Manager Conference 2016
  • 最高レベルの経営幹部からプロダクトビジョンを開発チームおよび実装チームに伝える [wikipedia]
  • ユーザーのニーズを満たす製品が確実に提供されるようにするためのさまざまなアクティビティーを調整する [wikipedia]
  • ※ さまざまな職務や責任を明確に説明するために多くの意味で使用される (ファッ？
  • Development / Users / Business を3スクミで睨む

Technical lead (wikiには不在で Lead programmer がでてくる)

  • ソフトウェアプログラムの基礎となるアーキテクチャーに責任がある wikipedia
  • プロジェクトで作業している他のソフトウェアエンジニアによって行われている作業を監督する
  • リードプログラマーは、通常、新規または低レベルのソフトウェア開発者またはプログラマー 、ならびに開発チームのすべてのメンバーのためのメンターとしても機能する
  • プログラマーと管理者の間のインターフェースとして機能する
  • 開発計画の所有権を持ち、作業を委任し、ソフトウェアプロジェクトが時間と予算の下に来ることを保証する
  • リード・プログラマーは、経営陣の技術顧問を務め、要件に関するプログラミングの視点を提供します

比較記事

Project manager vs. Line manager

  • プロジェクトマネージャーのような一部のマネージャーは、他の従業員の作業を指揮する責任がありますが、それらの個人の管理運営には責任を負いません。 彼らは従業員を懲らしめたり、昇進させたり、降格させたり、給与を調整したりしません。

CTO vs. VP of Engineering

  • CTOは技術的な先見性があり、イノベーションはどこから来ているのか、VPエンジニアリングは人を中心とした役割であると考えられています。
  • CTOはビジョンを検証し、技術文化を確立し、外界との関係を理解するために必要な技術的なものでなければならないと感じています。VPエンジニアリングは、製品の開発と納入、チームの募集を担当し、チームの最高の開発者でなければなりません。

まとめ

(今後、別エントリなどでまとめるかも)

  • Project manger はメンバの指揮責任はあるが、評価は含めない
  • Line manager は評価/エンパワー/管理を実施する
    • この意味では diff line_manager engineering_manager = tech っていっても良さそう
    • つまり、「技術組織における」 Line manager = Engineering manager
  • Engineering manager にメンタリングの責務は入ってない！
    • 技術的問題の精通と経営にもコミットする
  • CTO は文化とイノベーション/新しい技術の責任者
    • Vision を描く
  • CIO は既存の技術やIT投資の責任者
    • 直感的に持ってた「守備的な IT 人材のタイトル」といってもよさげ
  • VP of Engineering は人材にフォーカスをあてながら、最善の開発者！(最善 == 最高 ?)
    • 人材の育成にフォーカスを当てる面では Line manager もある
  • Product manager は Development / Users / Business を睨む
    • プロダクトとプロジェクトの境界面は？ 「プロジェクト=プロダクト+営業+マーケティング」という説もある
  • Technical lead はアーキテクチャに責任がある

参考リンク

www.slideshare.net pmconf.jp

人事 to IT カイギ #01 に参加してきた

参加してきた

jinji-to-it.connpass.com

3行 (僕の中の

めでたい

@meso 出産おめでとう！

登壇者

  • 藤本 真樹 (@masaki_fujimoto) @gree
  • 庄司 嘉織 (@yoshiori) @cookpad
  • 清水 俊博 (@meso) @dwango

ふじもとさん

  • ソフトウェアがからまないことはないよね
  • 38歳 なんで人事か？
  • HR の作業はいろいろあるし、3回おなじことやるんだったらシステム化できる
  • 人事はハードコスト高い

やったこと/めざしていること

  • 人事機能のサービス化
  • まずはデータ集約から
    • 「ある人が、同じチームに何日いるかをすぐ出せるヒト？」 会場シーン
    • ジョブローテを自動化する仕組みとかあるといいよね。
    • 人事が「より人間しかできない仕事ができるようにする」
  • ACL 問題については悩みが尽きない
  • ハードスキル(人事の)も欠かせない
    • 法律も変わるし・・・

おもしろい

  • エンジニアリングの観点で HR はとても楽しい

よしおりさん

  • 最初は断った
  • 当事者になれるチャンスを逃すのはもったいない (任天堂 岩田社長)

http://www.1101.com/president/iwata-index.htmlwww.1101.com

  • 人事の IT 化？
    • そうじゃない
    • IBM Kenexa
      • Watson を使ってる

やったこと

  • 現地にいって海外チームとの連携
  • インドとかでの新卒通年採用
    • カースト制度ができたときに、 IT 系はなかったので、誰でもなれる！インドでのし上がるためには IT 系しかない
  • コアタイム廃止
    • 昔は裁量労働制だった (エンジニア、デザイナ、企画職) けど、バックオフィスはできなかった
    • じゃあ、フルフレックスに全員した
    • エンジニアを神聖化しない
  • エンジニア採用
    • 「手伝って下さい」はあくまで「手伝い」
    • 当事者にならないと、手伝いになっちゃう
    • 2018年度の新卒採用選考エントリ
      • gist で yaml を書いて、それを html にするコードを書いて提出しろ
      • 内容もわかるし、コードもわかる！github のアカウントも収集できる！
  • システム入れ替え (勤怠システム辛み)
    • いろいろ口出せるのはよい

学んだこと

  • ミスは絶対許されない
  • 正常に遂行して当たり前
  • (SREなどの)インフラに近い感覚
  • DevOps や Infrastructure as a Code の思想的に近いかも

meso

  • kwappa さんとよしおりさんが説明している
  • 「@meso はコミュニケーションをしている」

パネルディスカッション

  • 人事マスタの難解さと他システムからの参照回数の多さにより、んごごご
  • HR テック、1) IT 化と 2) ヒトができなかったこと(うまくできてない最適化など)の2つに分けて前者をやるだけでも楽しいよ(少しやったりしているのでよく分かる
  • エンジニアが人事部長になったから非エンジニアが冷遇されると思ってる人たちの中にあるのはいいようのない劣等感なんじゃないかと思ってる(僕は)
    • 紐解くと、「全業種が ICT 化に向かっている中でできないこと」が広がっていることに対する焦りが全職種であるんだろうなと邪推したりしなかったり

  • Dwango や一休は別だと思うけど、 kaizen や GREE や Cookpad はそもそも「エンジニアが強い(営業/企画と少なくとも同等)の企業なのでその中で「エンジニアを厚遇したらハレーション起こるだろ」というのが感想。そもそもそういう意見が出る会社のエンジニアは恵まれてる。
  • Google はいろんな人事制度を変えたりできる背景にあるのは「生産性を可視化」できているから。これは冷静に考えたらすごくすごい

うちは冷遇されてません

  • 冷遇されないようにしている途中です！
  • 厚遇されているわけではないです！
  • エンジニアだけ、とか、企画だけ、とか、営業だけ、とかクッソくだらないセクショナリズム発揮してる暇があったら全社が1つの組織として With Us, You Can すればいいと思ってます

KPT をチェックリストに昇華させると無駄なく知識が蓄積される

KPT やってますか？ KPT やっても割りと無駄なこと多いですよね？ KPT はチェックリストに昇華させると、捗るぞ！という話です。

KPT ?

KPT については以下の各社の取り組みを見てください

kuranuki.sonicgarden.jp

http://engineer.wantedly.com/2015/04/01/sync-kpt.htmlengineer.wantedly.com

端的にいうと振り返りを行い、取り組みを改善するためのフレームワークです。 下記のように3つの項目を皆で出し合い、

  • KEEP: 取り組みの中で良かったこと
  • PROBLEM: 悪かったこと
  • TRY: 次に活かしたいこと

KJ 法 などによってまとめ、チーム間の意識をあわせつつ、取り組みを継続的に改善していきます。

私のチームやワークグループ、技術戦略委員会でも継続的に実施しています。

KPT あるある (課題)

  • TRY が抽象的
  • TRY の主担当が決まらず、結果、 TRY されない
  • PROBLEM が「まあ、しかたがないよね」と放置される

(本論) KPT をチェックリストに昇華させる

上記のような課題があり、スクラムマスターなどの誰かの属人による「運用でカバー」を避けるために最近は「チェックリストへの昇華」を促進しています。

具体的には、

  1. KPT を実施する
  2. PROBLEM を TRY に昇華させる
  3. KEEP / TRY をチェックリストにする

とし、ドキュメントとして管理する。

こうしておくことでなにか必要になったときにチェックリストとして残っているのでそれにチェックを付けながら実施することで、漏れや懸念点を意識しながら進めることができます。

効用

  • チェックリストにしようとすると、どうしても「実現できること」に落とし込まなければならないため、抽象的な TRY を作りづらく成ります
  • 担当はそれのチェックリストの利用者なのでそもそも考えなくてよくなります
  • PROBLEM をチェックリストの項目にするので、「まあ、しかたがないようね」がなくなります

余談

弊社では #nobolycloud のおまけパートでも話しましたが、gitlab を利用し、かつ、私のチームは「ラベル」を重視し、wiki や git 管理の対象のファイルではなく、 issue でいろいろなドキュメントを管理しています(これが正解とはいっていない)

f:id:muddydixon:20170113085022p:plain

issue board でみるとこんな感じで「チェックリスト」を一覧で見ることができるので、なにか必要になったときにはこれを利用する事ができます。

また、うちのチームは自作の gitlab issue を使った KPT ツールがあるので、

  1. KPT issue を立てる
  2. コメント欄に各自が KPT を書く
  3. ツールを使って issue の本文にアグリゲート
  4. 読み上げ/説明しつつ、 issue の本文に KJ 法などでグルーピングしつつ、 PROBLEM を TRY に昇華

が気楽にできるようになっています。

後は公平にジャンケンや練習を兼ねて若手にチェックリスト化してもらえばナレッジを再利用可能な形で蓄積することができます！ yummy!

With Us, You Can というコーポレート・メッセージについて思うこと

poem

弊社はコーポレート・メッセージとして「With Us, You Can」を掲げています。

www.nifty.co.jp

結論は「僕はこのコーポレート・メッセージが大好き」だ。です。

「ニフティグループは、お客様、株主、社員、パートナー企業、地域社会等の夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として、新しい価値の創造に取り組み続けます。」と堅苦しく書かれていますが、つまるところ

  • 自社単独でやるよりも、多くのステークホルダーと一緒に仕事をする方が大きなことができるし、その結果としてより広い社会的な貢献ができるから
  • ぶっちゃけリスク減るし、メリットあるし ( muddydixon 解釈

プラスアルファとして後付で「パソ通時代はパソ通の個人・法人ユーザの足回りとして」「ISPでは個人・法人の足回りとして」「クラウドではICTビジネスを立ち上げたい/成長させたいお客様の足回りとして」の役割を担ってきたからより強いメッセージになった、というのがあるかと思っています。

コーポレート・メッセージとは

コーポレートアイデンティティ - Wikipedia

Wikipedia を確認すると、

コーポレート・アイデンティティ (以下 CI ) は、企業が掲げてきた理念や事業内容、また企業の社会的責任 (CSR) 等に基づいて自らの存在価値を体系的に整理し、改めて定めた理念やそれに基づく行動指針を企業内外で共有することでより良い企業活動を行っていこうとするもの。またそれを実施するための計画である。 主に社会における企業イメージの構築を行うために計画・実行されるが、企業内部においても価値の共有による意識の向上、また品質や生産性、就職希望者の増加などの効果が期待できる。

役割はいくつかあるとは思いますが、大別すると

  1. 企業理念/存在価値の体系的な整理
  2. 上記や上記に基づく行動指針の内外への共有
  3. 企業イメージの構築(ブランディング)
  4. 企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する

Wikipedia ではこれらをまとめてCIの3つの構成要素としてまとめてあります。

理念、それに基づいた企業活動という行動、(情報の伝達経路で大きな割合を占める視覚的な)イメージ・デザインを統一する事が大事だとあります

内部ガバナンスにおけるコーポレート・メッセージ

チームマネジメントの観点で、非常に重要かつガバナンスのためのツールとして重要視しているのは特に「企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する」です。

知識創造企業の中でも(意訳が含まれていた場合には申し訳ありません)、トップがビジョンを示し、ミドルマネジメント層はそれを具体的にブレークダウン/解釈し、最前線の価値観を説明・共有するとありましたが、重要なことは

  1. ミドルマネジメント層に自事業における「解釈」「具体化」の幅を持たせる
  2. 共有化(体験としてイメージしやすく)しやすい
  3. 様々な知識の中でどれを「価値」として判断するかの、正当化基準として機能する

だと考えています。

知識創造企業

知識創造企業

これらを整理すると

  1. 価値の基準点としての機能
  2. 解釈の多様性
  3. 共有しやすさ

こういった観点で他社のコーポレート・メッセージ/コーポレート・アイデンティティを眺めてみると

コーポレートスローガン一覧 - NAVER まとめ

(こういうまとめは最近話題の記事の盗作でなくて手間を掛けての本当の価値だと思っています)

キッコーマンの「おいしい記憶をつくりたい。」、バンダイナムコエンターテイメントの「アソビきれない毎日を。」などは、価値のグラウンディング(正当化・基準点)、イメージがし易い、そして何より「解釈に幅がある」という点で、非常に優れたコーポレート・メッセージだと思います。

さて、上記観点で弊社のコーポレート・メッセージを振り返ってみます

価値の基準点としての機能

「With Us, You Can」は、お客様とともに私達があり、お客様へ価値を提供することでその価値への正当な対価として見返りをいただくという解釈を私はしています。 この観点に立つと、私達の利益を増やすためには、お客様がまず利益を得ていただかなければならない、つまり、お客さまのビジネスが自分たちの土俵であるという ATI (圧倒的当事者意識) の高まりが不可欠になります。

悪い言い方をすると他人の褌で相撲を取る、という表現にもなるかと思いますが、少なくとも私が現在自部署での活動においてはこの ATI をかなり強く意識しています。

解釈の多様性

PRESS RELEASE FROM NOSIGNER 2016

ギンザ・グラフィック・ギャラリーでの展示「ノザイナー かたちと理由」の「De(construct)sign」で「木は葉・実・枝・根の4種類で非常に多様性があるが、扇風機は100を超える多くの部品で構成されている」との展示がありました。 この中の説明文の中に

優れたデザインは、要素が少なく、かつ多くの理由を備えているものだ。自然は我々よりも遥かに優れたデザイナーであり、我々は自然から多くのことを学べるだろう

翻ってみると、「With Us, You Can」は 「Us」とは？、「You」とは？、という明示的なプレースホルダーに加え、ここに「How」「What」などの非明示的なプレースホルダーを想像することは容易です。解釈の幅を許しているだけではなく、明示的・非明示的なプレースホルダーを備えている、ある意味陳腐と捉えられるかもしれませんが、 解釈を促す コーポレート・メッセージは他社を探してもそれほど多くは見つかりません。

これはコーポレート・メッセージの多様性=タフさとも考えています。各事業・各社員の中で様々な解釈・具体化をされたとしてもそこから「With Us, You Can」の要素が見て取れることはコーポレート・メッセージとしてとても強いのではないでしょうか。

共有のしやすさ

「With Us, You Can」は Us を含むことにより、「自分たちはなにができるだろう」という想像を喚起します。 また、(多くの)ヒトはヒトの役に立つ、認められることを望む生き物である(承認欲求)ことを踏まえると、自分が役に立つ、というイメージは共有がし易いものでもあります。 また、各事業においてはメッセージはプレースホルダーを埋めることで具体性を持たされ、その際により一層、役に立つ姿、 ATI は高まります。

その他

最近ベンチャーの方々のお話を伺い恥ずかしながらアドバイスをしていたりしています。 その中で感じているのが、創業メンバはビジョンなどなくとも共有している時間・想いがあるとは思います。 ですが、人数が増えた際の企業文化うんぬんが起きた時に、ビジョンがコーポレート・メッセージとして表現されていると、「これに合わない」という話ができると思います。 在籍期間によるマウンティングをするわけではないですが、意地を張る/張らねばならないタイミングはあると思っており、この際の拠り所とになるのではないかと考えています。

まとめ

ニフティのコーポレート・メッセージは 1) 価値の基準点としても、2) 解釈多様性の幅の面でも、 3) 共有のしやすさ、の面でも最強だと思ってる

これからコーポレート・メッセージを作成される方々の一助になればと思います。

おまけ

経験者採用 | 募集情報 | 採用情報：ニフティ株式会社

こんな感じでやっていますので、興味を持たれた方はぜひ仲間になってください。

私の所属する IoT デザインセンターでは電気回路の設計、基盤の設計・実装(ハンダゴテ含む)、API サーバ・フロントエンドの設計・実装・運用、 データ解析・レポート作成、お客様への技術企画の提案を含むコンサルティングまで幅広くやっています。興味がある方は 特にぜひ 助けてくださるとうれしいです。(2回目

第1回 エンジニアリングマネージャ勉強会を開催し、因数分解でメンタリングをすることを発表してきました

EngineeringManager

f:id:muddydixon:20161214111008p:plain

id:takesako に煽られて背中を押されて

connpass.com

開催しました。

エンジニアリングマネージャ

資料内にもありますが、現在僕は2つの組織の改善を推進していて

  • IoTデザインセンタ 開発チーム リーダ
  • 全社 技術戦略委員会 (どこかで別に書きます)

ミクロなチームのマネジメントをしつつ、マクロなエンジニアリングのルールやガイドラインの提供、環境の改善などをおこなっています。

全社でやろうと考えていることのトライアルをチームで試し成功事例として全社に展開したり、チームの課題を汎用的に他のチームのメリットが出るように全社の課題として取り組んだりと、両方を睨むことで、うまく回っていきつつあります。

エンジニアリングマネージャの課題

id:antipop も話していましたし、懇親会でも話題になっていたのですが、エンジニアリングに限らず「再現性が無い(難しい)」があります。その背景として

  • メンティー自身の問題ではなく、メンターとメンティーの組み合わせなので自由度が一つ高い
  • メンティーのメンタルの状況が、人生のフェイズ、取り組んでいるミッション、その日の体調と乱数要素が大きい

というのがあるのかと思います。

取り組んでいること

私自身が「コミュニケーションが下手」というのもあるため、更に難易度が上がっています。 まるっと「メンター」「メンティー」「成長」という組み合わせでやるから「空気嫁」とか「人間力」みたいなモヤモヤすると考え、メンターの (指向・姿勢, 状況) とメンティーの (指向・姿勢, 能力) とその間の (動機づけの方法, アサインする仕事) という形で因数として分解してみることにしました。

  1. 指向・姿勢: キャリア・アンカー改
  2. 動機: 動機づけ要因、衛生要因
  3. 仕事: ロール/事業関与

分解した上でモデル化、実践と進めて行きたいと思います。

speakerdeck.com

全体を通して

私が「具体的な取り組みと分解の話」、 id:antipop が広い知識からの整理とペパボの「いいじゃん、いい感じに、バーンと」、 @kenchan が1 on 1の取り組みなどについて(途中、社内対応してたので、資料公開お待ちしております)、 id:takesako (こちらは ATI の高いピザ対応をしていたため見れなかったので公開をお待ちしております)と多岐に渡っているようで、下記のような共通点が見えて、自分が外れたことをかんがえているわけではない、と安心ができました。

新しい懇親会のスタイル

id:takoratta が司会をしてくださったこともあり、今回の勉強会では懇親会が非常に面白い形が「立ち現れました」。 懇親会で LT をし、飛び入りを募集する予定だったのですが、飛び入りが現れず、代わりに「会場みなへの質問」が投げかけられました。 そこから後は、話せるヒトが皆、代わる代わるにマイクをもち、個別に雑談もなく、会場全体が議論の渦になっていきました。

この背景として、おそらく、

  1. 参加資格を設けたこと
  2. 数回のイテレーションを回し、成否にかかわらず知見があったこと(反省・課題がある
  3. スクラム同様、教科書はあるが、正解がないため、現状が不安なこと(より正解に向かいたい
  4. マネージャという立場上、議論を回すことが好き・能力がある

だったのではないかと思いました。

これは非常にエキサイティングで、そこかしこから良し悪し問わず、知見が披露され、ためになるものでした。

今後、条件を統制することでこの形式を意図的に引き起こせるのであれば検討してみたいと思います。

最後に

id:takoratta id:takesako id:antipop @kenchan @yuku_t @tatsushim ここ数年、いろいろと考え、闇雲にトライしていたものを棚卸しする機会をいただきありがとうございました。

！？

f:id:muddydixon:20161214114604p:plain