幡ヶ谷亭直吉ブログ
娘のここねと格闘するエンジニア。
『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術』を読んで ～ チームが認識を揃えてものごとを進めるために
読書メモ。2025年22冊目。
『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術』を読んでの感想となります。（2025/3/15記載）
本の概要
本書は、世界でも有数のドキュメント作成ノウハウを持っているGitLabを参考にした「ドキュメント作成」や「テキストコミュニケーション」の入門書です。
同社は、世界65カ国に2,000名を超えるメンバーが所属しているグローバルカンパニーです。
世界中のあらゆる場所や価値観、タイムゾーンに存在するメンバーのパフォーマンスを引き出すためには、ドキュメントが鍵であると同社は述べています。
情報が蓄積されたドキュメントが存在することで、必要な情報にいつでも多くの人がアクセスでき、信頼性の高い情報をベースに業務が進められます。
本書では、このような効果的なドキュメントがどうすれば作成できるのか、GitLabのドキュメント作成ノウハウに基づいて解説します。
また、GitLabのドキュメント作成方法はかなり具体的なルールや手法が示されていますが、その背景にある理論や研究についても触れることで、表面的な理解だけでなく根本の思想についても学習し、応用できるように説明します。
引用：
動機
- 今まで作るためのドキュメントにしか意識が無かった。
- プロダクトの成長に追随するドキュメントの扱い方が分からずにいる。
- GitLabのドキュメントを学びたい！！
感想
GitLabのドキュメントについて体系的に学べる１冊でした。
自分がプロダクト開発にあたるドキュメントをあり方を知りたかったのに対してはもっと俯瞰した内容でした。
ただ、そのことでよりドキュメントに求められる目的であったり、意義を認識することができました。
今のチームでは、開発プロセスにおける個々人の作業を、どうやってチームとしての経験として消化できるだろうかと悩んでいる部分があったため、感覚や感情も含めてドキュメントにアウトプットする、という内容は大きなヒントになりました。
また、目的な記載やイテレーションなど当たり前とも思える部分も、改めて念頭に置きたいと思いました。
また、何より自分の捉え方を見直したいと思ったのは、ドキュメントは作成者のものではなく、チームのものであるということ。個人の認識で作ったドキュメントも相互理解を深めて共通認識のものにしていく過程で、個人のものからチームのものに転換していく。
そうすることで形骸化せず持続的にアップデートできるものになるイメージができました。
具体的な設計ドキュメントについても、今回の書籍を念頭に策定していきます。
忘れたくないメモ
■ドキュメントの意義
あらゆる人たちと協力して物事を進める上で、ドキュメントという客観的な場でお互いの情報をアウトブットして確認し合うことが効果的。
■プロセス・ロス
チームで個々人の何をなすべきかの認識がずれから発生するパフォーマンスの非効率をプロセス・ロスと呼ぶ。チームの方針が定まっていれば、認識のずれが発生することもなく、関係悪化という事態も生じない。
■認識のずれによる影響
過去の経験や物事の捉え方によって、個々人の認識の枠組みは異なっているため、何を達成するべきなのかという目的や優先順位が一致していないと食い違いが発生する。
■チームの認識の揃え方
チームになることで発生する認識のずれも存在し、無意識のうちに自分一人のときよりもペースを落としてしまう「社会的手抜き(social loafing)」や「調整の損失(coordination loss)」と呼ばれる現象もプロセス・ロスの一種。互いの認識をドキュメント上で明確にすることで、認顔のずれをそろえるための議論ができるようになり、コストパフォーマンス良く客観的な視点で物事を処理できるようになる。
■定性的な内容も含め共通認識を作る
感覚や感情も含めてドキュメントにアウトプットすることで、認識の違いを乗り越えるヒントになる。異なる人間の間でそれぞれが感じている現実を説明し、理解し合うことで共通認識を作り上げる。共有された現実を「意識的に作る」ことが、チームでコラボレーションする上で重要。ドキュメントを活用する際には、「共有された現実」を作り上げていくことが目的であることをチームの共通認識として持つ。
■教養
「教養」とは単に物事の知識が豊富であることではなく、相手との対話の中で「互いにより良いものを目指してい姿勢」（ヘーゲル）。ドキュメントの考え方も、ソフトウェアがより効果的に機能するように改善し続けるという意味では教養的な存在。
■認識の土台を構築する
多様な存在である私たち一人ひとりが持つ異なった認識を、ドキュメントを活用し共通の目的にし、客観的に見ることで認識の食い違いを乗り越え、あらゆる人にとってより良い認識の土台を構築することを目指す。
■すべてのドキュメントはより改善できる下書き
GitLabのValueのひとつ「Results for Customers(顧客のための成果)」の中に、「活動ではなく影響を計測する」という行動指針がある。顧客やチームメンバーに影響を与えなければ成果とはいえない。まずは、他の人の目につく場所に公開し、顧客やチームメンバーに影響を与えることが重要。こうした考え方から、すべてのドキュメントはより改善できる下書きであるというスタンスを取ることができる。
■目的の明示
ドキュメントが達成したい目的を記載することで、ドキュメントに記載すべき情報の取捨選択がしやすくなり、目的が達成できる内容になっているかのチェックもできる。ドキュメントを公開した後、読者の反応を見ることで目的が達成できているのか振り返りができる状態になる。読者が目的が達成されないと感じた場合、作成者に追加の情報を求めたり、読者が情報を追加したりすることで、より多くの人に価値あるドキュメントに改善していくことができる。
■ディビッド・ゴルフ「経験学習モデル」
具体的経験 (Concrete Experience)
→内省的省察 (Reflective Observation)
→積極的実践 (Active Experimentation)
→抽象的概念化 (Abstract Conceptualization)
■イテレーション
最小限の変更で素早くリリースして、ユーザーのフィードバックを受けながら、改善を積み重ねる。
■オピニオンの記載
ファクトではなく、ファクトに基づいたオピニオンとして「だから何? (So what?)」を伝えるようにする。
■目標意図と実行意図
行動変容を促すために、「目標意図」と「実行意図」を考慮する。
目標意図とは、「なぜ行動を起こす必要があるのか」という目的が伝わっているかという観点。メリットや解決すべき課題を明確にすることで示す。ドキュメントを読んだ人がやる意味があると思えるか。
実行意図とは、「具体的にどうやったらいいのか」という目的が伝わっているのかという観点。やる意義が伝わったとしても、やり方がわからないと行動にはつながりづらい。どのようにやれば達成できるのかという具体的な方法を明示する。
■意図をしっかり伝える
ドキュメント作成者と読者の間での解釈の違いや曖昧な部分を、詳細な言語化を行い解釈性の低いドキュメントに改善していくことを繰り返す。これによりドキュメント作成者が意図しているメッセージが、誤解なく相手に「伝わる」ことを追求できる。ドキュメントやメッセージの意図をしっかりと伝えるためには、情報にアクセスしやすいことと解釈の余地が少ないことが重要となる。
D-Plus Tokyo #12~個人の工夫をチームの力に！開発生産性向上の文化づくりどうしてる？ に行ってきました
D-Plus Tokyo #12に行ってきました。念願のオフライン参加でした。
イベントの概要
日々の業務で「もっと開発をスムーズに進めたい！」「チームで生産性を高める方法を知りたい！」と思ったことはありませんか？ 個人が工夫している開発生産性向上の取り組みを、チーム全体の文化として根付かせることができれば、より快適で効率的な開発環境を作ることができるかもしれません💡
しかしながら「個人の改善がチーム全体に広がらない…」「せっかくの工夫が属人化してしまう…」「チームの文化として定着させるにはどうすればいい？」と言った悩みを抱えているエンジニアも多いのではないでしょうか？🤔
本イベントでは、開発生産性を高めるために個人レベルで実践している工夫をどうチームの力に変えていくのか、実際の事例やヒントをLT形式で学び、交流会を通じて、他のエンジニアと情報交換しながら、すぐに実践できるアイデアを持ち帰れる場を提供いたします。
引用：
イベント参加の背景
- 開発生産性についてあれやこれやトライ&エラーしている。
- D-Plusさん現地に行きたいと思いつつ、いつもオンラインで拝聴。
- 今回のテーマはどれも明日の現場に持って帰れそうな内容のためいざ現場に！
開発生産性向上LTメモ
- そのドキュメント、ちゃんと息してる？〜 使われ続ける“生きた”ドキュメントの育て方 〜
ドキュメンテーション、ただの文字列ではない。
誰にでも整理できる状態にすることが重要。
プラス：情報の散在防止。業務品質の均一化。業務属人化の解消。
マイナス：化石化。
ドキュメントのサイクルで化石化させない取り組みをする。
情報選定：価値あるものだけ残す
→文章化：ドキュメントを書くコストを下げる
→編集権限開放：属人化させない
→定期的更新運用：運用の仕組み化 - やっぱり余白が必要だった話
個人の自主的取り組み。フロー効率を大切にしている。
隙間時間で改善をすることは、改善が想定より時間かかる場合は、
本来進めたかった作業にも影響がかかる。
そのために、以下を実施。
①計画的なチームの余白を作る。
②計画外の余白をうまく活用する。
後者はTidy Firstをヒントに、隙間時間でソースコードの整理をしている。 - 生産性を可視化にいたるまでの上位/下位組織へのコミュニケーション
目標ドリブンな有機的な組織に。
生産性の向上は受け入れられたが、費用対効果はシビアだった。
エンジニアのコスト懸念に対して、Findy+で見える化。
内省化も含めた組織強化。
生産性の見える化は途中。生成AIで生産性向上を目指している。 - もう一人で悩まない！個の知見をチームの知見にする3つの習慣と工夫
何のための開発生産性か。ユーザーに早く価値を届けたい。
ドキュメント、開発手法、ドメイン知識、これらがすぐに分かりたい。
オンボーディング、開発を進めるうちに知る。
各自が学んだことを伝搬するとチームが強くなる。
スタンドアップで学びを共有する、ペアプロで経験を共有する、ふりかえりで方向性の再確認をする。 - エンジニアリングマネージャーの試行錯誤～自律的なチームへのくふう～
自律的なチームのためには内発的動機づけが重要。
組織的横断的なLT会、情報共有会、チームリーダーとの設計・コードレビュー。
新しい技術に関する勉強会開催。トレンド技術のキャッチ活用。
TDD/テスト駆動開発勉強会。
組織のサポートが重要。チャレンジ賞賛風土。結果、開発生産性に繋がる。
懇親会
メガテック企業のエンジニアの方とのアジャイル開発についてのお話したり、
チームや組織での開発生産性に向けた課題感などお聞きし、学びの多い時間でした。
やっぱり、自分と異なる組織、開発現場の話はこうゆう機会が無いと知ることができないから貴重です。
ありがとうございました。
感想とまとめ
今回ドキュメントが一番気になっていた内容でした。
私のチームでもシステム仕様を記載したドキュメントが、システムの拡張に追いつかず刷新したばかりでした。
チームが取り扱えること、開発のプロセス上に配置することをポイントに刷新。
今日の発表をもとに今後運用する上でメンテナンスコストや仕組み化も考慮したいと思いました。
偶発的に余った時間の取り扱い方ももやもやしていた部分があったので、Tidyタイムに充てるのは気持ちよさそうでした。
エンジニアとしてもケント・ベックの名のもとにモチベーションあがりそう。
内発的動機づけは意識しなくてはと思いつつ後回しにしてしまっていたので、改めて向き合いたいと思いました。
気軽に取り組めるチームの学習機会を作りたい。
1日15分でもみんながみんなに伝えたいことをただ話すような時間を作るか…
いったんやってみよう。学習はコミュニケーションで伝播する。
初オフライン参加、懇親会でのコミュニケーション含め学びが多かったです。
D-Plusさん、また参加したいです。
娘の未来に続くチームトポロジー
５歳の娘へのホワイトデーのプレゼントに、ポケモン図鑑を購入しました。
娘はアニメ『ポケットモンスター』に夢中で、毎日「どのキャラクターが何に進化するの？」と尋ねてきます。
そのたびにスマホを取り出して調べて答える、という日課が続いていました。
こうしたやりとりが一日に何度も繰り返されるため、娘が自分で調べられるようにと、ポケモン図鑑をプレゼントすることにしました。
図鑑のおかげで、きっと娘は知りたいときに自分で調べることができるようになると思います。
その結果、私は娘から尋ねられるたびにスマホで検索することがなくなると思います。
図鑑を読むことは娘にとって文字を読む練習にも繋がります。
文字が読めるようになれば、娘はさらに多くのことを知り、考える機会が増えるでしょう。
考える機会が増えると、娘の世界が今よりもずっと大きく広がっていくと思います。
広がっていった先には、おそらくポケモンと同じように、もしくはそれ以上にわくわくするものが待っていると思います。
こうして少しずつ娘が自分のことを自分でできるようになっていく姿を見ていると、いずれは親のサポートが必要なくなる日が来るのだと感じています。
そう思うと、親は子供の人生の伴走者というよりは支援者であることに気付きます。
娘がより良い未来にたどり着くことを主目的として考える。
子育てを通じて感じるチームトポロジー。
きのこカンファレンス2025 に行ってきました
エンジニアがこの先生きのこるためのカンファレンス2025に行ってきました。
年齢的にも行かねばと楽しみにしていたカンファレンス。
イベントの概要
「エンジニアがこの先生きのこるためのカンファレンス」は、参加される方がそれぞれのキャリアやロードマップを見つめ直し、自身の未来を描くヒントを得ることを目的に開催するITカンファレンスです。 登壇者を40歳以上のベテランエンジニアに限定して、エンジニアとして長い時間を歩んできた彼らから経験や知識を吸収することで、参加者が末永くエンジニアを続けられることを目指します。 現役ITエンジニアをはじめ、デザイナーやマネージャーなど周辺職に就かれている方、ITエンジニアを目指す学生など、幅広い方にご参加いただけます。
引用：
イベント参加の背景
41歳を迎え今後のエンジニアとしてどうしていくかを模索している。
まだまだやりたいことは多くある反面、年齢的な制約も少し感じたりする。
- この先も生き残るためにいろいろな方のお話聞きたい！！
持ち帰るところの多かったセッションメモ
オープニングトークから最後の企画まで参加してきました！
- オープニングトーク
登壇者を40歳以上のベテランエンジニアに限定。
ネーミングは2002年2chの【この先生きのこる】から。
登壇者の経験から学ぶことからヒントを得る。
末永くエンジニアを続けるためのイベント。きのこなだけに味わい尽くす。 - 自分のためから誰かのためへ
誰かのためのすることは巡って自分のためになる。
かつて。完全に個人主義。自分がどれだけ貢献したかを重視。
リーダーへ転生。小さなプロジェクトは今まで通りでなんとなかった。
大きなプロジェクトではなんとかならず、当時のリーダーを思い出す。
傾聴、信頼、調整。まずは信頼を得ることから。誰でもできること。
主語を自分からチームに。チームファースト。
仕事は雰囲気作りも大事。
ユーモア。結果、心理的安全にもつながる気がする。
真面目さ。方針、軸となる
ユーモア×真面目さ。
多職種との協働。ビズ側。
営業から直接ダイレクトにフィードバック来る。
エンジニアの正しさと営業の正しさは違う。
お互いに必要なことを考えている。お互いを支え合うこともある。
生き残れた理由は、
・傾聴・信頼・調整
・やりきる
・必ず誰かがいることを意識する（ユーモア×真面目さ、他職種）
自分が誰かのためにしたことが、自分が生き残れた理由となった。
そのためにも、若手の背中を押す。 - 引き際は自分で決める！〜究極の選択と還暦で定年の無い企業に転職した話〜
定年が60歳。再雇用は65歳までだったので58歳で転職した。
年齢を重ねると健康寿命がキーワードになる。
65歳に近づくほど難しいので、速めに転職を始めた。
安定とチャレンジの天秤。当初の転職に対する判断を思い出し決断。
実際に正社員にもなった。自分で止めると言わない限り止めない状態。
止めるときの判断。自分での判断は客観性に欠ける。
定期的な1on1を通して、チェックを想定。
引き際は周囲と相談して決める。 - ランチセッション
- 貧民的プログラミングのススメ
世の中大きいものが出て廉価版が出る。
廉価版が続いてから、進化したものが出てくる。
いつかは貧民のプログラミングが生きてくる時がくる。
生成AIも高性能・高機能からDeepSeekへの流れがある。
貧民的プログラマーはドメインエキスパートになるチャンスもある。
貧民PGはスキル地味、活躍場面限られる。ヒットすると強い。 - キャリアを考える為の情報収集スタイルの多様化、その中でのエージェントの役割について
情報や選択肢が多すぎる。
スキル・キャリアパスの多様化。採用スタイルの多様化。働き方の多様化。
多様化が増えた分、情報の入手に困っている。
キャリアエージェントとしてやっていること。
情報の整理×潜在的な意識に向き合う→ひとりひとりにパーソナライズした情報提供 - No Day but TODAY: 20, 30代, 40代で起きたこと, 考えたこと, 行動したこと
20代、死にそうになった。死ぬ前にもっとやりたいことがあることに気付いた。
30代プライベートの翻訳を通して新しい企業に出会った。
新しい企業でいろいろなことをやっていたら、何をやるか分からない大きな仕事が舞い込んできた。
選んだうえで後悔しないように進んできた。
それが将来の自分の姿を大きく変えていく。
- 貧民的プログラミングのススメ
- 生きのこるLT会
- リカレント教育は役に立つのか ‐偏向な実体験を通して -
役立つ。業務の疑問解決。体系的・網羅的学習ができる。
やらない後悔より、やって後悔。 - リモートワークだからこそ20年以上もエンジニアとして仕事が続いたのかもしれない話
妊娠・子育てをきっけかにリモートワーク。
仕事はペースダウンした。 - 家族をスクラムチームに！アジャイルで取り組む家事と育児
確約：その日のゴールの明確化
集中：家事のやるべきことの明瞭化
公開：手順、予定
尊敬：リスペクト、尊重
勇気：判断が必要となる時の決断力
家事と育児を自分事にするためにスクラムの取り入れ。
詳しくはnoteに。 - 今から始める8bits CPUアセンブラ言語
80系と68系は戦っている。 - インターネットは世界と繋がっている。飛び出してみたら格段に世界が広がった話。
自分の殻を破って外に飛び出すと良い、という話。
留学前、引っ込み思案だった。
留学中、PjM、インターンを受けた。マネジメントの新しい視点を受けた。
帰国後、思考・行動・コミュニケーション・挑戦に対する変化があった。
刺激的な環境がアクティブさを醸成した。
異文化環境が意見交換の楽しさを教えてくれた。
- リカレント教育は役に立つのか ‐偏向な実体験を通して -
- 「ラベルにとらわれない」エンジニアでいること
fortee.jp生き残るためにはラベルに捉われないこと。
けど、捉われる。
目指せるロールモデルがいない。女性のリーダー層少ない。
無意識バイアス。制度の課題。ただ、母数が低いと扱いづらい。
黄金の３割理論。少数派は30%以上にする。
インポスター症候群に適切な支援をする。
積極的に発信することで、支援したいと思っている。
コミュニティでの活動で横のつながりが生まれた。孤立の解消。
カジュアル面談で色々な声を聞くことができた。
ラベルを自覚して克服する。捉われなくなる状況を目指していく。 - 50代フリーランスが考える、軸をぶらさずに変化に強くなるバランス感覚の鍛え方
fortee.jpnunulk-blog-to-kill-time.hatenablog.com
キャリアとは、より良い仕事を得る。より多くのお金を稼ぐこと。
目的を達成するための道のり。
心身の安定、力を最も効率よく伝える、作用の検証。
軸。検証を行って随時補正するもの。
バランス。自己戦型、個人戦型、団体戦型。
バランス感覚鍛えるために。
問題の認識。型の認識。軸の認識。認識の調整。
外部認識→内部認識→認識調整。
学びは訓練する。変化への適応は気付き、訓練、勇気が重要。
バランスを取る時の罠。型、固定概念、コンテキスト、バイアス、論理的思考。
最後は勇気をもって行動する。 - ソフトウェアエンジニアのキャリアパスの描き方と、その中で自分が大切にしてきたこと
エンジニアのキャリアパス。
エンジニアのキャリアパスは一方通行ではなく行ったり来たりする。
マネージャーやってからプレイヤーに戻ってもいい。
SSE、TL、EMは、グレードの序列関係は無い。EMが一番低いというケースもある。
複数スキル、経験の掛け合わせで勝負すると、レアリティ（≒市場価値）が上がる。
各軸は技術（IC）、事業（SSE、TL、EM）、経営（CTO、VPoE）と別れる。
マネージャー経験後にICに戻ると、掛け合わせの強さを感じる。
大切にしていること。
・また一緒に仕事をしたいと思ってもらえること。人とのつながりの方が寿命が長い。
・IT業界は狭いので、言動や振る舞いには気を付ける。 - ライフステージの変化を乗り越える探索型のキャリア選択
転職は点。キャリアは線。線をドラフトする。
カレイドスコープキャリア理論。
個々人のキャリアにおいて、ステージごとに重要なポイントが異なる。
挑戦、バランス、真実性。ステージは年齢で特定はできない。
ライフステージの傾向。
アーリー→ミドル。全部自分がやるができなくなる。選択と集中が求められる。
ミドル→レイター。自分が何者であるか、ミッションが重要。
それ以外に向き合うこと。技術、スキル、役割、ライフステージ。
ひとつひとつの変化に向き合うことが重要。チャレンジとともに領域を広げる。
選択肢が見えたら行動をする。
最終ゴールを先に見据えてキャリアを刻むのは変動性が高すぎて現実的ではない。
探索的にキャリアを刻んでいく。 - 「知識」と「知恵」を区別して時流を乗り切る〜50年経っても現役でいられるために〜
40年間やってきている。今は執筆系＋開発系。
これまでを振り返る。
無茶ぶりでもことわらない。一つの技術に拘らない。
良いものがあれば使う。新しい技術を学ぶ。知らないことでもやってみる。
知識と知恵。
知識：仕組み、操作など。仕様・決まりごと。
知恵：動かし方など。原理原則。
知識は新しいものが次々出てくる。知恵はそんなに登場しない。
知恵、オブジェクト指向、イベント駆動、LLM、量子コンピュータなど。
入出力をいじっているだけ。
目的：入力から出力を作ること。
〇〇したいから□□を使う。〇〇が知恵、□□が知識。
技術は階層構造を取っている。
応用技術を知っていれば、基礎理論・技術を知らなくても使える。
但し基礎をすれば横に広がる。新しい技術の登場時の学習コストも軽減できる。
今後、１つの技術では生きられない。
基礎的な考え方は変わらない。「データを入力して加工して出力する」
基礎を知って新しい技術を習得する。
決めた出力を出すプログラムが出せればＯＫ。手段は拘らない。
今回の話を書籍に。
技術の波に乗り遅れない！すべてのITエンジニアのための「一生モノの学び方」 - AIが台頭する時代のエンジニア進化論：価値探索とAI-Human Interfaceのスペシャリストへ
プロポーザル当時と比べ、年末あたりから状況が変わってきた。
今はまだ簡単なタスク。今後エンタープライズ領域でも人がいらなくなる。
社会的には良い影響がでてきている。
既存のスキルセットに固執すると脅威だが、新しいスキルを習得すれば大きな機会。
今度の変化のインパクトは大きそう。
エンジニアリングの本質的な複雑性は、誰にどんな価値を届けるか。
技術ではなく、技術をもとに価値提供することがエンジニアリングの本質。
HOWは劇的に変わるが、Why、Whatは本質的に変わらない。
課題設定、価値探索はPdMだけの仕事ではない。
言われたことをやるだけではAIには勝てない。
AIエージェント。関心の分離とモジュール化が十分にできていればレビューは必要ない。
今後、ドメインエキスパートとの共創がより重要となる。
エンジニアリングの本質は価値提供。
今後、偶有的な複雑性はAIが抽象化してくれるはず。
要望から要求までをAIがやるとしたら、人に残るのは意思決定の部分。
意思決定とは、仮説立案。仮説検証ならAIでもできる。
野性は、知性と野蛮。経験主義。これをリーンに繰り返すことがスクラム理論に通じる。
事業・プロダクトに興味を持つ。
興味対象を分析するためにAIも利用できる。
目的、知りたいこと、観点、ソースをもとに分析をかける。
ここまでは一人でできるが、それ以上は共創するチームに持ち掛ける。
開発だけでなく、業務側、ビジネスも巻き込む。
野性の対話を通すことで魅力的な価値が生まれる。
エンジニアリングの本質は野性。
AIは時代が求める速さに追随するためには不可欠となる。 - 変わりゆくもの、変わらないもの。
減る仕事、無くなる仕事がある一方、新しい仕事が生まれている。
ITエンジニア不足は続いている。生産性向上率を毎年5%上げる必要ある。
人、技術、社会は相互に影響し合って進化している。
技術決定論。技術で社会は規定されている。
我々はソフトウェア開発という社会的な営みの一端を担っている。
道具の進化で高次な仕事ができる状態になっている。
変化を恐れず学ぶことを楽しむ。
設計の原理原則：関心の分離、高凝集、SOLIDなど
ソフトウェアエンジニアリング：要求分析アーキテクチャ
思考力：具体と抽象の行き来、構造の把握
学び。
知識は伝わらない。認知的リソース×環境の提供するリソースでの創発。
抽象化と適用をする。
具体→抽象→高次の抽象とすることで、異なる状況下にも転用できる。
ものごとの本質をとらえる。抽象度のレベルを自由自在に操れるようにする。
技術、マインドセット、思考力を磨く。 - 企画
- 過去の自分への手紙
自信を持つことでさらに良い結果に繋がり更に良い結果に繋がる。
キャリアの棚卸をすることで、自分の内省につながる。
毎年やった方が良い。 - みんなの歴史年表
オーセンティシティ＝何のサービスに触っているかを話せること。
エンジニアのアウトプットにつながっている。
かつては文章化されていなかった背中を見て覚えていたような 流儀が、文章になって共有されるようになっている。
アピールには２種類ある。
やったことを伝えるもの。実現した効果を伝えるもの。
自己開示に繋がる。
同じことを複数人の人がしゃべったら複数主の発表になる。
社外で登壇することでコミュニケーションが増える。
未来に何があるかはわからないが、キャリアを積んでいく。
- 過去の自分への手紙
出展ブース
転職ドラフトさんのブースで年表ボードに参加できて嬉しかったです。
よくよく考えたら、新卒から今までよく生き残ってこれたなと思いました。
他にもキャリアや生活を考えるような取り組みも多く、自分を振り返ることで学びに繋がりました。
先日のemconf_jpに引き続きカケハシさんの珈琲も美味しく頂きました。
感想とまとめ
人生を浴びた１日でした。
経験からは学びが生まれるし、学びは成長を促す。
それは共有されることで、他の人の成長にも寄与する。
それが実現されるのがコミュニティの良いところと実感した１日でした。
「データを入力して加工して出力する」。
そこに野性味のノイズを加えられるのはエンジニアだけだし、
高次の抽象まで飛ぶことで適応することにオーナーシップを持つことができる。
それが個人ではなく、複数人、集団の視点で取り組み前進させていくことで、
まだまだエンジニアが生き残れる未来のイメージができました。
自分への手紙のコーナー。
私の投稿を扱って頂き嬉しかったです。
いつか少し酔っ払った日にエイって投稿したやつでした。
取り扱われたら少し恥ずかしいなと思いつつ、エイっとしたのは
何もしないより何かした方が無ではないと思ったからでした。
20代CD出して遠征していろいろわくわくしていたけど、今エンジニアとしてわりと毎日わくわくしている。
ミュージシャンを諦めたきっかけが気になる#きのこ2025#きのこ2025_a
— hmatsu47(まつ) (@hmatsu47)2025年3月9日
…変な雰囲気にしていなかっただろうかと気になりエゴサです。
超ブラック企業だったので責務の面では動きやすかったものの、
30代を迎える迄に音楽で収入を得る状態まで行けず、少し前に父親が倒れたこともあり…
といった話も、今の今まで楽しく生き残っているので、諦めたことにそこまで縛られていません。
そして、今でも時々ライブができているのも幸せなことと思っています。
生き残ることは、ひとりではできないことであり、誰かと何かを共有していくことだと思います。
エンジニアがこの先生きのこるために知見を共有する会って素敵だなと思いました。
来年あったらプロポーザル出したい！！
『システム運用アンチパターン』を読んで ～ 職能の垣根を越えてプロダクトと向き合うために
読書メモ。2025年21冊目。
『システム運用アンチパターン』を読んでの感想となります。（2025/3/8記載）
本の概要
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。
重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。
組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。
引用：
動機
- 先月から延長戦となったDevOps強化月間。
- 『The DevOps ハンドブック』『Effective DevOps』と並んで積んでいた一冊。
- これで多角的に捉えることができる気がする！
感想
『The DevOps ハンドブック』、『Effective DevOps』に比べると読みやすく実践にも踏み込んだ印象。
やはり、DevOpsとは、開発と保守のサイロを（もちろんそれ以外のサイロも）壊すという価値観のもと、各領域内で最適とされていた方式を見直そう、というムーブメントなんだと理解しました。
そのうえで、アンチパターンとしてフォーカスすべき領域を示してくれている本書は、やはり前２冊に比べ具体的なアプローチ方法のイメージがつきます。
ただ、それ以上に足を踏み込んで実現していくとなると、保守メンバーという役割は重要になり、結果サイロのしがらみから離れずらく、結果プラットフォームエンジニアリングが重要しされる、ということも理解できました。
これでいったんDevOps関連の書籍はしばらくは良いかなと思いつつ、もっと早くこの思考を学んでおけばよかった、と思いました。
実践で必要になってきたら、もっと具体的な内容の方も追っていきたい。
忘れたくないメモ
■責任の共有
DevOpsはソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有することを重視。
開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、職能の垣根が低くなる。
■DevOpsの優先順位
DevOpsはチームが一緒に働くことについて考える。
DevOpsはまず人、次にプロセス、そしてその次にようやくツールについて考える。
■4つの柱
DevOpsは文化(culture)、自動化(automation)、メトリクス(metrics)、共有(sharing)の4つの柱に支えられている。
■人為的な障壁を取り除く
伝統的な組織では将来の問題を防ぐために承認プロセスを採用する傾向にある。DevOps組織ではこの衝動を全力で抑える。価値を付加するものは残しつつ人為的な障壁を取り除くことに常に気を配る。
■人為的な障壁の弊害
人為的な障壁はチーム間のパワーダイナミクスを生み出し、依頼をする人と承認をする人の間に親子のような関係をもたらす。権力の不均衡を生み出し、チーム間の摩擦につながります。
■チームメンバーにオーナーシップを求めるために
知識を共有することは責任を共有するために必要。そのためには共有を促進するしくみを作る必要がある。責任の分担が増えると情報をため込むインセンティブが失われる。責任の拡大に対応するためにはシステムの全体像を少なくとも一定のレベルで理解する必要がある。チームメンバーの学習ニーズに何らかの形で対応しなければ、チームメンバーにさらなるオーナーシップを求めることはできない。
■効率的で迅速なデリバリのための自動化
DevOps組織では依頼に対するゲートを追加せず、効率的で迅速なデリバリに重点を置く。こうした効率的で迅速なデリバリは、ボトルネックを追加するのではなく自動化するという解決策によって可能になる。
■手動の承認プロセスの弊害
手動の承認プロセスは簡単に迂回できるため、あるデプロイと別のデプロイの間にばらつきが生じる。プロセスを監査したり、プロセスが毎回正確に手順にしたがっていることを確認する際に、ばらつきがあることは非常に苦痛。何の価値も生み出していない承認プロセスを自動化する。
■本番環境でのアプリケーション動作
開発者は自分たちが開発したシステムが本番でどのように動作するかを詳細に理解することが求められている。システムが成長し、ますます複雑になるにつれ、本番前の環境で完全かつ徹底的にテストするのは不可能になりつつある。本番環境で初めてテストされる処理もあるため、開発者は自分のコードが本番環境でどう動作しているかを理解できなければならない。
■プロダクトの正常が何かの理解
プロダクトを理解することはDevOps組織では必須。プロダクトを理解することで、システムが期待通りに機能しているか確認するためのメトリクスをより深く理解できる。運用チームが異常事態に対応するには、正常が何かを理解している必要がある。ツールに関する専門知識と会社のプロダクトやビジネスに関する知識の組み合わせが運用エンジニアの価値であり必要とされている。
■運用の可視化
運用の可視化はメトリクスとログによって可能になる。メトリクスとはシステムリソースのある時点での測定値。ログはシステムで発生したイベントを記述したメッセージ。ログにはイベントについての説明が記載されており、メトリクスよりも細かな詳細を把握できる。
■システム動作を理解する３つのメトリクス
システムの動作を理解するには、スループット・エラー率・レイテンシが役立つ。これらのメトリクスについて考えるということは測定対象について、どのくらいの頻度でこの処理が発生しているか？どれくらいの頻度で失敗しているか？完了するまでにどのくらいの時間がかかるか？質問をすること。
■メトリクスの種類
メトリクスには一般的にゲージとカウンタという2種類がある。ゲージはある特定の瞬間の数値を表し、カウンタはあるイベントが発生した回数を表し増加し続ける値。
■メトリクスへのプロダクトチームの関与
健全なメトリクスのためにプロダクトチームも巻き込む。レスポンスタイムのようなメトリクスでは、プロダクトチームが何が大切かを判断できる。プロダクトチームに健全なメトリクスを定義するプロセスに参加してもらい、理解してもらうことで、許容できるパフォーマンスについて全員の合意を得ることができる。
■故障モード影響分析 (FMEA failure mode and effects analysis)
FMEAの目的は、プロセスを詳細に調査し、プロセスが失敗またはエラーになる可能性のあるすべての領域を特定すること。ここでいうプロセスとは、システムが正常に動作するために相互作用する必要のあるさまざまなものが相当。
エラーが発生する可能性のある箇所を特定し、エラーを3つの軸で1から10の尺度で評価する。
1つ目の軸は深刻度。そのエラーが発生した場合にどれだけひどいことになるかを評価する。各企業におけるビジネスへの影響から深刻度の順位付けをする。
2つ目の軸は発生頻度。エラーがどのくらい発生しやすいかを評価する。
最後は検出可能性。社内の監視システムやメトリクスがエラーを検出する前に、顧客がそのエラーに気付く可能性を評価する。
3つのスコアを掛け合わせて、エラーにリスク優先度番号(RPN-risk priority number) を付与する。
チームは運用・開発・ビジネスユーザー・そのほかのステークホルダーで構成し、問題に関する専門知識を持ったクロスファンクショナルなチームでなければならない。さまざまな視点から見ることで、プロセスの中でうまくいかない可能性のある事柄をより幅広く知ることができる。
RPNがかなり上位に位置する場合、評価した3つの軸のうち、どれかを下げることができるかを検討する。深刻度、発生頼度を下げるにはかなり大がかりな開発が必要になるが、検出可能性はもっと簡単な解決策がある。役立ちそうなメトリクスを監視し障害を検出できるようにすることで、ほかの問題よりRPNが低くなる可能性がある。
■ログ集約が必要になる背景には文化的な理由
DevOpsの中心的な考え方には、チームに権限を与え可能な限り多くの情報を共有し民主化するというものがある。ログ集約がないと、ログへのアクセスは運用サポートスタッフに限定されるか、開発者がアクセスしやすい場所にログをコピーする必要が生じ、どちらのチームにとっても非常に大きな負担となる。
またログ集約は、ログの新しいビジネスユースケースを生み出す。プロセスの各機能やステップがどのように動作しているかをログに記録することで、ビジネスの流れを垣間見ることができる。技術チームだけでなくエンジニアリング以外のビジネスユニットにも価値をもたらす。
チーム全体の情報を民主化することは、システムの責任と所有権をめぐる組織の文化的変化につながる。
■ダッシュボードの対象者
最初のステップでダッシュボードの対象者を特定すべき。見る人によって必要なものは異なり、その人の目的を念頭に置いてダッシュボードを構築すると、対象者ごとにまったく異なるダッシュボードができあがる。どのメトリクスを表示するか、どのメトリクスを強調する必要があるか、どういった粒度でデータを表示するかなど、ダッシュボードで何を対象にするかを決めることができる。
■テストピラミッド
ピラミッドの底辺では迅速なフィードバックが可能。階層が上がるにつれてテストはより時間がかかるようになり、対象が広範囲になる。
■SLOの３つのカテゴリ
アラート通知への応答時間のサービスレーベル目標(SLO)は通常3つのカテゴリ（確認までの時間、開始までの時間、解決までの時間）に分けられる。
■慎重にアラートを作成する
文脈を無視してアラートを作成することは危険。一度作成したアラートは削除してはいけないという考えが人々に植え付けられる。
■良いアラート
良いアラートは、行動可能である、タイムリーである、適切に優先順位が付けられている、という3つの性質を持つ。
■手作業の弊害
手作業に費やす時間が多ければ多いほど、プロダクトに付加価値を与える時間は少なくなる。ツールの開発や自動化を行わないことは、今を最適化するために未来の一瞬一瞬を犠牲にしている。手作業は個別にはわずかな無駄でしかないように見えても、とんどん膨らんでいき、全体では非常に多くの無駄となる。最大の無駄は作業に必要以上に時間がかかることではなく、待ちが発生すること。
■ツールや自動化が重要になる4つの領域
ツールや自動化が重要になってくるのは4つの領域。
1つ目は待ち時間。待ち時間は多くの手動プロセスにおいて、時間を無駄にし悪影響を及ぼす。プロセスで必要な受け渡しの回数を減らすことで、待ち時間を解消または削減できる。
2つめは実行時間。コンピュータは反復的なタスクを速く実行するのに優れている。単に手動で実行するよりもそれを自動化するほうが、はるかに興味深く満足感を得られる。
3つめは実行頻度。繰り返し作業はエンジニアの集中力を低下させる。コンテキストスイッチが必要となり、前に作業していたタスクに再度戻る際に貴重な時間を失うことになる。また、人間に依存する場合、タスクの実行頻度が制限される。自動化によって、必要に応じて自由にはるかに高い頻度でタスクを実行できる。
4つめは実行のばらつき。人間が行うことには必ず多少のばらつきがあえう。さまざまな種類のばらつきが、将来的に何かに影響を与える可能性がある。
■コラボレーション
ほかのグループに協力を求める場合、コラボレーションが最も重要。自分たちの解決策を主張するのではなく、どういった問題を解決しようとしているのかに焦点を当て、協力して解決策を導き出す。
■システム運用
システムのオペレーターが安全にサポートできるようにするというプロセスは、エンドユーザーから要件や期待を聞き出す際に行うことと根本的には変わらない。システムを運用する人は、システムに対して異なる視点を持つとはいえエンドユーザーであることには変わりありません。
■タスクの捉え方
タスクの複雑さは、専門家としての観点からではなく、タスクを実行する人の観点から考えるべき。複雑なタスクであったとしても、失敗してしまったときのリスクが低い場合は、そのタスクを怖がらずに引き受ける。
■継続的な学習
DevOpsの中心にあるのは継続的な改善という考え方。漸進的な変化が勝利をもたらす。継続的な改善の原動力となるのは、継続的な学習。新しいテクノロジ・既存のテクノロジ・チームの運営方法・チームのコミュニション方法に加えて、これらがどう相互に関連して、エンジニアリング部門という人間と技術のシステムを形成しているのかを学ぶ。
■最適な学びの場
学びの場として最適なのは、物事がうまくいかなかったとき。インシデントは、システムに対するあなたの理解が現実と一致しているかどうかを確かめる決定的な機会です。体系的に構造化された方法で、システムやチームメンバーから教訓を引き出す必要がある。
■非難のない文化
懲罰と非難の文化では、従業員が真実をあまり話さなくなる。率直さを欠くと、インシデントから学ぶ能力が妨げられると同時に、インシデントに関する事実をわかりづらくする。非難のない文化(blameless culture)では、従業員は懲罰を受けることなく、コラボレーションと学習をより促進する環境を作ることができる。誰もが責任逃れをしようとせず、インシデントの原因となった問題や知識のギャップを解決することに関心が向けられる。
■24時間ルール
自分たちの環境でインシデントが発生した場合、24時間以内にそのインシデントに関するポストモーテムを行うべき。インシデントが発生してからドキュメント化されるまでの時間が長くなると、記憶が薄れ、状況の詳細が失われる。また、失敗の背景にある感情やエネルギーを確実に活用する。
■情報の共有方法
情報をどのように共有するかによって、チームのコミュニケーション方法や、責任と所有権の境界線の引き方が決まります。DevOpsはサイロを壊すことを目的としている。この壁は組織構造の中に存在するだけでなく、心や言葉の中にも存在している。自分のチームで情報がため込まれているかどうかや、保護されているかについて敏感になることで、共感する力を養うことができる。自分自身を振り返ることで、個人としてより良い選択ができるようになり、その選択をチームの文化的DNAに組み込むことができる。DevOpsのマインドセットの中核を成す。
■文化
文化が仕事の流め方の風潮を決める。文化はある行動を許容し、別の行動を要求する。
文化とは、あるグループの人々をほかのグループから区別する、共有された価値観、習慣、信念の集合体として定義される。
■最も簡単なところから始める
DevOpsの力を発揮させるために必要なことは1つだけではない。チームがより緊密に連携し、共通の問題を解決し、共通の目標に向かって働くためには、いくつかの領域でいくつかの変更が必要になる。
自分自身の努力で最も価値を提供できるところから始める。ツールよりもソフトスキルの方がより重要。ソフトスキルを組織に根付かせることで、テクノロジを選択する際に、それを使用するチームメンバーの要望にオープンで誠実な対話をしながら、難しい質問をできるようになる。
Agile Testing Night#22 ~Jam Session vol.1~ に行ってきました
Agile Testing Night#22 ~Jam Session vol.1~ に行ってきました。
イベントの概要
スピードの早いテクノロジーやビジネスの変化に合わせ、ソフトウェア開発のスタイルも刻々と変化してきました。その変化に合わせ発展してきたのがAgileやLeanです。
ところが日本の場合、これらはソフトウェア開発者の視点で語られることが多くソフトウェアテスト・品質視点での議論はまだまだ足りていません。
そこでAgile testingやShift-left testingを中心とした事例の紹介・ディスカッションを行うMeetupを企画しました。
日本のテスト・品質コミュニティを盛り上げるべく、オープンでカジュアルなイベント・コミュニティを目指します！
引用：
イベント参加の背景
- アジャイルにおけるテストがまだまだ分からない。
- 色々なイベントで大平さんの名前を拝見することが多くお話聞いてみたい。
- 来月から開発者としての稼働が決まった今こそテストにも触手を！！
セッション
大平さん体調不良でお休みでした…！！
イビツなスクラムの入口と出口
アジャイル宣言、誰でもやっている！！という反応は、
それぞれが自分たちのコンテキストから文脈を解釈している。
- 顧客満足
顧客=上司や発注担当者？システム利用者のはず。
我々は日頃システム利用者の満足に向き合って開発をできているか。 - 見積り
金額、期間、SP。イコール、根拠に基づいた計算結果。
構成要素を洗い出し判断する必要がある。
物理的なものは不確実性は低いが、ソフトウェアは不確実性が高いので比較が必要。 - スプリントバックログ
未達の理由。時間が足りない。見積りが甘い。
計画より現実が正しい。計画を練るための経験が足りなかった。
経験を積んだうえで見積る必要がある。スパイクで試してから見積もる。 - バックログ
バックログ＝機能一覧？
メリット享受者は１つのユーザー種に限られない。
誰に何の価値を生み出すかを考えて、タスクを細分化する。
小さく区切ってリリースすることで、ステークホルダーの視線がプロダクトに行く。 - 雑談
責任感から少し離れた部分でアイデアを交流できるようにした方が良い。
責任感があるところからは、なかなかアイデアを出しづらい。 - まとめ
新しい単語は最初は自分のコンテキストで理解をするもの。
学習できるのは所属コミュニティーで困らない範囲まで。
困っていないなら、外に出で学習をする。
感想
自分の中のスクラムに対する理解を補強する機会となりました。
見積りのお話しの際に、なんで見積りを時間でやらないのかという質問がありぐるぐる考えました。
結果、【見積りを時間でやる】は【制約の話】になり、【制約の話】は【個々人のスキル】に依存しやすく、やりたいことは個々人のスキルの話ではなく、やりたいことの規模ってどれぐらいなんだろう？という疑問から距離が生まれるからと勝手な理解。
時間で見積もったとして、４時間のチケットを１日に２枚消化できるかって言ったら違うし。
同じテーブルに着席した方とのコミュニケーションも有意義な時間になりました。
自分の知らないコンテキストを知ることは大きな学びに繋がります。
大平さんのお話は別の機会にお聞きしたいです。
おまけ
ビール美味しくいただきました！！
『APIファーストの世界』を読んで ～ APIが持つ可能性とアプリの未来
読書メモ。2025年20冊目。
『APIファーストの世界』を読んでの感想となります。（2025/3/1記載）
本の概要
この「APIファーストの世界」コミック単行本は、APIファーストの世界がどのように、そしてなぜ実現されようとしているのかを描いています。すべてのAPIエンジニア必携の書です。
引用：
API Graphic Novel in Japanese / 「APIファーストの世界」コミック日本語版store.postman.com
動機
・自身のプログラマーとしての黄金時代はスマホアプリから呼ばれるバックエンド開発だった。
・APIには特別な思いがあるし、なんならまだまだ開発したい。
・いろいろなカンファレンスでお世話になっているPostmanさんの物理本をとうとうゲットしてしまった！！
感想
APIという存在の大きな可能性を知りました。
OSSと同じような文脈として扱えるのも興味深い。
プラットフォームチームやコンプリケイテッドサブシステムチームのXaaSとしても機能すると思う。
APIをブロックのように扱うという話は、昨年のServerlessDaysTokyo2024での草薙さんの発表を思い出しました。
いつも思うのですが、このPostmanのキャラクターがかわいくて好きです。
おまけ
Postmanのスマホゲームの存在をはじめて知りました！かわいい！
本日リリースされたスマホゲーム「Postman:API-First Journey」🚀 Postmanが目指すAPIファーストの世界をモチーフにしたゲームです🎮#vscodejp
— Postman Japan (@postman_japan)2023年11月28日
iOS:https://t.co/N9l5iMyHDK
Android:https://t.co/LK2gYPfQItpic.twitter.com/lAzarrHGuo
