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

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

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

島田が翻訳した書籍のいくつかをお読みいただける方にお譲りします

更新: 無事に在庫全てにご応募いただけたため、募集締め切らせていただきます。ご応募ありがとうございました!!


翻訳した書籍の在庫が増刷などで手元に増えてきたので、お読みいただける方にそれぞれお譲りしようと思います。

以下のフォームから応募いただいた方に先着でお送りいたします。特に応募に条件などはありません。

https://forms.gle/kGkQJ7qVGJDdXiYG9

全部の本が捌け次第フォームは閉じます。また、レターパックで送ることになるので、届くのは連休明けなるかと思います。

もし読んでくださる方がいらっしゃいましたら、ご応募お願いします。

上級技術リーダーの役割やあり方に関する翻訳書籍の原稿をレビューいただける方を募集します

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


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

書籍は上級技術リーダーに求められる役割やあり方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です:

  • 自分の役割をよりよく理解し、成長させたいと考えているスタッフエンジニアやプリンシパルエンジニア
  • スタッフエンジニアやプリンシパルエンジニアといった個人貢献者コースでのキャリアアップに関心のあるソフトウェア開発者

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

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

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

https://forms.gle/9FCAQzkqKbcHqeVP9

『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』

翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』(オライリー・ジャパン)が明日(2024年1月24日)発売となります(電子書籍オライリー・ジャパンのサイトでの購入となります)。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』(O'Reilly Media)の全訳となります。

本書は、経験豊かな10名のソフトウェアアーキテクトたちによる、ソフトウェアアーキテクチャメトリクスをテーマとした論集となっています。

著者には、次のような著名なソフトウェアアーキテクトたちが名を連ねています。

本書は、ソフトウェアアーキテクチャの分野におけるメトリクスの考え方、取り組み方、実践に対するヒントが学べる一冊となっています。

本書で取り扱われるトピックには、次のようなものがあります。

  • Four Keys メトリクスの計測と可視化の実践
  • アーキテクチャ適応度関数(architectural fitness functions)の考え方を用いてアーキテクチャが目的を満たしているかを検証する方法やヒント
  • モジュール性成熟度指数(Modularity Maturity Index:MMI)を用いて技術的負債を計測する方法
  • DevOps文化に組織が移行できているかを測るのに役立つメトリクス
  • ビジネス目標と結びついた適切なKPIからソフトウェアアーキテクチャメトリクスを導く方法や実践
  • メトリクスベースのフィードバックループを実践して保守性を保つ方法

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

はじめに 

1章 解き放たれた4つのキーメトリクス
    1.1 定義と計測 
    1.2 メンタルモデルのリファクタリング 
    1.3 記録と算出 
    1.4 表示と理解 
    1.5 議論と理解 
    1.6 オーナーシップと改善 
    1.7 結論 

2章 適応度関数テストピラミッド:アーキテクチャテストとメトリクスのためのアナロジー 
    2.1 適応度関数とメトリクス  
    2.2 適応度関数の区分 
    2.3 テストピラミッド 
    2.4 適応度関数テストピラミッド 
    2.5 適応度関数例の評価 
    2.6 より複雑な適応度関数例の評価 
    2.7 適応度関数とメトリクスを開発する 
    2.8 結論 

3章 進化的アーキテクチャ:テスト容易性とデプロイ可能性でアーキテクチャを導く
    3.1 学習と発見の重要性 
    3.2 持続可能な変化を実現するためのツール 
    3.3 テスト容易性:高品質なシステムを構築する 
    3.4 デプロイ可能性:システムの開発をスケーリングする 
    3.5 結論 

4章 モジュール性成熟度指数でアーキテクチャを改善する 
    4.1 技術的負債 
    4.2 技術的負債の発生 
    4.3 MMIによる評価 
    4.4 モジュール性 
    4.5 階層性 
    4.6 パターン一貫性 
    4.7 MMIを算出する 
    4.8 MMIを決定するためのアーキテクチャレビュー 
    4.9 結論 

5章 プライベートビルドとメトリクス:DevOps移行を乗り越えるためのツール 
    5.1 主要な用語 
    5.2 「オーナーシップシフト」 
    5.3 ローカル環境を再び強化する 
    5.4 プライベートビルド 
    5.5 ケーススタディ:不安定なトランク  
    5.6 ケーススタディ:ブロックされたコンサルタント会社 
    5.7 メトリクス  
    5.8 メトリクスの実践  
    5.9 結論 

6章 組織のスケーリング:ソフトウェアアーキテクチャの中心的役割
    6.1 YourFinFreedom社の挑戦:モノリスを壊す 
    6.2 分散した巨大な泥団子となったマイクロサービス 
    6.3 方向性を模索する 
    6.4 ベストエフォートからインテンショナルエフォートへ 
    6.5 メトリクスによって意図的なソフトウェアアーキテクチャを導く 
    6.6 コミュニケーションを通じた期待マネジメント 
    6.7 アーキテクチャの学びと進化 
    6.8 そしてAnnaはどうなる? 
    6.9 結論 

7章 ソフトウェアアーキテクチャにおける計測の役割 
    7.1 ソフトウェアアーキテクチャに計測を加える 
    7.2 計測のアプローチ 
    7.3 システム品質の計測 
    7.4 始め方 
    7.5 架空のケーススタディ 
    7.6 落とし穴 
    7.7 結論 

8章 メトリクスからエンジニアリングへの進化
    8.1 適応度関数への道 
    8.2 メトリクスからエンジニアリングへ 
    8.3 自動化によってメトリクスを運用する 
    8.4 ケーススタディ:結合 
    8.5 ケーススタディ:ゼロデイセキュリティチェック 
    8.6 ケーススタディ:忠実度を測る適応度関数 
    8.7 結論 

9章 ソフトウェアメトリクスを使用して保守性を確保する 
    9.1 メトリクスを使う理由 
    9.2 なぜメトリクスはもっと広く使用されないのか? 
    9.3 メトリクスを収集するツール 
    9.4 有用なメトリクス 
    9.5 アーキテクチャ適応度関数 
    9.6 メトリクスを長期的に追跡する方法 
    9.7 より良いソフトウェアを作るためのいくつかの黄金律 
    9.8 結論

10章 ゴール・クエスチョン・メトリクスアプローチで未知数を計測する
    10.1 GQMアプローチ
    10.2 ケーススタディ:未来を見通す力を身につけたチーム
    10.3 GQMワークショップを開催する 
    10.4 結論

ソフトウェアアーキテクチャ分野のメトリクスに興味のある方や、上記のトピックや目次を見て興味を惹かれた方などには、ぜひ手に取っていただきたい書籍なのですが、本書には注意いただきたい点もあります。それは、本書は「ソフトウェアアーキテクチャメトリクスというトピックを体系的に取り上げた書籍」ではなく、「ソフトウェアアーキテクチャメトリクスをテーマとしたエッセイ集」であるという点です。

原書の書名(『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』)からはそのことが分かりづらく、残念ながら、原書では読者の期待との間にミスマッチが生じているケースも見受けられます。訳書では副題を「アーキテクチャ品質を改善する10のアドバイス」とすることで、そうした誤解が少なくなるように工夫しています。

本書は、実践者たちのさまざまな経験やアドバイスからヒントを得る書籍として読むと、得られる部分の多い書籍です。ぜひ『ソフトウェアアーキテクトが知るべき97のこと』や『ビューティフルアーキテクチャ (THEORY/IN/PRACTICE)』、『Making Software ―エビデンスが変えるソフトウェア開発』などに連なる書籍として、そして、まだまだ情報源の多くないソフトウェアアーキテクチャ分野でのメトリクスの活用についてインスピレーションを得る書籍として、多くの方に手に取っていただけたらと考えています。

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

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


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

書籍はソフトウェアアーキテクチャの評価指標について学ぶ入門的な内容となっています。具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くださいませ。

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

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

https://forms.gle/4H6RPhPj93vv6vpT6