ひょうたん

先日「スタッフエンジニアの道」を読みました。本書は部下を持たない上級技術職として「スタッフエンジニア」を定義し、どういう役割を求められ、どういうスキルを発揮し、どうあるべきかのひとつの形を示すという内容です。 「成熟した大人」として振る舞い、リーダーとしての成果を上げる 本書では以下の3点をスタッフエンジニアのスキルの三本柱として定義し、3部に渡ってそれぞれを構成するサブスキルに分けて説明していくという構成になっています。 大局的な思考 実行 レベルアップ 全編を通して「スタッフエンジニアはリーダーである」ことが必須であり、リーダーとして成果を出していくために「成熟した大人」としての振る舞いが必要であるという価値観を貫いています。 この背景としてはスタッフエンジニアというのはあくまで、マネージャーとは異なる方法で組織に貢献し、成果を出すリーダーである。ただ与えられた課題を解き、そのためのコードを書き続けた先にリニアにレベルアップした先に待っている役割ではないということが根底にあるのだと思います。 （このあたりの話はEM.FM Re.33 "「技術力」って何？"の後半で話題に出ていて、かなり面白かったのでオススメです。） パッシブな影響力/アクティブな影響力の発揮 「第III部 レベルアップ」でパッシブな影響力とアクティブな影響力という考え方は個人的にハッとさせる部分で面白かったです。（多分ゲームでよくあるパッシブスキル（明示的に使わなくても効果が発揮されるもの）/アクティブスキル（明示的に使うことを選択することで効果が発揮されるもの）を想定しているんじゃないかと思う） パッシブな影響の事例としては例えばその人がどのように責任を持って仕事に取り組んでいるのか、といった「責任ある大人としての姿勢」をとり続けることによって周囲のメンバーやその組織の文化に与えるような例を、アクティブな影響としてはコードレビュアーとして「ガードレール」の役割を果たすことで明示的に影響を与えることができる、というような例を提示しています。 普段、自分自身の行動の影響力を意識することは少ないですが、本書で提示された概念を念頭におきつつ振り返ってみると、新たな意味づけができそうだなという感触があった箇所でした。

先日、 fukabori.fm 62. プロダクト・レッド・オーガニゼーション を聞いて「先行指標と遅行指標」の話に感銘を受けた。 「プロダクト・レッド・オーガニゼーション」の背景にある「プロダクト・レッド・グロース」モデルについて先に知っていると、後日、前者を読んだときにより理解が進むような気がしたので本書を読んだ。 分野的にはプロダクトマネジメント関連の書籍と近いところがあると感じたが、基本的にはビジネス側からの視点なので、プロダクト側からだけではない視点を増やすためにも読んでみてよかったなと思う。 プロダクト・レッド・グロースモデル 本書ではプロダクト・レッド・グロース（以下、PLG）モデルについて紹介・説明している。これは表紙の言葉を借りれば「プロダクトでプロダクトを売る」ビジネスモデルだ。本文中ではプロダクト主導型ビジネスモデルと訳されている。 セールス主導型ビジネスモデルと比較しながら、PLGモデルが適するビジネスの類型や、適用するにあたって重要なポイントなどを紹介している。 この本の中で私がなるほどと思ったポイントのひとつが「ビジネスのインプットとアウトプットを知る」という部分だ。 「第12章 最適化プロセスを開発する」の中で持続的な成長を実現するためのプロセスとして「トリプルAスプリント」というものを紹介している。このプロセスにおいて外すことができないものがビジネスに必要なアウトプット（ARRなど）を生み出すインプット（展示会、広告、eメールマーケティング）が何かを理解することだとしている。 どんなインプットが望むアウトプットを生み出しているか理解していなければ、持続的な成長を実現することはできない。なるほど確かにそうかもしれない。これまでを振り返ってみるとインプットに対する理解があまりない状態でアウトプットについて考えていることが多かったように思う。言うは易く行うは難しかもしれないが押さえておくと役に立つ考え方だと感じた。 余談 少し前にmasuidriveさんのこのツイートがバズっていた。 エンジニアが会社を選ぶときに評価をするのは年収以外に「事業ドメイン」「技術スタック」と共に「理解がありアホなこと言わない上司、経営陣」と「適切な成長機会」があると思う 特にアホに説明する心理コストは高いから、なぜメモリがたくさんいるのかとか、この機能の変更は大

LOCAL Developer Day Online ’21 /Security に参加してきました。セキュリティの知見を広げるよい機会となりました。主催したLOCAL、せきゅぽろのみなさまありがとうございました。  Developer-First Securityという考え方 LOCAL Developer Day Online ’21 /Security はじまりました〜 Session 1. Developer-First Security という考え方 講師： 米内 貴志 (株式会社Flatt Security 執行役員 CTO) #ldd21sec pic.twitter.com/aJpdm7gsF4 — LOCAL (@local_hokkaido) September 4, 2021 Developer-First Security の背景 設計・開発者が安全にものを作れるとセキュリティってよくなるんじゃない？ セキュリティの範囲は広い 人によって「セキュリティ」が指すものは違う セキュリティに関わる人も多い 設計・開発者が安全にものを作れる環境が大事では？ 安全にものを作れるよいプラクティスはあまりないのではないか うまくいっているセキュリティプロダクトにはDeveloper-Firstという共通点がある これまでのセキュリティプロダクトに課題があった すぐ使えない、コストが高い UXが常人向けではない 開発者の環境になじまない セキュリティプロダクトでうまくいっているスタートアップの共通点としてDeveloper-Firstという考え方があるようだ Developer-First Securityとは 1. 開発者の活動圏にとけこんでいく 開発フローに組み込める製品にすることで開発者のセキュリティへの関心や行動を自然に引き出すようになっている。ツールに密結合したりしている。 ex.) Snyk：GitHubと連携して改善のアクションまでをサポートしている ex.) GitHub：数多くのセキュリティ機能を展開している。 2. 開発者の技術スタックにとけこんでいく 例えば認証処理なんかは要件が複雑になりがち。ここをサービスとして提供することで技術スタックに押し込む。認可のサービス化もあったりする ex.) Auth0 ex.) build.

ツイッターの投稿を見る限り1月末くらいからはじめたようだ。 unity、移動制御をPhysicsまかせにするとこんな感じになるのかー。ウケるけどこうではない pic.twitter.com/X6vwC7j0NU — もひゃ (@onjiro_mohyahya) January 25, 2020 2月末くらいの時点でこんな感じ。 よしよし、そこそこゲームっぽい雰囲気が出てきた気がするなー pic.twitter.com/shyKoIn52c — もひゃ (@onjiro_mohyahya) February 29, 2020 元々はSFネタで1本アクションゲームを作ろうかなーと思っていたけど、ネタがあまり煮詰まらないので、とりあえず昔描いたミクのドット絵で適当に作ってみることにしたのだった。 お話はねぎ畑を荒らされたミクがたこルカをしばきに行くみたいな感じになりそう。適当な感じにしておくと気が抜けてよい。 今はボスのたこルカを作っている。ドット絵を打つの面倒すぎなのでたこルカはやめたほうがよかったかもしれない。 たまにgh-pagesも更新。zでジャンプ、xでネギ https://t.co/1Ki8H7lJbY — もひゃ (@onjiro_mohyahya) February 29, 2020 ちなみにシルフェイド幻想譚の作者のsmokingWOLF氏の本で紹介されていた"力尽きたらそこで完成"メソッドで進めているので、力尽きたらそこで終わりにしようかと思っている。

昨年、 本当に取り組む課題を見つける、課題発見ワークショップ in Sapporo  に参加してきました。会社のSlackで紹介されて、なんとなく「面白そうだなぁ」という動機で参加してきたのですが、想像以上に楽しかったの最高でした。 年末あたりに記事にしようと思ってたけど気張りすぎて出力できなくなってしまったので供養。。。 こんなワークショップだったよ ワークショップの目的は次の通りでした。 課題設定の重要性を理解する 課題の見つけ方を体験する 課題解決までのプロセスを体験する 内容としては課題設定の重要性についての話をし、実際にワークをいくつかやってみるというのをいくつかやる、という形式で進みました。 ワークショップの中では課題発見の方法として、以下の考え方やテクニックが紹介されていました。 認知問題、技術問題 問題の分解とリフレーミング スマートとシニカル HMW Framework、我々はどうすれば〇〇できるだろうか、という形式で考えてみる よりよい課題発見の方法にも型がある 課題の見つけ方の体験というのはじめてやった チームでの課題が面白かった。途中でこれは厳しそうだなぁと思ったけど、なんかそれなりになんとかまとまった。ちょっとびっくりしました 背景の異なる人とワークすると刺激がある いっしょにワークを実施したチームメンバーは全然背景の異なる方々で、開始するときにはちょっと心配だなぁと思っていたのですが、逆にこれはこれでよかったかもしれません 次はこれやってみようかな 話の中で紹介されていた本、「他者と働く」が気になったのでどこかで読んでみようかなぁ。。。

「カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則」を読みました。 だいたいこんな感じの内容でした。 Salesforceがサブスクリプションこれまで買い切りだったソフトウェアの世界にサブスクリプションを誕生させた。サブスクリプションの世界では導入時の売り上げよりも、契約し続けてくれることによりもたらされる売り上げのほうが大きく、重要になってくる この世界では更新、アップセルが特に重要になってくること。このためにはソフトウェアを導入した顧客が目的を達成できることや、ファンになってもらうこと（＝心理ロイヤリティの創出）が求められること 売り上げ比率の変化により、これまでの社内での力関係に変化が発生している。これまでは契約取得に対して責任を持つセールスが力をもっていたが、更新に対して責任をもつ部署へとバランスが傾いてくるようになった 更新に対する責任の遂行にあたっては何か問題があったら対応するというこれまでのカスタマーサポートよりも、事前に手を打って顧客の心理ロイヤリティを高めるカスタマーサクセスという動きがより重要視されている 今後 CCO（Chief Customer success Officer）が出現し、重要なポジションとなっていくであろうこと サブスクリプションはソフトウェア以外の分野でも今後増えていき、カスタマーサクセスの重要度が多くの分野で増していくであろうこと 「カスタマーサクセス」って実際のところなんなの？ これまでカスタマーサクセスという言葉について、「耳障りのよい言葉で、なんかよさそうなやつだけど、実際に何を指しているのかが、人によって考えていることがバラバラでふわふわしたもの」という認識でした。この本ではもう少し具体的にカスタマーサクセスとはなんぞ？というものが定義されており、「カスタマーサクセス」という言葉が出てきた時に認識を合わせるひとつの指針として利用できそうだなと感じました。 カスタマーサクセスという文言は、ロイヤリティの創出、特に心理ロイヤリティの創出という言葉の言い換えにすぎないということだ。 カスタマーエクスペリエンス大事、、、大事 読んでいてこれは確かにそうだよなぁ、なるほど〜と思ってマーカーを引いていた部分を挙げておきます。 最高のカスタマーエ