Shimpei Wakida's Blog

日々の学びをゆるりと.

『モノリスからマイクロサービスへ』読んだ

最近ソフトウェアの設計領域に興味が沸き始めている。最近の業務では統括EM的ポジションで採用やチームスケール体制づくり等組織開発メインでやっており、コードを書くことはほぼない。ただ、コンウェイの法則の通り、組織とアーキテクチャは同時に考える必要があり、組織を設計する人には少なからずアーキテクト的素養が求められる(逆も然り)。

現職の組織開発において、これまでは1チーム体制が続いていたのだが直近一気に3チーム体制になり、チームの境界をどう引くか?など複数チーム特有の問題に頭を悩ませる時間が増えた。そうなると自然にアーキテクチャにも関心が向くようになった、という背景。

現職に入社するまでまともなWeb開発経験もなく、これまでモノリス以外の構成は未経験なので、具体の事例は正直理解が難しかった。

ただ、

  • マイクロサービスは銀の弾丸ではない
  • マイクロサービス化するメリットがコストやリスクを上回るのか、移行まえに時間をかけて真剣に考えろ
  • 移行するなら、安全に段階的にやるべし(そのための手法は本書を見ればよい)

といった本質的に著者が伝えたかったであろうメッセージは伝わり、自分の解像度も上がった。

チームで技術的な会話をしていると「この問題の解決策なら、マイクロサービス化するくらいしかないですかね〜」といった、おそらく発した本人も本気で言ってはいないであろう雑な提案を見聞きすることは多い。マイクロサービス化した時のうまみはまだまだ分からないが、やるとなったらどれだけ大変か、その上で進む覚悟はあるか、といった問いかけをし、議論できるくらいの知識は身についたかなと思う。

大規模スクラム手法と現状整理

社内向けに言語化したのもをせっかくなのでこちらでも言語化しておく

LeSS

  • 「LeSSはスクラムである」と公式サイトでも言われるように、通常のスクラムを拡張したシンプルなフレームワーク
  • 8チームまでを想定しており、それ以上のチームになると「LeSS Huge」
  • 1つのプロダクトバックログ、1人のプロダクトオーナー、複数の開発チーム
  • リファインメントやレトロは、各チームごとと全体でそれぞれ実施

Scrum@Scale

  • チームごとにプロダクトバックログ&プロダクトオーナーを持つ
  • 「単一のスクラムに、チーム間連携の仕組みを追加したもの」
  • プロダクトオーナーをスケールする仕組みを持つことがLeSSとの大きな違い
    • WHAT領域のプロダクトオーナーをスケールさせる仕組み(= プロダクトオーナーサイクル)と、HOW領域の開発をスケールさせる仕組み(= スクラムマスターサイクル)という概念がある
  • イベントをチームごとと全体で実施するのはLeSSと一緒

発散的メモ

  • LeSSの「1つのプロダクトバックログ」とはどういう状況なのだろうか。うちでは一応Jiraプロジェクトとしては1つだが、チームごとにフィルター分けて管理している。これは1つのプロダクトバックログというのだろうか
  • ツール起点で考えるのは本質的ではないが、「1つのプロダクトバックログ&チームごとにスプリントバックログを持つ」はJiraだとどう表現されるのか気になる。もしかしたら今がそうなのか
  • 今はチームごとに独立して何を作るか決めている(他チームのイシューとは分けて優先度付けしている)ので、今のうちの状況はおそらくScrum@Scaleに近そう
    • そうなると、チーム間の連携(プロダクトオーナーサイクル/ スクラムマスターサイクル)をうまく回す仕組みがないと全体として正しい方向に向かって最大出力出せない状態になってしまいそう
    • その全体整合性を保つのが自分の仕事になりそう
      • 先日の事業内でのプロダクト意思決定ライン整備のワークショップ(RACIで責任範囲を明確化)で、「複数チームにまたがるプロダクトのWHAT(何をいつ作るか)」領域は事業責任者がRACIでいうA(責任者)、自分がR(実行者)を担うことになった。このRに求められる役割を一言でいうと「開発組織全体のスクラムマスター」だという結論になった。各チームはそれぞれスクラムマスター&POがいてその中で意思決定してもらい、全体の方向性づけや交通整理を自分がやるイメージ。このワークショップで全ての役割が抜け落ちず明確化されたかは分からないが、落ちていたらそれを拾いにいくのも、その後どうにかするのも全体のスクラムマスターの仕事。アラインメント体制決めのMTGを設けたことも、まさにその仕事の1つだった。

ハイパー起業ラジオ:ず〜っと愛される番組を作る秘訣の会が面白かったのでメモ

ハイパー起業ラジオのプロデューサー・樋口さんゲストでここまでのハイパー起業ラジオそのものの戦略を語る会が、個人のブランディングや組織論にも応用できそうで面白かったのでメモ。

youtu.be

この動画をChatGPT要約した内容が以下

段階的な発展の重要性: 樋口さんは、ポッドキャストのコンテンツや戦略を急がず、段階的に発展させることの重要性を強調しています。外部からの影響や反響に左右されず、しっかりとした基盤を築くことで、長期的に愛される番組を作ることができると述べています。特に初期段階では、番組の方向性が定まっていない時に外部の反響が大きすぎると、思わぬ方向に進んでしまうリスクがあるため、慎重な進行が求められると指摘しています。

SNS影響力の制御: ポッドキャストの告知や宣伝は、番組の形がしっかりと固まるまで控えることが推奨されます。SNSでの影響力が大きい場合、過度な期待やプレッシャーがかかり、結果として番組が不自然な方向に進んでしまうことを避けるため、あえて外部に広めず、内輪での熟成期間を持つことが重要だとしています。

コミュニティの育成と管理: 樋口さんは、コミュニティを一気に大きくしないことの重要性を語っています。コミュニティが急激に拡大すると、文化やノリが固まる前に多くの人が集まり、結果として統一感や一体感が失われる可能性があるため、慎重に人数を増やしていくことが大切だと述べています。また、少人数からスタートすることで、自然にメンバー間に階層やメンターシップが生まれ、運営側が過度に関与しなくても、コミュニティ内での文化が育まれるとしています。

文化の醸成と維持: 初期段階でのコミュニティ運営においては、文化の醸成を重視し、ノリや雰囲気が自然に形成されるように工夫することが大切です。特に、初期のメンバーが自発的に後から入ってくるメンバーをサポートする仕組みを作ることで、持続可能なコミュニティを育てることができると樋口さんは考えています。

忠実なファンベースの構築: 最初からのファンやコミュニティメンバーに特別な価値や誇りを感じてもらうことが、番組の成功につながるとしています。初期のファンが、自分たちが早い段階で番組を見つけたことに喜びや優越感を感じ、その満足感が他の人に広めたいという動機につながることを期待しています。これにより、自然にファンベースが拡大し、結果的にブランドや番組が長く愛されるものになると考えています。

要約をベースに、メモ

段階的な発展の重要性: 樋口さんは、ポッドキャストのコンテンツや戦略を急がず、段階的に発展させることの重要性を強調しています。外部からの影響や反響に左右されず、しっかりとした基盤を築くことで、長期的に愛される番組を作ることができると述べています。特に初期段階では、番組の方向性が定まっていない時に外部の反響が大きすぎると、思わぬ方向に進んでしまうリスクがあるため、慎重な進行が求められると指摘しています。

SNS影響力の制御: ポッドキャストの告知や宣伝は、番組の形がしっかりと固まるまで控えることが推奨されます。SNSでの影響力が大きい場合、過度な期待やプレッシャーがかかり、結果として番組が不自然な方向に進んでしまうことを避けるため、あえて外部に広めず、内輪での熟成期間を持つことが重要だとしています。


個人のブランディングでも、発信によって影響力をつけるフェーズと、自力をつけるフェーズがあると思っている。発信によって影響力をつけるフェーズは、ある種スキルや時間の切り売りであって、そこでの純粋なインプットは少ないと思われる。 今の自分は、年齢は30代中盤に差し掛かろうとしているが、エンジニアに転職した時点でキャリアはほぼリセットされている。エンジニア転職して5年なので、社会人歴5年のつもりで生きている。 尊敬する山口周さんは「長期的にはインプットとアウトプットの量は同じになる。若い頃の無目的なインプットが超重要」と述べており、成田悠輔さんは20代の働き方として「若いうちは人目につくな」と述べている。 どちらも、若いうちには自分の興味が赴くままにインプットすることが長期的なキャリア形成においても大事という趣旨。

自分も、駆け出しエンジニア時代にはSNSの影響力をつけるぞ!と意気込みXのフォロワーを増やすために色々と頭を使っていた。当時は、「いいねやRTがいっぱいもらえそうかどうか」で投稿内容を決めていたし、自然とそういったインプットにもなっていた気がする。 それは本質的に自分が今すべきインプットではない場合もあったはず。

今ではXのフォロワー数やインプレッションを1ミリも考えなくなった。またストックとフローで考えた時、自分の思考や学びの軌跡はフローであるXではなくストックであるブログに中心に書くようになった。 ブログでは、Xよりも能動的に見にこなければ人の目に触れることはない特性があるので、心理的安全性が保たれている。

あとは、発信ありきでのインプットになると、いいねがもらえないとモチベーションにつながらないというリスクもある。誰も見てないやーくらいのノリでやっていれば、落ち込むこともない。

この状況で、20代のようにひたすらにインプットを続けていきたい。

コミュニティの育成と管理: 樋口さんは、コミュニティを一気に大きくしないことの重要性を語っています。コミュニティが急激に拡大すると、文化やノリが固まる前に多くの人が集まり、結果として統一感や一体感が失われる可能性があるため、慎重に人数を増やしていくことが大切だと述べています。また、少人数からスタートすることで、自然にメンバー間に階層やメンターシップが生まれ、運営側が過度に関与しなくても、コミュニティ内での文化が育まれるとしています。

文化の醸成と維持: 初期段階でのコミュニティ運営においては、文化の醸成を重視し、ノリや雰囲気が自然に形成されるように工夫することが大切です。特に、初期のメンバーが自発的に後から入ってくるメンバーをサポートする仕組みを作ることで、持続可能なコミュニティを育てることができると樋口さんは考えています。

忠実なファンベースの構築: 最初からのファンやコミュニティメンバーに特別な価値や誇りを感じてもらうことが、番組の成功につながるとしています。初期のファンが、自分たちが早い段階で番組を見つけたことに喜びや優越感を感じ、その満足感が他の人に広めたいという動機につながることを期待しています。これにより、自然にファンベースが拡大し、結果的にブランドや番組が長く愛されるものになると考えています。


採用と組織拡大においても同じことが言えそう。 一気に拡大すれば、大事にしたい文化が定着せず、結果としてすべてが機能しなくなるリスクがある。 また、古参メンバーの帰属意識をどうやって高めるか?という視点もとても大切。 新メンバーに文化を伝えるオンボーディング的な役割は、文化をよく理解し体現している古参メンバーにやってもらいたい。マネージャーのリソースは有限。

『アメリカはなぜ安倍晋三を賞賛したのか』読んだ

政治系の本は初めて読んだかもしれない。

現在の世界を正しく理解するには、政治・経済・社会とその歴史を知る必要があると最近強く感じる。大学生の頃から考えていたが、15年経ち、より深くそう思うようになった。

これまで政治に無関心だったので、興味を持つきっかけになればと手に取った1冊。結果的に、大きく目的達成できた。

安倍晋三元首相の活動や功績(慰安婦問題、靖国神社参拝、憲法改正など)に対する、日本と関係の強い外国の反応を、安倍氏を長年取材してきた記者目線で語る内容。

慰安婦問題、靖国神社参拝、憲法改正の議論の根底には歴史的背景があり、特に第二次世界大戦は現代社会理解に不可欠な知識だと実感した。

政治への興味が目的だったが、結果的に昭和史、特に第二次大戦前後への知的欲求が掻き立てられた。政治を知りたかったのは、歴史の文脈で当時の政権や社会情勢を理解するためだったと気づいた。

最も印象に残った(驚いた)のは、慰安婦問題での外国(特に中国)からの無根拠な批判を読んで、自分の中に怒りが芽生えたこと。 これまで全くと言っていいほど政治に無関心で、「日本人としての誇り」のようなもの特にないと思っていたのに、自分の中の日本人の心が怒っていた。

国内のリベラル派からの同様の批判には怒りを感じなかった。明らかに、「批判者が外国人であること」が怒りの原因だと思う。

歴史をもっと知りたくなり、その中での政治家の活躍についてもさらに学びたくなった。

『世界のエリートはなぜ「美意識」を鍛えるのか』

1年ぶりの再読。最近は仕事に直接すぐ関係しない本もたくさん読むようにしているが、その理由はこの本に詰まっている。今後も定期的に読み返したい。

ビジネスにおける3つの意思決定

1. アート

組織の創造性を後押しし、社会の展望を直感し、ステークホルダーをワクワクさせるようなビジョンを生み出す。 「美意識」はこのアート領域を指す。

2. サイエンス

体系的な分析や評価を通じて、「アート」が生み出した予想やビジョンに、現実的な裏付けを与える

3. クラフト

地に足のついた経験や知識を元に、「アート」が生み出したビジョンを現実化するための実行力を生み出す


上記3つが、どれか1つだけ突出していてもダメで、バランスが大事。

これまでのような論理思考に軸足を置いた経営、つまり「サイエンス重視の意思決定」では、VUCAと言われるこの不安定な時代を舵取りすることができない。「直感」や「感性」、いわゆる「アート」な決定も同様に重要。

なぜなら現実のビジネスでは、「数値化や論理で説明ができ、白黒はっきりできる問題」ばかりでなく、最終的にはリーダー個人の感覚で意思決定しなければならない場面が多くある。ここで必要になるのが美意識。

論理で説明ができるというのは、逆にいうと誰でも同じ答えに辿りつくことができる。つまり正解のコモディティ化が起こっている。差別化のためにも美意識が必要。

アート VS サイエンス

アートな意思決定は、ロジックで説明できない(説明できるならサイエンス/クラフト)ので、議論の場においてはサイエンスやクラフトにどうしても劣ってしまうとあった。直近の仕事で、まさにこうした場面に遭遇した。

上司であるCTOと同僚のEMがサイエンス的に導き出したGoの意思決定に対して、自分がいわばアート的な感覚でNoをぶつけた。「ワクワクしない」という非常に感覚的な理由でNoを伝えることになったが、最終的には自分の意見を尊重してもらえた。

まともに議論し「論理の正しさ」で勝負するとほぼ確実にアート側が負ける。アート的な意思決定を通すためには、日頃から信頼貯金を貯めておくことが大事だなあと、このブログを書きながら改めて感じた。

グレーゾーンで求められる美意識

変化が激しく法整備が追いつかない現代においては、「違法ではない(≒ グレーゾーン)」の領域が必然的に多くなる。その中では、道徳や倫理観に基づいての意思決定が求められる。つまり美意識。

近年の大企業の不祥事の数々は、まさしく美意識を欠いた意思決定の典型例。意思決定時には合法でも、後から遡って違法になるということもよくあるらしい。特に日本人は、違法性よりも倫理観を重視する傾向にあるらしく、より美意識が重要視される。

美意識の鍛え方

ではどうやって美意識を鍛えるのか?という話だが、本書の中では大きく4つ挙げられていた

  1. 絵画
  2. 哲学
  3. 文学

このあたりは、山口周さんが多くの著書で一貫して述べている「リベラルアーツを学べ」に通ずるところ。 最近は仕事にすぐ役立つか分からない哲学・歴史・政治などの本を読むことが増えた。間違いなく山口周さんの影響が大きいが、純粋に知らない領域の知識が増えていくのが面白くて続けられている。

『独学の技法』読んだ

独学を単なるインプットとしてではなくシステムとして捉え、より知的戦闘力を高めていこうという本。

読書後ブログ等でアウトプットする場合としない場合、明らかに前者の方が記憶の定着がいい実感があった。しかし、これまでその理由はうまく言語化できていなかった。「アウトプットするといい」のは漠然と理解できているものの、そのメカニズムはよく分かっていなかった。

本書を読んで、アウトプットする過程で何をアウトプットするか(抽象化)、どうアウトプットするか(構造化)の思考プロセスを経ることで、改めて整理された状態で記憶されるのだと理解できた。つまり、アウトプットすること自体よりも、そのプロセスに意味がありそう。

また独学の技法とは直接的な関係の薄い内容だが、個人的に最も刺さったのは以下の点。

「リベラルアーツを学ぶ意味④ 領域横断の武器となる」において、「リーダーになるということは『非専門家』になることである」と述べられている。その究極は社長。

リーダーの仕事は、領域を横断して領域内に閉じている領域専門家を共通の目的のために駆動させること。「何かおかしいな」と感じたら、非専門家としての立場から領域専門家に口出しをしなければならない。自分はマネージャーとして、ある種の非専門家としてプロフェッショナルのエンジニアメンバーと一緒に働いている。彼らと仕事をする上で、プロフェッショナルとしてのリスペクトを最大限持って接しているつもりだが、その反動として本来言うべきこと言えていないという状況はないか。振り返ってみると、少なからずそういった場面はある気がする。

しかし、「非専門家として専門家に口出しするのはいかがなものか」と遠慮するのはリーダーの責務を果たせていないことになる。

今後、自身の課題としてしっかりと向き合っていきたい。

以下読書メモ

- 独学はシステム
    - 戦略
    - インプット
    - 抽象化・構造化
    - ストック
- 重要なのは覚えないこと

## 序章
- 学ぶだけでも、考えるだけでもだめ
- ケーススタディは、「自分ならどうしたか?」を考えなければ意味がない
    - インプットが「学び」、抽象化が「考える」
- 戦略
    - 何をインプットしないか
    - 知的戦闘力を高めないものはインプットしなくてよい
        - 政治ゴシップ
    - 宿題)自分にとっての戦略は?
    - 戦略は、荒い方向性だけでいい
        - 偶有性からしか大きな学びはない
- インプット
    - 本やネットの情報は、誰かの知的生産物なので、それを元に知的生産するのは劣化コピー
    - 自分の五感で収集した情報は唯一無二
- 抽象化
    - 情報に意味づけする
    - 「問い」のないところに学びはない
-
## 第一章 戦う武器をどう集めるか

- テーマが主、ジャンルが従
- 盲目的な読書はバカになる
- いちチームにジャンルは複数またがる
- 自分が既に持っているものに着目する
- ポイントは2つ
    - クロスオーバー
    - 既にもっているものに着目

## 第二章 生産性の高いインプットの技法
- 長期的にアウトプットとインプットの量は同じになる
    - 機会費用
- メタファーとメトニミー
- 読書量に比例して読書スピードはあがる
- 情報量ではなく情報処理能力がボトルネック
    - 意図的に遮断すべき

## 第4章 ストック
- 記憶に頼らない
- いけすに情報という魚を生きたまま泳がす
- 分厚い知識ストックが常識を相対化する
    - 終身雇用は日本の伝統でもなんでもなく最近の話
- 常識を疑う「why」思考がイノベーションをうむ
    - 自分は全然ないなー
- 創造は、新しいものを生み出すのではなく、既存のものの組み合わせでしかない(by ジョブズ
    - だからこそ、アイデアの種となるストックを取れだけ持っておけるかが重要
- アンダーラインは「事実」「洞察・示唆」「行動の指針」に引く
    - 共感できない・反感を覚える情報にもアンダーラインを引く
- 転記する箇所は、「9箇所」に絞る
    - 9という数字に意味はない
    - 全て転記することはコスパ悪い
    - 絞る過程で、再度読み込むので記憶の定着は高まる
    - → ブログに書くのは、まさにこの行為
- 読書ノート、適度に読み返すことが重要

## おわりに
- 独学者こそが、世界を変えてきた

『LEADING QUALITY』読んだ

「品質文化をどのように組織に根付かせるか」がメインテーマの本。具体的なテストへの向き合い方が知れたのも大きかったが、自分も現場のマネージャーでやっている目標設定やビジョン作りについて言及があったのも面白かった。

品質はビジネスの成果と顧客価値に直結していることを再認識。

3つの品質ナラティブ

リーダーとして現場に変革を起こすために、まずは組織に根付く品質文化について理解する必要がある。

1. 責任ナラティブ:誰が品質に責任を持つかが考えられ、語られている

どう変化させていくのがよいか?でいうと、結論品質への責任は特定のチーム(QAやエンジニアチーム)が持つのではなく、組織全体に広げていくのがよいよね、という話。あらゆる部署がプロダクトの品質に直接関わっている。

2. テストナラティブ:品質向上につながる正しいテスト技法はどれか・どのツールを使うべきかが考えられ、語られている

いわゆる「どうやってQAするの?」の領域。QA界隈で最も語られるもの。

どんなプロダクトなのか?どんな開発手法なのか?ユーザーからの期待や要望はどのようなものか?こうしたコンテキストを踏まえ、テストナラティブは語られる。

プロダクトライフサイクルによっても適切なテスト手法は変わるので、テストナラティブは静的なものではない。

3. 価値ナラティブ:品質に投資した場合の見返り(ROI:投資収益率)が考えられ、語られている

QA界隈で最も語られづらいもの。採用・インフラ強化・ツール導入等の品質への投資は分かりやすいが、その結果としての顧客満足度の向上・社内業務の効率化・チームが費やす時間の短縮の測定は難しい。

収益性・コスト削減・リスク軽減の3つの観点で見るとよい。

テストの種類

テストには大きく2種類ある。1つは新たな情報を得るための「調査」と、もう1つは「検証」で想定通り動くかを確認するもの。

調査と検証、という区分は、『知識ゼロから学ぶソフトウェアテスト』では「探索的テスト」と「テストケースベーステスト」と表現されていた。直近うちのチームでも一人目QAエンジニアを迎え入れてQA体制の構築を行っているが、まさにの調査と検証を使い分けている。開発と並行して調査を行い、未知のバグを発見していく。ここでかなりの数のバグが見つかる。その後、テストケースで正しい仕様通り動くか確認していく。

本記事執筆時点ではテストケース作成前なので「検証」フェーズはこれから。QAとして意図的に調査を組み込むのは初めてだったので、どれほどクリティカルなバグが拾えているか、検証フェーズの結果が楽しみ。

自動化すべきか

なんでも自動化すればいいというものではない。自動化すべきかの判断基準が本の中で紹介されていたので、引用。

  1. 自動化されたテストケースが変更の手を入れることなく長期にわたって利用できると期待できること
  2. テストケースが比較的自動化しやすいものであること。すなわち、細部にわたる操作を必要としない手動テストから生成できるか。手順が複雑になるほど、自動化は著しく困難になる。
  3. 手動で実施するよりも自動化して実施および維持するコストの方が安い

基本的には費用対効果で考える必要がある。直近E2E自動テストツールのMagicPodを社内に導入したのでこれからシナリオを充実させていく予定だが、どこまでを自動化させるのか誰も判断基準を持っていなく路頭に迷っている感があったので、一つの基準として使ってみたい。

プロダクトライフサイクルと品質

フェーズによって求められる品質が変わるのは当然。また、数多の素晴らしいプロダクトで溢れている昨今ユーザーも目が肥えてきて当たり前品質の水準は日々上がり続けるので、MVPといえども品質の要求水準は高まる一方。品質が低すぎるとユーザーは2度と使ってくれないので、どこまで品質を求めるか?はユーザー感度の高さが求められる難易度の高い領域だなと思った。

適切な目標指標

プロダクトの種類によって適切な指標は3種類ある

1. アクションベースの成長指標

メディア、ゲーム業界等多くの toCエンタメサービスにおいて有効。DAU等。

2. トランザクションベースの成長指標

商品やサービスを購入させることが本質のEC、マーケットプレイスなど。Airbnbは予約成立数、Uberは乗車完了数など。

3. プロダクティビティーベースの成長指標

toBサービスの多くは、顧客の業務生産性を高めることが目的。顧客が与えられたタスクをどれだけ素早く成功させられるか。 Slackの「2000以上メッセージをやりとりしたチームの数」など。

アクションベースがアクションそのものに着目するのに対し、その結果に着目しているという解釈をした。

戦略の前にビジョン

明確に描かれたビジョンには、とてつもないパワーがある。自分たちはどこに向かいたいのかを示す最上位レイヤー。 ただ、ビジョンが役に立つかどうか、リーダー自身がそのビジョンにワクワクしている必要がある。

元々自分自身がビジョンを持たずに生きてきたタイプなので、未来や社会に目を向けるのはとても苦手という自覚がある。しかし、ビジョンを作り語るためには、未来や社会の視点が不可欠になる。自分がマネージャーとしてさらに飛躍するために、間違いなく重要な要素の一つ。しっかりと向き合っていきたい。

『努力革命』読んだ

ChatGPTの登場によるゲームチェンジを理解し努力の仕方を変えていこう。そんな内容の本。

前半はChatGPTの具体的な活用方法について書かれていた。読み進める中で、「ChatGPT、もっと使える」と強く思った。

ChatGPTやGitHub Copilot登場以来、エンジニアとしてコードを書く業務では生成AIを当たり前のように使うようになっている。しかし、それ以外でがっつり使えているかと言われると、正直そこまで活用できていない。普段のChatGPTの使い方を振り返ってみると、どうしても検索の延長の使い方をしてしまっている。プログラミングにおける知識は検索の延長というか、正解を求める使い方としても一定パフォーマンスするし、最近はWebのソースを参照して回答を出してくるので検索の延長としての精度も高くなっている。

本書で紹介されていた、「問題解決における課題の特定・解決策の検討」や、「学びにおける抽象化→具体化」の反復においてはまだまだ全然活用できていないので、さらに積極活用して知的生産力を高めていきたい。

後半は、これだけAIが普及した世の中で人間がやるべきことについて。

知識獲得や経験のコピー、論理的思考はAIの得意とするところだが、「あえて非論理的な意思決定をする」のは人間にしかできない。大きな成果を出すためには、「AIはA案が良いと言ってるけど、自分はB案がいいからB案にする」といった非論理的な意思決定が時には必要になる。山口周さんの「アート、クラフト、サイエンス」でいうアートの部分がやはり大事になってくる。『世界のエリートはなぜ「美意識」を鍛えるのか?』を改めて読んでみようと思う。

『知識ゼロから学ぶソフトウェアテスト』読んだ

チームに一人目のQAエンジニアを迎え入れるにあたり、自分もQAを体系的にインプットせねばということで、読んでみた。

デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developersというスライドにあるソフトウェアテスト読書マップを参考にした。

「テストによって全てのバグを見つけることは不可能」、「リリース後に見つかるバグは、要求の時点で見つかるの100倍修正コストがかかる」など抽象レイヤーで意識すべきこと、なんとなく意味は分かってる「ホワイトボックステスト」「ブラックボックステスト」の詳細や、はじめてきく「探索的テスト」の有用性など具体についてもバランスよく理解できた。まさにタイトル通り知識ゼロから学ぶのに適した1冊だなという印象。

以下、メモ

ホワイトボックステスト

  • ホワイトボックステスト = プログラムの論理構造が正しいかを解析するテスト
  • ウォーターフォール時代は、「開発者はホワイトボックステストで網羅率を担保、終わったらテスト担当者がブラックボックステストでバグをみつける」だった
  • アジャイルではそういった分断がなく、今後はテスト担当者もホワイトボックスを理解し、てすとkとしての限界を把握し、短いイテレーションでのテスト戦略を開発者と一緒に考える作業が重要になってくる
  • ホワイトボックステストは論理構造の正しさの担保なので、仕様そのものが間違っていることから起こるバグは発見できない
    • よって、ホワイトボックスだけでテストを終わらせることはできない
    • ホワイトボックスとブラックボックスの優劣の優劣を比較することはほとんど意味がない
  • 制御パステスト
    1. ステートメントカバレッジ
    2. ブランチカバレッジ
  • カバレッジ基準
    • ざくり、80%を目指す
      • 80%以上は、網羅率を上げるコストが一気に大きくなる

ブラックボックステスト

  • プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せずに(見ずに)テストを行う手法
  • 3つの手法
    1. 境界値テスト
      1. 基本中の基本
    2. ディシジョンテーブルテスト
    3. 状態遷移テスト
  • どうやってやるか
    • まず境界値テスト
    • 複数フォームがあれば、ディシジョンテーブルテスト
    • さらに、ダイアログ遷移があれば、状態遷移テスト

探索的テスト

  • 上記「テストケースベース」のテストに加え、探索的テストを行うことでより多くのバグ発見につながる
  • テスト設計・実行を同時にやる

    vs テストケースベーステスト

  • テストケースベースより多くのバグを発見できる
    • テストケースから見つかるのは全体の3%以下
    • → であれば、テストケースをいちいち事前に書くよりさっさとテストしながら考えて実行しちゃおうよ、という結論
  • テスト設計・ケース作成を早い段階でやりすぎると、序盤の作業が無駄になるリスクが大きい
  • テスト実行しながら、どこか他にバグが起こりやすい箇所を見つけて、弱い箇所を見つけたらそこを重点的にテストすることが大事
    • テストケースベースだと、これがやりづらい
  • 探索的テストもテストケースベーステストも、網羅率は同じ
    • ほんとに?とは思う
  • さらに、テスト担当者に開発者がプログラム構造を説明すると、探索的テストの網羅率が跳ね上がる
    • 探索的テスト+スキルのあるテスト担当者 の最強コンビでは、短時間で効果の高いテストが実施できる

要求仕様のテスト

  • 出荷後のバグは、要求仕様のバグの100倍修正コストがかかる
  • 大規模PJでは、全体コストの50%がやり直しであり、20-40%が要求に関するエラー
  • 要求の網羅
    • 1つの要求に対し、1つのテストケースが対応するわけではない
  • TDRE(Test -Driven Requirements Engineering)
    • 要求とテストケースを同時に作る

『マッキンゼー 勝ち続ける組織の10の法則』読んだ

新しい大きな発見があったというわけではないが、本書で出てくる内容は改めて大事よなーという感想。

新しい発見ややってみたいことをメモ。

第1章 優れた人材を獲得し、定着させるには?

  • データはいつでも人間に勝つ
    • マネーボール
      • 人の目ではなくデータを活用すべし

第2章 勝つために必要な人材を育成するには?

  • 継続的に成長する機会を得た社員は、その会社でキャリアを積む確率が2倍となっている。
  • 弱みよりも強みにフォーカスした研究の方が、2倍成長する
    • ex.
      • 有能な企業には、尖ったリーダー(秀でた強みがあり、他は平凡または足りないくらい)が多い。強みを伸ばしたということ。
    • 📝 KPTやFBにおいても、いいところをより構造的に伝える&深堀りしてみる。Problemはかなり具体で深ぼって振り返るけど、Keepはあまりしてない。なぜうまくいったのか?言語化してもらう。

第3章 潜在能力をフルに引き出すためには、どのようにパフォーマンスを管理すればよいか?

  • 優れたパフォーマンスマネジメントは業績向上につながる
  • 会社と社員のモチベーションを一致させる
  • 公平なプロセスを実現する
  • システムやデータではなく、人と対話する
    • 最新の人材管理システムを導入すればパフォーマンス上がるわけではない
  • 📝 人間の本質的な原理原則(心理学の範疇かな)、普段は結構忘れちゃってるので、意識的に使えるようにしていきたい
    • ex.
      • 行動経済学(予想通りに不合理)
      • プロセスに関わると目標達成度合いは高まる
      • 外発的動機付けより内発的動機付け

5 意思決定の質とスピードを高めるには?

  • 意思決定のアプローチをどのように調整するか
    • 関係者の広さ/重要度 x 発生頻度/内容への精通度合い の4象限で考える
  • RACIモデル
  • あらゆるバイアスに陥る
    • 確証バイアス
    • 楽観バイアス
    • 社会バイアス
  • 📝 意思決定はそれ単体で深堀したいので、別途本を買う

7 間接費を持続的に削減するには?

  • コスト削減は、ダイエットと似ている
    • 急激な削減(減量)は、大事なもの(筋肉)も多く失うことになる
  • 必要なものまで削減してしまっては本末転倒
  • 1%のレイオフ目標は、31%離職率を向上させてしまう

8 組織文化を競争力にするには?

  • 企業文化とは、「その辺りでのやりかた」
  • 企業文化は本質的にはコピーしにくい
    • トヨタのやり方を真似すればするほどうまくいかない
      • 手法を支える企業文化があってこそうまくいく
  • 企業文化が強い会社に他社から入ってきてうまくいかないパターンは多い
  • 企業変革の失敗は、七割が組織文化が原因

9 どうしたら組織全体を変革できるのか?

  • 変革しつづける
    • GoodからGreatへ(ジム・コリンズ)
    • いいときこそさらに変革を起こさなければ、変化の激しい時代に取り残される
      • 得てしてこういう時は現状を維持しようとする力学がはたらく
  • パフォーマンスと組織健康度を両方改善させる
    • 組織健康度の改善を中心に行い、パフォーマンスが大きく改善する例も多い