読んだ記事をメモっていくscraps

• 情報が凝縮されることによるメリットを享受できる
• ツールによるBizとDevの隔たりがなくなり協働関係が促進しやすい

• どっちが良いとかではないが、最初は兼任から始める　→　専任になる順だと取っ掛かりとして良い
• ScrumMaster Wayを知った（概念は知ってたがオリジナルは知らなかった）
  • https://scrummasterway.com/scrummasterway-ja.html
  • これも読んでおきたい
• 専任のほうが目線が上がったとのこと。これは役割によるものと考えると、役割によって自分を変えるはエンジニアとしても有効。1 Junior Engineerとしてやるだけではダメで、もっと問題意識広げる　→　役割変える　→　問題意識広げる　を意識できると良さそう

読んだがDDD基礎理解を全然やってないので無駄になりそうだったので流し見。

• コンテキスト境界はチートポでもがっつり出てきてたので結びつきが強そう。
• こういう難解なものを扱うメリットがまだ分からないけど、大規模な開発&チームになると効いてくるんだろうか…。
• マイクロサービスアーキテクチャは大規模になりすぎて手のつけられなくなったものをどうにか扱えるようにするものと聞いたので関係がありそう。
  • GPT曰く、目的は違うけど、相互補完的な関係ではあるらしい。

  • マイクロサービスアーキテクチャはシステムを複数の独立したサービスに分割することに注力し、DDDはこれらのサービスがビジネスの要件を効果的に満たすように設計するための方法論を提供します。両者を組み合わせることで、ビジネスニーズに密接に連携した、より強力で柔軟なソフトウェアソリューションが実現できます。

• 所々知識不足でロジックが理解できないとこがあったのでGPTで対話的ラーニングの題材にしても良さそう
• 生成系AIが当然の前提となっている
• どう応用していくかについては考えないといけないが、ひとっ飛びには行けないので個人的に意識するところとしては、飛び付かずにデータの使い方などの基礎理解をすべきと思った。

• 個人の才能（スペック）の多くは「正規分布」だ。一方で、経済的な成功は、何らかのきっかけでチャンスを掴んだ少数の人間がほとんどの成果をかっさらう「べき乗則」の世界だ

  • べき乗の世界はパレートの法則チック

• 人々を苦しめている問題の根っこは、環境が作り出す成功という「現象」が、個人の能力を示す「成果物」のように扱われてしまうことにあるように思う。

  • これはすごく納得。ただ納得したからと言ってこうやって因果関係に結びつけるのを避けるのは難しいし、成果を上げた人にしかわからないからこそ難しいとも思う。

• 独自性（ユニークネス）とは、その時代の人々がなんとなく共有している認識を見抜いた上で、その「常識」と「非常識」のちょうど境界線上にアイディアを置くという行為

  • 抽象的だけどわかりやすい説明。

• もし規格外の成果を出したければ「べき乗則」が支配する世界に身を移す必要がある。べき乗則が支配する世界では、人気者はさらに人気者になり続けるというループが無限に発生する。結果的に指数関数的な成果が短期的に舞い込む。

  • SNSの影響力はまさにこれの賜物なんだろう

• 求心力を発揮させることに思考が偏り過ぎてしまうと、0から100まで全てこだわり抜こうとしてしまう（頑固者の職人のように）。そのため、自分が得意でもない領域にまで手を出してしまい競争に巻き込まれてしまったり、外部環境の力を活用しようとせずに小さくまとまってしまうということが起きる。

• 独自性（ユニークネス）とタダ乗り（フリーライド）の掛け算によって本人たちも想定外な規模の成果が発生すると、そこには物語性（ストーリー）が付け加えらえることが多い。確かに成功秘話や開発ストーリーや偉人の自伝は読み物として面白い。
  人間は情報を流通させるために物語を勝手に作り出してしまう癖がある。なぜなら、そのほうが効率が良いからだ。

  • これは因果関係のバイアスも示唆してそう。ストーリーがある方がが一貫性が出てわかりやすい。

• 「優れた才能」が足枷となり、競争に巻き込まれて「独自性」を発揮できなかったり、「タダ乗り」せずに自力で突破しようとして「運」を味方にできないといった戦略ミスを犯しやすい。

  • 環境がいかに大事か

• おすすめは「好き」と「得意」の二つが重なってる領域に狙いを定めることだ。「周りから褒められるけど自分では楽にこなせること」を注意深く観察していくと、自分の個性が見えてくる。それを続けることが全く苦痛でないならば、好きと得意が重なっている領域と考えて良い。

  • この部分は超よく見る形になってるけど説得力が違う

• 二つでダメなら三つ組み合わせて、三つでだめなら四つ組み合わせる。「ちょうど良いサイズのニッチ」が見つかるまで絞り込めば良い。

• 人間は、環境が変化しても種が全滅しないように、個人が多様性を持つように設計されている。

  • おもしろい考え方やな〜出典どこなんだろう

• 自分に配られたカードを知るためには「自分では特に頑張ったつもりはないけど、周りからよく褒められること」を見つけるのが近道だ。

  • 今ぱっと浮かぶのは、自分で物ごとに意味を付けてそれを信じる事ができる能力は人よりある
  • 貧乏だったからというのと、行動するために意味を付けていくことが大事だとアンラーニングしていった結果
  • 損得ベースで動くので、どんな物事にも得な意味づけをできること

• 脳には「デフォルトモードネットワーク」という領域があり、ここがずっと覚醒していると何かを考えることに忙しくなってしまう。思考のループから抜け出せなくなってしまう。この領域を休ませずに覚醒させ続けると鬱病などの精神疾患を発症する。

  • ほ、ほえ〜

  • なかなか成果につながらず「失敗したらどうしよう」「笑われたらどうしよう」といった不安に押しつぶされそうな時は、目の前のことにところん没頭する癖をつけると良い。没頭することで、逆に脳を休めることができ、充実感も得られる。周りの声も気にならなくなり、成果も出やすい。まさに一石二鳥ではなく三鳥も四鳥にもなる。

    • 煮詰まったときにランニングしてたのは結構この理論に適ってることだった

• 科学が台頭した後は「分からないことは分からない」という態度はどんどん許されなくなっていった

  • 完全にそう。自分の思考回路もこれ担ってることを思い知った

• うまくいってる人をよくよく観察してみると、試行回数が圧倒的に多いことに気付く

  • 今まではこの言葉がちゃんと腑に落ちてなかったことがわかった。この説明でようやく腑に落ちた。

• 「運の悪い人」から脱却するためには「失敗する＝才能がない（無能である）」という固定観念から、早いタイミングで脱却できるかにかかっている。
  もちろん、世の中の99%の人は「成功」と「才能」を結びつけて考えてしまうので、トライアンドエラーの過程で「あいつは無能だ」「才能がない」と嘲笑されることはあるかもしれない。
  ただ、自分が大好きなことをやってる場合には気にせず続けることができるし、目の前のことに没頭していれば周りの評価も気にならなくなる。

一見便利そうなのでつい使いたくなる言い回しですが、主語が大きすぎるがゆえに捉え方は人それぞれ。何を意味するか曖昧なのは否めません。

言葉の定義が曖昧。

「何を求めているのか」の認識をすり合わせなければなりません。
プロダクト開発の意義やゴールをチーム全員で正しく共有できていないんです。ひとことで言えば、困難に直面したときに立ち戻るべき指針がないわけです。
登り方はおろか、登るべき山さえも周知されていないにもかかわらず、装備や日程、メンバーだけが決まっている状態で山登りに出発しても、山頂にたどり着ける確率は極めて低いでしょう。それと同じことが多くの開発現場で起こっているんです。

自己組織化されたチームにも程遠い状態。

プロダクトとしての目的やゴールが明らかになっていないと感じるなら、率直に聞くべきですね。「これは何を達成するためのプロダクトなのか？」「何をもって成功と定義するのか？」「このプロジェクトの目的と、プロダクトが目指すゴールとの整合性はどこにあるか？」と、わかるまでしつこく聞くんです。

tough questionがここでも出てきた。
小さく試し始めてるけど、居心地の悪さは確かに感じる。
「これは必要なことだ」と自分に自信を持たないとやってけない。

エンジニア側であれビジネス側であれ、真っ先にフォーカスしなければいけないのは「誰の、どんな課題を解決するか」という点です。それがあってはじめて、解決に向けたアイデアや手段が生まれてくるし、顧客の業務や新たな開発手法を学ぼうというモチベーションが湧いてきます。
そうした前向きな開発体験を経験できない環境に居続けることは、エンジニアのキャリアに悪影響をおよぼしかねません

限られたリソースでどこを取捨選択するかの意思決定材料にもなる

• モニターすべきは遅行指標でなく先行指標

  • 一般的に、先行指標は同じ「売上」に対するものであっても、それぞれのビジネスによって異なります。

• 数値に一喜一憂するのは二流、一流は傾向をおさえます

• プロダクトエンジニアはフロントエンド・バックエンド・デザイン、そしてあらゆる領域を越境してプロダクトのあるべき姿を構想し、優れた顧客体験を生み出します。

  • 優秀すぎる

• フルスタックエンジニアが増加してきたことは技術が平易になったことを表す

• フルスタックエンジニアと比較すると各技術領域への深い理解は必ずしも必要ではなく、プロダクト構築に必要なスキルを持って適宜スペシャリストに頼る推進力が求められます。

  • インデックスを持っておく必要性

• プロダクトエンジニアが持つ３領域は「テクノロジー・UXデザイン・ドメイン」

  • テクノロジー

  • ひとりで１機能を単独で実装できる技術力があることは望ましく、技術力の深さとソリューションの多様さは優れた顧客体験を創る根源

  • ドメイン

    • 顧客理解の解像度を高く持ち、それを源泉として優れた体験を創出することがプロダクトエンジニアの一番の特徴

• 共通した特性

  • 顧客ドメインやビジネスに対する高い好奇心
  • 専門領域の越境とキャッチアップの素早さ

    • 一般的な技術軸での学習に比べて極めて実践的で目的意識を持って行われるため学習効率は高く、エンジニアとしての成長も意外にも速くあります

    • なるほど。遅延評価学習を軸にしていく必要性を感じた。
  • 探索的かつ迅速な仮説検証サイクル
  • アンラーンを受け入れる素直なコミュニケーション
  • 課題解決に対する強いオーナーシップ

なんとなく言語化されずに今求められている、今後求められていくエンジニア像を職種として定義したんだな〜という印象。
正直エンジニア2年目の自分からすると途方もなく感じるが、顧客理解への好奇心はあるので愚直に目の前の顧客に価値を届けるにはどうすればいいか？どういう知識が必要なのかの問題意識を持ってそのギャップを埋めていけたらいいなと思った。うちのCTOはまさにプロダクトエンジニアだと思う。

• 学卒初任給の平均額に届かない月給 20 万円で労働者を確保できたとしても、5 人いれば、一年分の人件費だけで 1,200 万円かかります

  • えぐい

• 会社設立はできるだけ遅らせるべき ~ 資金を消費する活動を開始するのは可能な限り遅らせるべき

  • 全然この考えをしてたわけじゃないけど、できるだけ個人でやりたい。社員の人生の責任を取るの怖いと思ってたのは結果的には良い考えだったかもしれない。

• 現 Coral Capital は、シリコンバレーのスタートアップ・エコシステムをよく理解しており、それに倣っているので、投資先スタートアップに対して、資金面だけにとどまらない様々な支援を惜しまずおこなっています

• 製品開発よりビジネスモデル考案の方が難しい

  • ミクロ経済学を学んでいないか完全に忘れている

• 周辺事業進出が悪手になる場合もある

  • 勢いがあるように見えていた競合企業が、昨年末にかなりの人員を解雇し、今年に入り他企業に買収されて独立を失いました。解雇された人の話によると、製品に新機能を追加した結果、大企業と競合関係になってしまい、製品を売るのが難しくなり、事業が行き詰まってしまった

• 個人的には、次の三つから再利用可能なソフトウェアの設計・実装について多くのことを学ぶことができました。
  Unix 仮想ファイルシステム
  Linux カーネルドライバ
  Java 仮想マシン (CDC/PBP のリファレンス実装)

「知ったかぶりができる」ということは 「無知の知を自覚した状態で人に説明ができること」 と言えそうです。

知ったかぶりは取っ掛かりとしては意外といいいうアンラーニングから始めよう。

理解の３要素＞ とは次のようなものだ。
その構造をつかんで、人に説明できること。
いつでもどこでも即座に取り出して使えること。
知見を踏まえて応用がきくこと。
いつでもどこでも即座に取り出して使えること」をまずは目指すべきなのですが、これについては本書の中で「メンタルモデルの構築（＋システム思考）」によって達成できると紹介されています。メンタルモデルの構築とはつまり、脳内イメージ

脳内イメージを如何に構築していつでも取り出せる状態にする

全体と細部、抽象と具体をうまく行ったり来たりすることが解像度を上げる一番の近道なのでは

これはその通りな感覚。どっちから始めてもいいけど、全体から始めるほうが自分はうまくいく気がする。

伝えられた事柄、本で読んだ事柄がどのような範囲をカバーするのか、それは他の知識とどう関係するのか、そしてどこで使われるのか、そうしたことを考える作業を行わない限り、その事柄は単に記憶としてしか存在せず、知識とはならないのだ。

ぶっ刺さるな…

なぜならどの市場に於いても零細企業、中小企業、そして大企業が抱えるビジネス課題は大きく異なり、その解決手段としてのSaaSに要求される機能も役割も異なる

SaaSを含むウェブアプリケーションは、結局のところデータへのアクセス管理ツールでしかない。CRMならば顧客データ、ERPならば法人資産データ、HCMならば人事データへのアクセスを平準化し、その処理を自動化したり、分析しやすくすることで得られる付加価値に対して利用料が発生するのがSaaSのビジネスモデル

こういう知識も足りてないし、思ってた以上にエンジニアとしての価値が生成AIで変わられていく感覚を覚えた。
価値が下がって、これまでみたいな高給ではなくなっていきそう。

人に説明できるレベルで理解しているかを問い、どうやってそのレベルに達するかの話

向こう10年で同程度の成長をするならば、10年間で 100万円程度年収が上がることは期待できますが、誰かが年収1,000万円を達成しようと思うと、他の誰かの年収を平均値より下げる必要がありそうということが推察されます。

例えばチームの Lv.1 生産性を上げるために、「1日あたり2つPRをつくろう」「PRのopenedからmergedまでのリードタイムを24時間以内にしよう」という目標を設定した場合、メンバーはいろんなことを考えなければいけません。目標達成のためにメンバーは、

• レビューする人が差分を理解しやすいコミットメッセージ
• レビューする人がすぐに見られるPRのサイズ
• タスク分解をPR単位で表現する意識
• 開発に着手するためのWIP制限
• フロー状態を意図的に生み出すために不要なミーティングの棚卸し

など、数字を意識するようになったことでそれを最大化させるための努力をするわけです。その結果としていままで問題視されてなかった、あるいは負担だったがマネージャーのマンパワーでどうにかなっていた部分が顕在化して、組織としていい課題を乗り越えるような良いサイクルが回り始めます。

アピールにおいて重要なのは
・具体的であること
・能動的であること
の二点だけだと考えます。
「曖昧な言葉を使わず、何をやったのか具体的に分かること」
「聞かれてそれに答える形ではなく、自分で考えてまとめること」
の二点を満たしてさえいればそれで十分だ、と、部下の人たちにもそう伝えています。

成果の可視化について、私が部下の皆さんにお勧めしていることが、二点あります。
一つは、「この仕事の成果はどう言語化出来るか」ということを、仕事に手を付ける前に考えておくこと。
もう一つが、「成果を言語化する時、その成果のストーリーを考えてみる」こと。

まず一点目、「成果の言語化」をタスク開始の時点で意識しておくというのは、私自身が昔先輩から言われたことで、普段仕事を進めていく上でもとても重要です。
この仕事をやり遂げた時に、自分はどんな言葉で組織に成果報告出来るかな？ということ。自分がどのように組織に貢献したのか、説明の仕方を考えておくこと。

なんとなくでこういう嬉しさがあるよねくらいの思考で進めてしまっている。

「成果の言語化」を意識しておくと、明確になっていないゴールに気づきやすい。だから、「この仕事の成果をどう言語化するか」を考えておくことが重要。まずはそういう話です。

二つ目、「成果を言語化する時、その成果のストーリーを考えてみる」こと。
一般に、アピールが上手い人と下手な人の最大の差は、ここにあるような気がしています。

棚卸しした業務内容について、ストーリー付けをやってみるとなにか得られるものがありそう

アウトプットしろ！！！！！！！

• ここまでの一連の流れをもって、成し遂げたい結果はなにか。
  上司や先輩から、あなた自身の関わり方への成功体験を作ること
  これ１点のみです。
  自分が伝えたことが、その人にとっての良い影響になっていることを理解すれば
  更に追加でお伝えしたいことが山ほどあるのが、リーダーや管理職というものです。

  「あなたとの関わり方における成功体験」は面白い考え方だと思った。たしかに。

• 自ら情報を取りに来た人に、その労力に見合うだけの情報は渡される。
  上司は、その動きが出来る人物を、知れば知るほど、有益な情報を渡してくれるようになる！

フロントエンド開発は既に「コンポーネント化」の歴史が長いので、そのことに誰も疑問を抱かないほどです。フロントエンドがコンポーネント化されている理由は明らかで、コンポーネントは「分離されている」「テストしやすい」「再利用可能」「コンポジション可能（当然！）」という優れたコードのあるべき姿を体現しているからです。

かつてフランシスコ・ベーコンは「いくつかの本は味見に値する、いくつかは飲み込むに値する。そして、まれにだが、たまには噛み砕いて、消化するに値するような本もある。」と言いました。

１回ですべてを理解しようとするとこの味見に値するのを気づかず飲み混んでいる。
まずは

1. 味見でざっくり概要を理解する
2. そのうえでちゃんと読むかどうかを吟味する

というプロセスを意識することで時間の浪費を減らせる

テストを書くという行為は、想定する仕様を持つ機能やコードを「使用する」行為である。使用することで、使い手にとってそれが良い仕様なのか、悪い仕様なのか、自然に明らかとなる。テストを書きつつ、それが悪い仕様だと感じたならば、その時点で仕様を変更すれば良い。こうして、小さなフィードバックサイクルが形成され、仕様はより洗練されていくことになる。

右側に位置するQ3のテストでは、仕様を正としない。そこで検出される誤りは、優れたユーザー体験と仕様との間に生じうるギャップと言えば良いだろうか。ブライアン・マリックはこれをイシュー（issue）と呼んでいた。従来型のテストモデルで陥りがちな失敗パターンにおけるテストフェーズでは、仕様と実装のギャップの検出とその修正が目的であった。あくまでも仕様を正としたテストが行われていたのだ。この点が大きく違う。

仕様を正としない

プロダクトを批評することで発見されるイシューは、その領域がQ3であるかQ4であるかに関わらず、欠陥（バグ）ではないということだ。もちろん、多少の欠陥も検出されるが、発見すべきものはあくまでもイシュー（課題）なのである。それが、左側象限で定義される仕様やテストにフィードバックされる。こうして、フィードバックサイクルが形成されるのだ。とても、アジャイル開発プロセスらしいではないか。私はそう感じた。

必然的に、この象限のテストは手薄になってしまう。また、ここでのスペシャリストの多くは、テストだけでなく、同領域における設計のスペシャリストでもある。したがって、手薄になるのはテストだけでなく、設計も不十分になるだろう。ソフトウェアシステムに、非機能観点での設計や実装が適切に組み込まれないということだ。
私の実感では、周囲のエンジニアから「優秀なエンジニア」だと認められ、信頼されているエンジニアの多くは、これらの領域を担うスペシャリストだ。逆に言えば、このようなスペシャリストになることは、エンジニアにとって、自身の価値の向上につながる。当たり前ではあるが、エンジニアリング領域を預かるマネージャーは、こういった人材を育て、あるいは獲得することに注力する必要があるのだろう。

ここはアジャイルで求められるゼネラリストではなくスペシャリストが求められると言及されている。

テスト自動化ピラミッドで示される理想像を目指しつつ、逆三角形からはじめてみるのも、戦略的に悪くはないだろうと考えている。E2Eテストの自動化から始めることで、リグレッションテストをなるべくカバーするのだ。これまで手動で行われていたリグレッションテストのテストケースを自動化するのだと考えると良い。そして、機能変更などによってE2Eテストが壊れる時が、その範囲の自動テストの階層を下げるタイミングだ。

レガシーコード（=テストのないコード）と戦うにはの文脈

応用ができないのは基礎の徹底ができない、すなわち本質を掴んでいないから

たしかに。本質をどれだけ早くつかめるかが成長速度に影響してきそう

逆に記録を残すことのデメリットってなんでしょうか？めんどくさい/時間がかかるということくらい

間違っていると思う意見には、「反論する義務」がある――。これはマッキンゼー・アンド・カンパニーで受け継がれる価値観だ。

「マッキンゼーで学んだ最も強烈な教訓があります。いまでは私も新入社員全員に伝えていますが、“反論する義務”と呼ばれるものです。どんな会議においても、その場で最も経験の浅い者が、最古参のベテランに異議を唱える最大の権限を持つ、ということです」

「上司の言うことすべてに同意するような会議は、やるべきではありません。反論する義務があってこそ、最高の知恵と成果を得られるのです。人はそういう環境を好みます。自分に価値があると感じられ、大胆になります」

こういう事を考えたい。小さくてもいいから何か事業をやりたい。
何が足りないのだろうか？

エンジニア歴6年前後

差分を考えたい

「タイトルから内容が推察できる記事」や「自分の専門性を磨きたい領域外の深い記事

選択と集中

スクラムではなくても小まめにドメインエキスパートやプロダクトデザイン側からフィードバックはもらっているし、一定の振り返りもしていて、でもそれらを型化せずに各人の自律駆動で開発しているスタイルでした。
スクラムという型で行うと、どうしてもイベントがあるからという理由で無理に小さいフィードバックを出すなど「場を保つためのムダ」が生まれたりもする

スクラムの概念を落とし込んで暗黙知としながら実践している→これに再現性をもたせようとすると形式化が必要だが、チームごとに適切なものが違うのでそうしていくかは考える必要がある。
あと、スクラムという軽量さがウリのFWでも無駄なプロセスが発生する、というのは面白い。

そういう意味ではこのプロセスにプラスの要素はあまりないのかもしれません。でもプラスよりもマイナスを排除できることに大きな意味があったと思います。

メンタル的にはマイナスがない方が負担が少ないし、継続していくうえでそれはとても大事。

マネジメント側も明確に評価できる「映える目標」を入れたくなる気持ちは分かるのですが、それをなくす勇気がマネジメント側にあればシンプルに活動だけにフォーカスした目標設定は可能だと思ってます。勇気次第です。

なるほど。