『ソフトウェアアーキテクトのための意思決定術 リーダーシップ/技術/プロダクトマネジメントの活用』

翻訳を担当した書籍『ソフトウェアアーキテクトのための意思決定術 リーダーシップ/技術/プロダクトマネジメントの活用』(インプレス)が明日2024年12月11日に発売となります。

本書は、2023年12月に出版されたSrinath Perera 著『Software Architecture and Decision-Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』(Addison-Wesley Professional)の全訳となります。

著者は、Apacheオープンソース開発者として20年以上のキャリアを持ち、Apache Axis2Apache Airavata、WSO2(SiddhiChoreo)といったプロダクトのアーキテクチャ策定に携わってきたソフトウェアアーキテクト、Srinath Perera氏です。

本書は、そうした豊富な経験を持つ著者が、ソフトウェアアーキテクチャにかかわる意思決定を効果的に行うために必要な知識や考え方を整理・解説した書籍です。

具体的には、ソフトウェアアーキテクチャにおける意思決定の原則や基本、そしてパフォーマンス、一貫性の保証、セキュリティ、高可用性、スケーラビリティといったソフトウェアアーキテクチャで考えるトピックごとに、知っておくべき前提、原則の適用の仕方、効果的な判断を行うために考えるべきことが学べる内容となっています。

第1章 ソフトウェアリーダーシップ入門
    1.1 判断力が果たす役割 
    1.2 本書の目的 
    1.3 パート1: はじめに 
    1.4 パート2: 最も重要な背景 
    1.5 パート3: システム設計 
    1.6 パート4: すべてをまとめる 
第2章 システム、設計、アーキテクチャを理解する
    2.1 ソフトウェアアーキテクチャとは  
    2.2 システムを設計する方法 
    2.3 5つの質問 
    2.4 7つの原則:包括的なコンセプト 
    2.5 オンライン書店の設計 
    2.6 クラウド向けの設計 
    2.7 まとめ
第3章 システムパフォーマンスを理解するためのモデル
    3.1 計算機システム 
    3.2 パフォーマンスのためのモデル 
    3.3 最適化のテクニック 
    3.4 レイテンシー最適化テクニック 
    3.5 パフォーマンスへの直感的な理解
    3.6 意思決定における考慮事項
    3.7 まとめ
第4章 ユーザーエクスペリエンス(UX)を理解する
    4.1 アーキテクト向けの一般的なUXの考え方 
    4.2 設計のためのUXデザイン 
    4.3 APIのためのUXデザイン 
    4.4 拡張機能のためのUXデザイン 
    4.5 意思決定における考慮事項 
    4.6 まとめ 
第5章 マクロアーキテクチャ:はじめに
    5.1 マクロアーキテクチャの歴史 
    5.2 現代のアーキテクチャ 
    5.3 マクロアーキテクチャのビルディングブロック 
    5.4 意思決定における考慮事項 
    5.5 まとめ 
第6章 マクロアーキテクチャ:コーディネーション
    6.1 アプローチ1:クライアントからフローを駆動する
    6.2 アプローチ2:別のサービスを利用する 
    6.3 アプローチ3:集中型ミドルウェアを使用する 
    6.4 アプローチ4:コレオグラフィを導入する
    6.5 意思決定における考慮事項 
    6.6 まとめ
第7章 マクロアーキテクチャ:状態の一貫性の保持
    7.1 なぜトランザクションなのか 
    7.2 なぜトランザクションを超える必要があるのか 
    7.3 トランザクションを超えていく 
    7.4 ベストプラクティス 
    7.5 意思決定における考慮事項 
    7.6 まとめ 
第8章 マクロアーキテクチャ:セキュリティへの対応
    8.1 ユーザー管理 
    8.2 相互作用のセキュリティ 
    8.3 ストレージ、GDPR、その他の規制 
    8.4 セキュリティ戦略とアドバイス 
    8.5 意思決定における考慮事項 
    8.6 まとめ 
第9章 マクロアーキテクチャ:高可用性とスケーラビリティへの対応
    9.1 高可用性を加える 
    9.2 スケーラビリティを理解する 
    9.3 現代のアーキテクチャのためのスケーリング:基本的なソリューション 
    9.4 スケーリング:取引のツール 
    9.5 スケーラブルなシステムの構築 
    9.6 意思決定における考慮事項
    9.7 まとめ
第10章 マクロアーキテクチャ:マイクロサービスアーキテクチャでの考慮事項
    10.1 決めること1:共有データベースの扱い 
    10.2 決めること2:各サービスのセキュリティ 
    10.3 決めること3:サービス間のコーディネーション 
    10.4 決めること4:依存性地獄の避け方 
    10.5 マイクロサービスの代替としての緩く結合されたリポジトリベースのチーム 
    10.6 意思決定における考慮事項 
    10.7 まとめ 
第11章 サーバーアーキテクチャ
    11.1 サービスの作成 
    11.2 サービスの作成におけるベストプラクティスを理解する 
    11.3 高度なテクニックを理解する 
    11.4 テクニックの実践 
    11.5 意思決定における考慮事項 
    11.6 まとめ 
第12章 安定したシステムの構築
    12.1 システムはなぜ障害を起こすのか。私たちはそれにどう対処できるのか 
    12.2 既知のエラーに対処する方法 
    12.3 一般的なバグ 
    12.4 未知のエラーに対処する方法 
    12.5 グレースフルグラデーション 
    12.6 意思決定における考慮事項 
    12.7 まとめ 
第13章 システムの構築と進化
    13.1 実際にやってみる 
    13.2 設計を伝える 
    13.3 システムを進化させる:ユーザーから学んでシステムを改善していく方法 
    13.4 意思決定における考慮事項 
    13.5 まとめ

本書を書いたモチベーションについて著者は、多くのソフトウェアアーキテクチャが知識不足ではなく判断力不足、判断の誤りによるものであるにも関わらず、ソフトウェアアーキテクチャの判断、意思決定について学ぶための書籍が十分にないことにあると語っています。

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』(オライリージャパン)や『ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには』(オライリージャパン)、『Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions』(O'Reilly Media)など、近いモチベーションで書かれた書籍も出てきてはいるものの、確かにそうした書籍はまだまだ多くありません。

また、ADR(Architecture Decision Record)に取り組む組織も増えてきており、ソフトウェアアーキテクチャの意思決定については、ますます注目されている/重要性が増してきている状況もあります。

そうした中で、ソフトウェアアーキテクチャにかかわる意思決定についての原則や基本、全体像を、A5判304ページという比較的コンパクトな分量で学べる本書は、これからソフトウェアアーキテクチャという領域にチャレンジされる方々や、より良いアーキテクチャ上の判断を模索されている方々にとって、価値のある一冊になると考えます。

前述の類書と合わせて、本書がソフトウェア開発でより良い意思決定をしていくための一助となると幸いです。

技術執行役員の仕事に関する翻訳書籍の原稿をレビューいただける方を募集します

10/2更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます


2025年初めに刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。

書籍は技術執行役員(あるいはCTOやVPoE、技術統括など)としてエンジニアリング組織をリードする立場になった後に遭遇する課題やそれを乗り越えるためのアプローチ、考え方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です:

  • 現在エンジニアリング組織を運営する立場にいる方
  • これからエンジニアリング組織を運営する立場に就く方
  • 技術執行役員の仕事に興味がある方

具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。

募集期間は最大で1週間程度(~10/8)とし、応募状況によってはそれよりも手前で締め切らせていただきます。

興味がある方がいらっしゃいましたら、以下のURLよりぜひご応募をお願いします。

『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』

翻訳を担当した書籍『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』(オライリー・ジャパン)が来週(2024年8月26日)発売となります(電子書籍オライリー・ジャパンのサイトでの販売となります)。本書は、2022年にO'Reilly Mediaより刊行されたTanya Reilly著『The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change』の全訳となります。

本書は、技術専門職としてのキャリア成長に必要な考え方やスキルを、20年を超えるキャリアを持ち、現在も現役で上級技術専門職を務めている著者が、自身の経験をもとに整理・解説した書籍です。

具体的な目次は次のようになっています。

第I部 大局的な思考

1章 では、具体的に君はここで何を?
    1.1 スタッフエンジニアとは一体何なのか?
    1.2 ご高説ごもっとも。で、私の仕事は何?
    1.3 役割を理解する
    1.4 スコープ、形状、重点事項を一致させる
    1.5 まとめ

2章 3つの地図
    2.1 あれ、誰か地図は持ってきた?
    2.2 ロケーターマップ:観点を手にいれる
    2.3 トポグラフィックマップ:地形を学ぶ
    2.4 トレジャーマップ:向かう先は?
    2.5 あなた自身の旅
    2.6 まとめ

3章 全体像を描く
    3.1 シナリオ:SockMatcherには計画が必要です
    3.2 ビジョンとは何か? 戦略とは?
    3.3 働きかけ
    3.4 作成
    3.5 ローンチ
    3.6 ケーススタディ:SockMatcher
    3.7 まとめ

第II部 実行

4章 限りある時間
    4.1 全部やる
    4.2 時間
    4.3 リソース制約
    4.4 プロジェクトを選ぶ
    4.5 まとめ

5章 大規模プロジェクトをリードする
    5.1 プロジェクトのライフサイクル
    5.2 プロジェクトの始まり
    5.3 プロジェクトの推進
    5.4 まとめ

6章 なぜ止まってしまったか?
    6.1 プロジェクトが動いていない。動かすべき?
    6.2 あなたは迷子
    6.3 たどり着いた……どこに?
    6.4 まとめ

第III部 レベルアップ

7章 今はあなたがロールモデル(お気の毒さまながら)
    7.1 良い仕事をするとはどういう意味?
    7.2 有能であること
    7.3 責任ある行動を取ること
    7.4 目的を忘れないこと
    7.5 先を見据えること
    7.6 まとめ

8章 良い影響力を広げる
    8.1 良い影響力
    8.2 アドバイス
    8.3 教育
    8.4 ガードレール
    8.5 機会
    8.6 まとめ

9章 この先は?
    9.1 あなたのキャリア
    9.2 現在の役割
    9.3 ここからの道のり
    9.4 リセットする準備
    9.5 選択が重要
    9.6 まとめ

スタッフエンジニアについて

スタッフエンジニアの「スタッフ(staff)」は、軍事用語における「参謀(staff)」を指します。

参謀 - Wikipedia

参謀(さんぼう、独: Stab、英: staff、仏: État-Major)とは、作戦・用兵などに関して計画・指導にあたる将校 ...(略)... 軍隊において部隊の指揮系統は単一であるために、あらゆる決心は指揮官が単独で行う。しかしながら高級指揮官は軍事作戦を指揮統制するために処理すべき情報や作業が膨大なものとなる。これを組織的に解決するために参謀組織が情報収集、情報処理などの面で高級指揮官を補佐することとなる。そのために指揮官に対する発言権は認められていたとしても、部隊の指揮権は持たない。

こうした役割を求められるスタッフエンジニアという具体的な職も存在する一方、シニアよりも上位の技術専門職(インディビジュアルコントリビューター, IC)には、一定こうした役割が期待されます。そのため、職位としてのスタッフエンジニアと区別して、こうした働きが求められるシニア以上の技術専門職をまとめた総称として「スタッフ+(スタッフプラス)」という呼称も出てきています。

本書は、ソフトウェアエンジニアリングの専門家として、組織やビジネスを現場から独立した形で支えることが期待される、そうした上級技術専門職に求められる考え方やスキルを解説した書籍です。

『スタッフエンジニア』との差分

スタッフエンジニア、スタッフプラスの役割を解説した書籍としては、もう一冊、Will Larsonの『Staff Engineer: Leadership beyond the management track』(邦訳『スタッフエンジニア:マネジメントを超えるリーダーシップ』)が存在します(本書の著者であるTanya Reillyが序文を書いています)。

ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。

Will Larson自身はスタッフエンジニアではなくマネージャーであり、Will Larsonの方の書籍は、実際のスタッフエンジニアへのインタビューなども含め、スタッフエンジニアの仕事を外側から整理した書籍となっています。

一方、本書『スタッフエンジニアの道』の著者であるTanya Reillyは長いキャリアを持つ現役のスタッフエンジニアであり、本書はスタッフエンジニアの仕事を内側から整理した書籍となっています。

両方の書籍に目を通すことで、スタッフエンジニアという役割がより立体的に理解できると考えます。

『エンジニアのためのマネジメントキャリアパス』との関係

本書の序文は『エンジニアのためのマネジメントキャリアパス』(オライリージャパン)のCamille Fournierが執筆しています。

本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。

経緯は序文に詳しいですが、『エンジニアのためのマネジメントキャリアパス』の原書のタイトルは『The Manager's Path』、本書のタイトルは『The Staff Engineer's Path』となっており、両者は姉妹本の関係にあります。

エンジニアリングのトラックに進むのか、マネジメントのトラックに進むのか。それぞれの書籍は、自身の今後のキャリアを考えるヒントになってくれます。今後のキャリアについて考えている/ 考えたいという方は両方に目を通してみると、良いキャリアパスのヒントが得られると考えます。

まとめ

多くの研究や文献が存在するマネジメント職と異なり、技術専門職のキャリアを進める際に参照できる情報はまだまだ多くありません。

日本国内でも、昨年(2023年)にWillの書籍の訳書が出版され、スタッフエンジニアという役割についての理解が少しずつ広まりつつあります。そこに本書も加わることで、国内でも上級技術専門職の仕事や役割への理解、そしてエンジニアリングリーダーシップについての議論がますます深まっていくことと思います。

本書が、エンジニアリングリーダーシップの道を進んでいく方々にとって有益なガイドになることを願っています。

「エブリン……何してる?」

「あなたの戦い方を学んでいる」

映画『Everything Everywhere All at Once』より

『Ruby on Railsパフォーマンスアポクリファ』

翻訳を担当した電子書籍Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。

Ruby on Rails パフォーマンスアポクリファ

本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。

The Ruby on Rails Performance Apocrypha

本書は、Nateがニュースレター「Speedshop Ruby Performance Newsletter」に公開してきた記事を編集してまとめたものです。Nateが注力し続けている Ruby on Rails アプリケーションのパフォーマンスやスケーリングの話題、ソフトウェアパフォーマンスの一般原則、RubyについてのNateの考えなどがまとめられてます。具体的な目次は次のようになっています。

第1章 原則
1.1  私が大切にしていること
1.2  パフォーマンスの科学
1.3  なぜパフォーマンスか? 
1.4  あなたはコンパイラではない
1.5  10%の高速化が本当に意味すること
1.6  Rails アプリケーション向けのベンチマーク
1.7  自分用のAPMを作る
1.8  フレームグラフを読む
1.9  DRM(データベース、Ruby、メモリ) 
1.10 デザイン空間におけるパフォーマンス 
1.11 マイクロサービスとトレンド 
1.12 Minitestについて 
1.13 Rubyに対する企業のサポート
1.14 なぜRubyは遅いのか?
1.15 人気 
1.16 臭い依存関係 
1.17 なぜキャッシュするのか? 
1.18 スタートアップにおけるソフトウェア品質

第2章 フロントエンド
2.1  簡単なフロントエンドの設定変更
2.2  常にCDNを使用する
2.3  ページ容量とフロントエンドの読み込み時間
2.4  遅延読み込みを簡単に
2.5  リソース優先順位付けとは何か
2.6  HTML ON THE WIRE
    
第3章 Ruby
3.1  例外:静かでもタダではない
3.2  スレッドセーフについて
3.3  GVLとは
3.4  GVLを時分割する
3.5  GVLとC
3.6  肥大化
3.7  最低限必要なRails
3.8  誰も使わなかった奇妙な設定
3.9  オブジェクト割り当て
3.10  常に本番用プロファイラを使用する
3.11  ローカル環境で問題を再現する
3.12  ワーカーキラー
3.13  クエリーキャッシュとは?
3.14  NewRelicのRubyVMタブを読む
3.15 テストセットアップ

第4章 スケール
4.1  消費時間とは
4.2  リクエストキュー時間
4.3  アムダールの法則
4.4  スレッド数
4.5  CPU律速かIO律速か?
4.6  スワップとは何か
4.7  データベースプール
4.8  シングルスレッド性能
4.9  リードレプリカ
4.10  なぜLambdaなのか?
4.11  Performance-Mは決して使わない
4.12  日次での再起動

本書はニュースレターに書かれてきた記事が元になっているため、Railsのパフォーマンスに関して体系的にまとめた書籍というよりも、パフォーマンスをテーマとした技術エッセイ集的側面の強い一冊に仕上がっています。しかしながら、そうした技術エッセイ集的な読み心地には、なんとも言えない「良さ」を感じます。

かつては、『ハッカーと画家 コンピュータ時代の創造者たち』(オーム社)や『BEST SOFTWARE WRITING』(翔泳社)、『プログラマが知るべき97のこと』(オライリージャパン)をはじめとする『〜が知るべき97のこと』シリーズなど、ソフトウェア技術者によるエッセイ集が多く出版されていた時期があり、技術書としても人気を博していました。

Rubyに関わりが深い著者による同系統の書籍として、『達人プログラマー ―熟達に向けたあなたの旅― 第2版』(オーム社)や『情熱プログラマー ソフトウェア開発者の幸せな生き方』(オーム社)などを思い浮かべる方も多いのではないでしょうか。こういったエッセイ集から私たちが学んでいたのは、単なる新しい技術や知識というよりも、ソフトウェア技術者としての哲学や心構え、考え方でした。

しかし、ブログブームの終焉や出版業界の状況なども相まってか、昨今はこうした書籍を商業出版で見かける機会は減ってしまいました。

そういった状況の中で本書を読み、訳者が久々に感じたのは、上記のような書籍を読んでいたときに感じていた「良さ」に似た味わいでした。

本書は、Web(特にRailsによるWebアプリケーションによるWebアプリケーション)のパフォーマンスについての書籍ですが、それと同時に、Nateというソフトウェア技術者の考え方や哲学に触れることで、私たち自身のソフトウェア技術者としての考え方を深めたり、普段の開発への取り組み方を見つめ直したりするきっかけになる書籍でもあります。

本書を通じ、一人でも多くの方に、訳者が感じた原書の味わいが届けられればと願っています。

Ruby on Rails パフォーマンスアポクリファ


Nateは、現在は日本に暮らしており、日本語での情報発信も積極的に行なっています。 本書を気に入られた方、気になった方は、ぜひ彼の活動に触れてみてください。

ソフトウェアアーキテクチャに関する翻訳書籍の原稿をレビューいただける方を募集します

7/11更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます


2024年冬頃に刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。

翻訳している書籍は『Software Architecture and Decision Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』になります。

書籍紹介より

リーダーシップの知識を活用し、より良いソフトウェアアーキテクチャの決定を下そう。深く考えた上で、ゆっくりと実装しよう。

ソフトウェアシステム(ソフトウェアアーキテクチャ)を構築する私たちのゴールは、品質基準を満たし、長期間または定められた期間、最高の投資収益率(ROI)をもたらすシステムを構築することだ。

優れたプロダクトは、テクノロジー、リーダーシップ、プロダクトマネジメント(UXを含む)の組み合わせから生まれる。リーダーシップとは、不確実性を管理し、適切な決定を下すことを指す。優れたプロダクトを作るには、リーダーシップ、プロダクトマネジメントの知識を組み合わせて、適切な決定を下していく必要がある。技術的なミスの多くは、これら3つに関する知識と判断力のギャップから生じる。

本書は、ソフトウェアアーキテクトが深く理解しなければならない原則と概念を解説するものだ。そして不確実性を管理するために、それらの原則を活用する方法についても説明する。本書で取り上げられる質問と原則は、ソフトウェアアーキテクチャを構築する際の不確実性を管理し、意思決定していくためのフレームワークを提供する。本書は、構築するシステムに関して総合的な判断を下すソフトウェア業界のすべての技術リーダー、そしてそうした技術を学ぶ将来のリーダーのための書籍だ。

募集期間は最大で1週間程度(~7/17)としますが、応募状況によっては早めに締め切らせていただきますので何卒ご了承ください。

興味を持っていただける方がいらっしゃいましたら、以下のURLよりぜひ応募をいただけますと幸いです。

https://forms.gle/YXcoRxQkcVQuRSYx5

えにしテック15周年記念カンファレンスのこと

2024年6月29日(土)にHOKKAIDO x Station01をお借りしてえにしテック15周年記念カンファレンスを開催しました。

当日はたくさんの方々にお越しいただき、おかげさまで、とても特別な15周年を迎えることができました。参加いただいた皆さま、あたたかいメッセージをいただいた皆さま、登壇いただいた高橋さん角谷さん大場さん平鍋さん、美味しいコーヒーを出していただいた猫廼舎さん、運営をつつがなく取り仕切ってくれたメンバーのみんなに感謝します。ありがとうございました。

正直、まだあの場がなんだったのかをきちんと飲み込みきれておらず、きちんとした総括はできない感じなのですが、何かを書いておかないと先に進めない気がしているので、一旦カンファレンスのことを書き残しておこうと思います。


15周年の節目、何をしたいかと考えて出てきたのは、一番に初心に返って勉強会がしたいなという気持ちでした。

なぜ会社の初心で勉強会かというと、株式会社えにしテックの出自は、Ruby札幌 というコミュニティにあるからです。

Ruby札幌は、2006年に島田が発起人となって始まったコミュニティです。Ruby札幌では、運営チーム(@darashi@tmaeda@noplans@mrkn)やそこに集まってきてくれた人たちと一緒に色んなことにチャレンジしてきましたが、その始まりは島田がRubyを勉強したくて始めた Ruby勉強会@札幌という勉強会でした。

その初心に立ち返って、今島田が話を聞きたい方々を呼んで、島田が一番前でその人たちの話を聞き、そこから何かを受け取るという場・時間を、今の会社のみんなと一緒に経験したい。それが最初に立てたこの会のコンセプトでした。

そして、講演は島田やえにしテックにとって繋がりのとても深い高橋さん・角谷さん・大場さん・平鍋さんの4名にお願いしました。

それから猫廼舎さんも。日本Ruby会議2007からの付き合いであるogijunさんも、ぼくらにとってはカンファレンスに欠かせない特別な存在で。猫廼舎さんにコーヒーを提供してもらうカンファレンスをする(しかも札幌で!)ということも、この会の大事なコンセプトの1つでした。


会期中のことは、まだまだ全然冷静に振り返れないので、感情の断片を残しておきます。

前日のこと

この時点で、何だか特別な感じがしていたんだなあ。

ハッシュタグのこと

このメンションをもらった途端、何だかX(ソーシャルメディア)がTwitterソーシャルネットワーク)に戻ったような印象を覚えました。このままこの流れの中でみんなで決めるのが「正しい」と感じて、そのように振る舞いました。ここでハッシュタグが定まったのもとても良かったし、このやりとり自体もイベントのテイストに作用するとても大事な場面だったと感じています。

高橋さん

speakerdeck.com

ここから先考えるべき問いをもらうキーノート。The One Person Framework、概念圧縮、消極的自由と積極的自由。

角谷さん

speakerdeck.com

主催したカンファレンスで角谷さんがこんなに生き生きと講演してくださったことがまず何よりも嬉しく、師匠の高座を横で学ばせてもらっていました。そしてちりとてちん...

あらためて、ちりとてちんのオープニングから始まったカンファレンスのハイライトが、コミュニティへの「ふるさと(概念) 」の伝搬というのは、なんだかとてもすごいことが起きたんじゃないか……という気がしている。夢……だったのかもしれない #enishitech

Koji Shimada (@snoozer05.bsky.social) 2024-07-04T08:55:23.283Z
bsky.app

大場さん

speakerdeck.com

大場さん。前日に思い返していたのと同じで、今回もまた、大場さんの背中にはとても励まされたし、新しい人たちも同じように励まされていて、やっぱり大場さんはかっこいいなあと感じていました。

平鍋さん

全体をライブで総括していく平鍋さんは、やっぱりすごくて、かっこいい。これもまた師匠の高座を学ばせてもらっている感覚が強くありました。もっと時間をゆっくりとって、平鍋さんの話もじっくりと聴きたかったけれど、それはまたこの先のどこかで。

参考資料

ぼく側の視点から見た平鍋さんとの歴史:

メッセージ

これまでご縁のあった方々のメッセージ、当日かけてくださった言葉、感想。どれも大切な宝物になっています。本当にありがとうございます。

新しい人たちにつながっていく

note.com

そして、今回は新しい人たちも覗きに来てくれていて、それもとても嬉しい出来事でした。そうした新しい人たちは、ぼくからはとても素敵に映っていて。あの空間を一緒に過ごしてもらえて良かったなあと感じています。

その土地の豊穣さを祝う。自分たち自身を祝う

「会社」がこんなふうに祝われるというのは何だろう...というのがうまく解釈できないでいたのですが、「えにしテックとはRubyコミュニティという土地に生えてきた芽であり、その芽を祝うというのはRubyコミュニティ(土地)そのものを祝うことであり、Rubyコミュニティとはそこに集う人たち自身であるなら、それは自分たち自身を祝う場であった...みんなでみんなを祝福する場だったのかもしれない」とみなさんの感想を読んでいて感じるようになってきています。

総括できない総括

本当に特別な1日となりました。改めて、カンファレンスにご参加いただいた方、そして、これまでえにしテックに関わりのあったすべての方々に感謝します。ありがとうございました。

野辺へ出てまいりますと、春先のことで、空にはヒバリがピーチクパーチクピーチクパーチクさえずって、下にはレンゲたんぽぽの花盛り。かげろうがこう萌え立ちまして、遠山にはふあ〜っと霞の帯をひいたよう。麦が青々と伸びて菜種の花が彩っていようかという本陽気、やかましゅう言うてやってまいります、その道中の陽気なこと! 〜「ちりとてちん」より

良いコードってどんなコードですか?という質問を受けたら何と答えるか

技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。

最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期(それぞれRubyの会社で働いている)と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。

この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。


とても大事な疑問を見つけられたんだなあと思います。

「良さとは何か」ということに向き合う必要のある質問だと思って考えています。 ものの良さ=質というものには、大きく

  • 主観としての良さ: 自分として良いと感じる
  • 客観としての良さ: 誰かや何かの基準に照らして良いと感じる

の2つが存在しますよね。 たとえば、映画(音楽でもアニメでも小説でも、なんでも自分のイメージしやすいものに置き換えてもらって大丈夫です)を例にとると、次のような感じです。

  • 主観としての良さ: この映画すごく面白い!自分にとって特別な映画だ!
  • 客観としての良さ: XX賞受賞、動員数XX突破、〜〜が絶賛

ここで、難しいのは、この「主観としての良さ」と「客観としての良さ」というのは、常に一致するわけではないというところにあります。

「自分は良いと思っても、世間では評価されていない」「世間ではとても評判だけど、自分にはイマイチ良さがわからない」

そして、世間の中でも、あるところでは絶賛されているけど、あるところでは問題視されている、なんていう風に評価がぶれていることも多々あります。

こうしたギャップが生じるの起きるのは、「良さ」は、その良さを測るシチュエーション(何を評価する場面なのか)と誰が評価するのか変わってきてしまうからだと考えます。

さらに、自分自身の評価も、対象に関する知識が増えたり経験によって変わっていったりします(例:映画をたくさん見ることで、映画の見方がわかってくる)。

今回、Sさんが感じた「よくわかんなくなった」は、この辺りがこんがらがってしまったんじゃないかなと想像します。

スクール時代の同期の話や今の仕事で書いているときに求められるコードの質は「客観としての良さ」についてのことで、「1年後にいいコードが書ける、上手に書ける」というのは「主観としての良さ」についてのことに当てはまると思ったからです。

そうだとして、どうしたらいいの?という話なんですが、客観の良さについてはシチュエーションや相手によって変わるのは仕方なく、良さを評価される立場にいる場合には、そのシチュエーションで求められる品質を満たすコードを書いていくしかない、ということになるかなと思います。

求められているのが自分がクリアするのが厳しい品質である場合には、主観の良さを鍛える良い機会になるでしょうし、逆に主観の良さを超えないものであった場合には、その仕事の制約の中で自分が満足できるコードにどれだけ到達できるかがポイントになってくると考えます(仕事でコードを書く場合には、期限という大きな制約があるので、完全に自分として納得のいかないコードの場合でも、要求される品質は少なくとも満たす、というところで先に進む必要が出てくるという感じです)。

いずれにしても、Sさんが立てた「1年後にいいコードが書ける、上手に書けること」に進むためのアプローチとしては、許された制約の中で、自分として精一杯のコードを書き続ける、そしてその結果がどんなコードだったか(満足いくものになっているか、何かたどり着けなかった部分があるか、制約がなかったらどうやれるか)をちゃんとふりかえっておく、ということになるんじゃないかなと思います。可能であれば、コードや設計についての勉強も続けられるとより良いです。

上記を継続していく過程で、間違いなく、少しずつ「こういったコードが良いコードだ」というのが自分の中に積み重なっていくはずです。