とあるドメインに紐づく GKE の pod を探せ!

証明書更新の時期、ありますね。僕はこの作業がとても嫌いです。 よきにはからってくれていればいいのですが、引き継いだりした場合に

  • どこで動いているかわからない
  • どうやって変えればわからない
  • そもそもどのリポジトリ

ってあるあるだと思います(前職で同じことが起こっていたら非常に申し訳ない)。

kubernetes は便利なんで pod を上げると思うのですがそうなるともう何がなんだかになります。 今日はこれを探すメモです。

手順

% nslookup ${該当のドメイン}
% kubectl get svc
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)         AGE
XXXX      LoadBalancer   10.AAA.BBB.CCC   104.FFF.GGG.HHH   443:KKKKK/TCP   1y
YYYY      LoadBalancer   10.AAA.BBB.DDD   104.FFF.GGG.III        443:LLLLL/TCP   1y
ZZZZ      LoadBalancer    10.AAA.BBB.EEE   104.FFF.GGG.JJJ     443:MMMMM/TCP   1y

ってすれば NAME がでてくるので、あとは kubectl get pod して kubectl exec -it XXXX bash すれば、何者様なのかがわかります

2018年 抱負

前職の(しかも入社したての)頃から「muddyさんはいつ転職するんですか?」と言われ続けていましたが、 2017年の7月1日付けで HAROiD に転職して半年が過ぎました。

HAROiD は3年目に突入したばかりの会社ですが、 TV x Web というのを実現しつつありとてもエキサイティングな環境で働いています。

2017年にやってきたこと

  • プロジェクトごとにプライベートだった Slack Channel をほぼ全て Public 化による社内情報のオープン化
  • 放送局様からの要請 / プロダクトアウトだったためサービスのファクトを各種レポートとして提出
  • InterBEE のためのプレゼン資料づくり
  • 「インフラ/アプリ」「フロント」に分かれていたエンジニアチームをマージ
  • 開発速度を調整しながら必要な箇所の運用の冗長化
  • 経営指針となる情報の提供

あんまり直接的な売上にコミットできてないですね・・・安定性の補強と主体性のある人が自分でキャッチアップして進むための基盤を整備したってところまでです。

あ、あとエンジニアチームのキャリア・アンカーをやって皆の志向性を意識した1on1をやったくらい。

この半年あまりコード自体は書かずに、主に設計とコードのレビュー、キャリアを意識したアサインなど清く正しいエンジニアリングマネージメントとビジネスデベロップメントにリソースを振り向けていた感じです。 今年ももう少し後述するビジネスデベロップメントに注力し、ビジネスを立ち上げてからまたコードをガンガン書いていきたいと思っています。

2018年にやってやりたいこと

データビジネス

HAROiD では、スマホ/PCでログインすることでウェブと紐付けられている視聴履歴データは最高に面白くて、年末の InterBEE で紹介した 「HAROiD x Ad」を今年はきちんと商品化して多くの放送局様・広告主様に利用いただけるように商品品質を高め、実績を積み上げていきます。

もちろん各種のファクトを収集可視化し、サジェストから対策の企画・改善案提案までのトータルでのデータアナリティクス・データに基づくコンサルティングによって自社サービスのグロース・テレビのデータ放送の価値向上はより加速していきます。

ハレのLiVECM からケの視聴体験への進化

ACC に選ばれた「視聴者がウェブからテレビに介入する体験」を提供する LiVECM を「ウェブ→テレビ」から「テレビ↔ウェブ」へより融合したインタラクションに昇華させつつ、より日常の視聴体験の中に馴染ませ、新たな視聴体験を提供していきたいと思っています。

HAROiD では個のクリエイターの力だけではなく、クリエイティブを現実のものに着地させていくテクニカルディレクターの力、それを実現する @toritori0318を筆頭としたエンジニアの力を一つの矢として束ねればそう遠くない未来に実現可能だと考えています。

スマホとテレビ

スマホが台頭し、番組のウェブ配信が始まったことでテレビに費やす視聴時間自体は減っているものの、1億2千万人に視聴率15〜20%の番組、すなわち、その1時間なりの時間で1500万~2500万UUを相手にできるメディアはまだまだ大きな媒体です。 テレビというレガシー(だと思われていて)で参入障壁が高いレッドオーシャンにいつつ TV x Web は実はブルーオーシャンです。

もちろん、レガシーなだけに既得権益との政治的なあれこれはあるかと思っていますが、だからこそ・そこも含めて新しい市場を開拓することは面白いと思えています。

まとめ

下記3つをやってやるぞい!

  • データビジネスの本格的な立ち上げとマネタイズ
  • エンジニアチームのエンパワー
  • テレビとウェブに新たなケの視聴体験の立ち上げ

コードは少し我慢。

おまけ

エンジニアもプランナーもディレクターもほんと能力が高くて、30人ポッキリの会社によくこれだけの人材がいるなぁと思う。 エンジニアチームだけでも、立ち上げ時期だということを理解し、事業を実現するためという大目的に立脚した上で、開発が好きな連中が集まっていて、ディスカッションが常に前向きでとても楽しいです。 あと、酒が好きな人が多いので、個人的には最高の職場です。(転職して明らかにいい意味で酒の量が増え、健康診断があれだった)

HAROiD では仲間を超絶募集しています

www.wantedly.com

www.wantedly.com

自身の時間を使って勉強/自己研鑽すること(をどう広めるか

どうも、7/1 付で HAROiD に入社しました muddydixon です。

三行

  • (こちらでもあがっていましたが) (特に)エンジニア組織のメンバに勉強して欲しい(自身のキャリアのためにも)
  • 言い方によってはパワハラ待ったなし
  • 困ってるので、「うちはこうしてるよ!」というのがある人は教えてください

経緯

先日、id:takesako さん、Speee の是澤さん や pixiv の 川田さん たちと飲む機会がありまして、その中の1つの話題に

エンジニアの自分の時間を使って自己研鑽するようにアドバイス (指示ではない) するか

というのがありました。

前職で OJT の受け入れや新人研修、若手の配属指導などをしてきたのですが、これがいつも自分の悩みのタネでした。

  • 自分の時間を使って勉強しろ -> パワハラっぽい
  • 自分の時間を使って勉強しなくてもいいけど、できそうなヒトの方が仕事ふりやすい -> パワハラっぽい
  • できないなりの仕事はある -> パワハラっぽい

と、パワハラは専門ではないのですが、なんとなく、アウト感が漂ってはいます。

なので、いつも僕は、「生き方は人それぞれだけど、世の中のすごいエンジニアたちは趣味と仕事の境界線が無くて、仕事以外の時間でも OSS を読んだり、自分のプロダクトを試行錯誤したり、時折それが会社のツールとして利用されて効率化されたりしているよ。僕はそういうヒトたちに憧れるし、そういう一人になりたいと思っているし、そもそもそういう創造的な活動は楽しいよ」という、伝わるんだか伝わらないんだかよくわからない感じのメッセージを伝えてきました。

その飲みの場では

  • ドライでいいじゃん
  • ロールモデルを示すんだよ(これがわりかしやってきたことに近い)
  • そもそもそういうことができないヒトを取らないことができないといけない

などの意見が出てきましたが、いかんせん飲みだったのでなんとはなしに次の話題に移ってしまいました。

結局、「これだ!」という妙案がないままでしたので、銀の弾丸がないことはわかっていますが、自社でやっているアドバイス・サジェストの仕方があれば、教えてください。

富士通クラウドテクノロジーズ株式会社 aka ニフティ株式会社を退職します

2017/06/28 14:00 追記 「富士通」が冠についたことは何一つ退職の原因ではありません(そうでなければ「面白い会社です!」とか書きません)。クラウドを作る側に回りたいヒト、クラウドをもっと便利に使うための機能を作りたいヒトは引き続きおすすめの会社の1つです

退職エントリを見るたびに「知らんがな」という思いと「全員に直接いうのも変だから便利そう」という思いの両方がありましたが、いざ、自分が退職することになると「全員と飲みましょう」とか無理だと気が付き「便利」となったので書くことにしました。

正確には「富士通クラウドテクノロジーズ株式会社」を退職するのですが、正直2ヶ月しか働いておらず「遅れたニフティ株式会社の卒業生」という気持ちしかないので以降「ニフティ」と記載します。

このエントリも消されるかもしれませんが、そのときは社会の闇だと思って下さい。

f:id:muddydixon:20170627151622p:plain


就職してからここまで

  • 博士課程満期退学の栄えある情報学修士として27歳の4月にニフティ株式会社入社。あっという間の11年
  • 3年めくらいから社外のエンジニア友達には社交辞令とは言え「まだいるの?」、社内の新卒からは「勉強会で見た muddy さんがなんでうちのような会社にいるんですか?」という失言に近い褒め言葉をいただく
  • いろいろあって7月から新天地に向かうことにしました。

技術系業務

  • IE をインターネット」と呼ぶお客様 に IP を配っている会社に勤めながら「自社検索ポータルの新機能を Firefox の Greasemoneky userscript」でリリース
    • 当然利用者は少なすぎて半年ほどでクローズ
  • 1年目でレコメンデーションエンジンの設計運用保守をしたり(mapreduce を利用しない HDFS のためだけの Hadoop の 0.1 系が入っていた)
  • AdSense の AB テストを実施して収益改善したり (リリースされなかったけど GA を使った広告改善をしたり)
  • バックエンドに Cassandra を利用した REST で perlスクリプトをエンドポイントにバインドできる AWS Lambda のような仕組みを作ってリリース
    • Cassndara の GC で友人の結婚式二次会中に呼び出される
  • mongodb と hadoop魔改造をする
    • mongo shell で mapreduce を書くと hadoop に渡され、 文字列の JS を rhinomapreduce して結果を mongo driver 経由で返すシステム
    • このあたりで d3 を調べまくって一人アドベントカレンダーをしたり書籍の機会をいただく (coffee はいらなかった・・・
  • 某 EC サイトの広告効果測定ツールを企画設計開発運用する
  • MQTT as a Service を出したり、 Lambda みたいなやつをリリースしたりする

ニフティでの大半をデータシステムの設計開発およびデータ解析およびその利活用に捧げてきました

技術系以外

技術的な活動以外にも社内の技術文化環境に対するメタ的な取り組みも多く取り組むことができました。

  • 入社1年目に課長が入院してチームの先輩に指示を出しながら採用とか大学との連携を進めたりする
  • 社内勉強会を2年間でのべ100回以上の開催
  • エンジニアサポートとして社外勉強会への自社施設の提供をどこよりも速くプレスリリース
  • CROSS というどう考えても常軌を逸してるイベントを開催
  • 技術戦略委員会を立上げ自社の技術者の環境改善・文化改善に取り組む

www.nifty.co.jp

2017.cross-party.com

speakerdeck.com

NIFTY is

自分は非凡な人間では決してないですが、めんどくさい人間であることは自覚しています。そんな人間の居場所がニフティ社にはありました。ニフティ社は自発的な取り組みに対して真に寛容な「非凡」な企業でした。

自分にしかできない取り組みもあったと自負はしていますが、自分だけで実現できた取り組みはどれひとつとってもなかったと思っています。めんどくさい人間をそれなりに可愛がって下さった皆様には感謝の思いしかありません。「WIth Us, You Can」というニフティのコーポレート・メッセージは全く偽りがなく、「With Nifty, I Can」でした。このコーポレート・メッセージは最高すぎて、今後なんど転職するかはわかりませんが、自分の社会人生の DNA として多く広めていく所存です。

muddydixon.hatenablog.com

富士通クラウドテクノロジーズ

富士通クラウドテクノロジーズは引き続きクラウド事業/SaaS事業も世界を狙える位置取りをしています。

japan.zdnet.com

技術戦略委員会もこれまで以上に人財・環境・オペレーション・データ活用の4領域から全社の技術的側面を横断的な組織でフォローしていきますし、エンジニアの品質としてもここ数年ぐっと上がり、これまでの自社クラウドの効果的な利用に Slack / Gitlab / Gitlab CI / 自動テスト / ansible を利用したデプロイなどの他社と遜色ない環境で開発しています。

OSS にも理解を示し、 builders con のスポンサーにも入っています!

富士通本体のグループ名を持ちながら、ニフティだった時以上に(いい意味で)富士通らしくない企業になるはずでエンジニアとしては面白い企業だと思います。興味を持たれた方はぜひ下記からよろしくお願いいたします。

採用情報|富士通クラウドテクノロジーズ株式会社

送別会で見られる心理的安全性の高さ

開いていただいた送別会は我ながらなんというか「僕らしい」というか「心理的安全性が高すぎて、みんな何言ってもいいと思われている」感じで溢れていました

f:id:muddydixon:20170627014351p:plain

どうかと思いますよ

www.facebook.com

送別会で送られる人間が挨拶している時にブーイングの嵐とか本当、みんな社会人としてどうかと思いますよ。大人なんでしょ!!(裏表なく可愛がっていただき、本当に幸せでした

なんで辞めたの?次は?

  • 飲み会で!
  • 6/30まで年休消化で 28 日が最終出社です。
  • 7/3 から新オフィスで勤務開始です!!

例の奴、そっと置いておきます。

【妄想】日本の流通にAmazonが入ってきたらどうなるか【夢】

書こう書こうと放置していた妄想です。物流にカスル仕事はしてましたが、不勉強ですので本気で切られても困ります


日本の物流 ヤマト・佐川が amazon からの撤退が決定したのが4月。同月ドラッグストアなどを中心に独自物流を展開していく宣言。予測される未来はこんな感じかなあとぼんやり思ってる

基地としての amazon 倉庫が増える

  • amazon の日本の倉庫
  • 上記がもう少し増える。地方とかじゃないレベルで、県ごととか、人口ごとに階層的に基地ができる
    • この倉庫の最適化も物流網の整備や amazon fresh の利用率に応じて最適化される。なので、最初は関東・関西から

コンビニがバッファとして機能し始める

  • 倉庫は所詮、基地であり、もっと消費者に近いところの配送の最前線基地としてコンビニと結びつく
  • 日本のコンビニが牙を向いたら、待ってましたとコンビニ建設をする
    • もろもろコストを考えると「 amazon にとってよい値段で契約できるコンビニ」と提携できることを望んでるとは思うけど
  • コンビニがより本格的に下記の機能を担う/担うような設備を備える

コンビニの無人化機能が進む

www.meti.go.jp

  • コンビニの無人化が進む中で、そもそも多くの品は陳列されている意味すら失う
  • 生鮮食品のように品質の均一化が進んでいるとはいえ差が生まれる商品とくらべ、コンビニで買える多くの商品は工場で生産され(それこそみんなだいすきなAIが入って異常は検知される)、パッケージ化されるので「選ぶ」ということ自体が無意味になる
  • すでに amazon 依存度の高い諸氏に至ってはコンビニやスーパーで商品を眺めることと amazon を眺めることに大きな買い物体験の差異は生じてないはず
    • 生鮮のように「組み合わせて利用する商品」はセレンディピティによる買い物効果が高い
  • コンビニが一分機能とはいえ「巨大な自動販売機」になる日はそう遠くないと思う
    • 店員が棚に陳列する労働力を考えれば、ストッカーごとトラックから届いてセットすればよいだけの自動化が進んでもおかしくない
    • 万引きが実質的に不可能になるため防犯上の効果もある
    • そのときには RFID タグは翻って不要になるけど
    • 物流のダンボール等の均質化も進む
      • どっちかというとダンボール自体に RFID が貼られて、トラック内の RFID センサによる配送におけるミス(誤配送/出荷漏れ)がなくなるコストも減じることができる
    • オペ改善によりバックヤードの面積を減らして倉庫面積を増床できる

コンビニがそもそもコンテナになる

  • 無人化/自販機化に伴って「店内」「倉庫」という概念がなくなり、商品の補充自体が容易になる
  • 結果、コンビニ自体が倉庫の機能を担うコンテナと化す
  • 配送基地から最適化された品を詰めたコンテナを運び、トレーラーからコンビニのバックヤードに直接降ろされる
    • 空になったコンテナは持ち帰る
  • 配送基地としての機能は継続/強化される
    • コンビニ商品のコンテナと同時に近隣の amazon 商品配送の中継基地として機能する
  • 当然この流通網を効率的に利用して、自宅配送希望の商品は配送する

人類の「クラウド的なストレージ」としてコンビニが利用され始める

  • 「誰がいくら買ったか」がクラウド上で管理されているので、顧客は一括で持って帰る必要すらなくなる
    • 「毎月10kg買っている米」を「先々週、休日に歩いて行ける近所のコンビニで3kg」だけ引き取って、「今週は駅からの帰路にあるコンビニで5kg」受け取る、といった「オンデマンド」な「クラウド的」な商取引が始まる
    • 「一升瓶を持って醤油を買いにいく」ような感じ

物流のクラウド化がサービス化される

  • ここまで自社のための物流網および物流に関する仕組みを革新してきたものを、 AWS のようにサービス化してより安価で使いやすいものとして提供する
  • uber の荷物配送の新サービスにおける中長距離配送で利用される

ディストピア

  • 20枚の年賀状を amazon がでかい箱で持ってくる
  • 収入の3割を生活費として amazon に払う
  • 彼女の家の近所のコンビニで味噌を買ったら「あなたがいるはずのない地域から買ってますがクラッキングですか?」とメールが飛んできて余計なお世話
  • amazon 銀行爆誕
  • 電気代等の光熱費を amazon の請求から払う
  • 結婚式を amazon で買って支払ったら「買うはずがないけど、クラッキングですか?」とメールが(ry
  • 学資保険を amazon で買って支払ったら(ry

参考

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

はじめに

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

2年やって

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

制度を改善するコツ

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

パネルディスカッション

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

まとめ

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

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

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

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

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