SCRUM BOOT CAMP THE BOOK

初めてスクラムに取り組む方には特におすすめの良書でした！！

スクラムはスクラムガイドがあるもののより具体的な行動は自組織の状況に合わせて考えていく必要があります。本書はスクラムガイドの丁寧な説明と共にある架空のプロジェクトを題材により具体的な行動を示してくれます。

もちろん、組織の状況により変わるので正解があるものではありません。しかし、著者が長くスクラムに向き合う中でうまくいっている状況をまとめたものなので参考にはなるはずです。

一つのお手本として色々と学びや気づきがあります。自組織ならこうなるだろうな〜と考えながら読むことでよりスクラムに対する理解を深めれるでしょう。

プロダクトのSREチームにおけるスクラムについて（おまけ）

SREチームでスクラムを初めて4ヶ月ほど経ちました。メンバの中には開発チームでのスクラム経験者もいるので一定のプラクティスは実践でき始めています。

ただ、全てを忠実にやれているわけではないというのが現実です。なんちゃってスクラムと呼ばれる状況なのかもしれません。

結果としては導入して良かったと感じるところが多いです。特に透明性がもたらす属人化排除や、メンバを孤独にしない環境作りはこれまでのSREチームの課題を解決するものだったように思います。

また開発チームはスクラムを導入しているので会話の中で出てくる用語の解像度が上がったなど副次的な効果もあります。

一方で、SREチームのスクラムはかなり難しいなあと感じます。創意工夫の余地があるのは前提として難しさを言語化してみます。

やはり一番の歪みはプロダクトオーナーがいないことなのかもな〜と仮説を立てています。

そもそも当プロダクトにはプロダクトオーナーという立ち位置はありません。プロダクトマネージャと各開発チームにいるプロダクトリードが似た責務を持ちます。

当SREチームが実施するような「開発者チームが信頼性を向上するための仕組み作り」をプロダクトマネージャーが扱うのは現実的ではなさそうなので、プロダクトマネージャーは現状SREチームのバックログには関わっていません。

そうなると結局プロダクトオーナーの責務はメンバが共有して持つ形になります。スクラムチームから⽣み出されるプロダクトの価値を最⼤化する責任をメンバで共有している状況です。

ちなみに、チームのプロダクトリードがバックログアイテムの作成は実施しています。なのでスクラムのイベントは実施できています。

また、具体的な機能が必ずできるわけではないのでスプリントレビューも実施してなかったりします。

そうなると検査が機能しなくなっていきます。元々SREチームは差し込みタスクが多いというのもあり、各インクリメントもなあなあになってくるところもあります。

とはいえスクラムをやることが目的では無いですし、プロダクトに対して価値を生み出せている自信はあるのでヤバすぎる状況では無いのかな〜と思ったりはしています。

一方でもう少し価値を最大化する方法があったりしないかな〜とは思ったりするので、今後も少しづつ向き合えたらと思います。

上記のような課題感を持てるのも当書籍のおかげです。基礎的な考えを学ぶのは大切ですね。

SREチームのメンバになって1年経過した

転職して今月で１年が経ちました。あんどぅさんのふりかえり記事を読んでこういうの大切だよな〜と思い自分も個人的な振り返りを書いてみることにしました。

note.com

筆者の略歴

• 2017/04 SIerでインフラを主軸としてモダンな技術の活用促進・技術支援
• 2022/08 Sansan株式会社のBill OneプロダクトのSREチームに参画

SREチームの業務

私はプロダクトのSREに所属し、Sansan株式会社の提供するインボイス管理サービスBill Oneの信頼性向上を目指しています。SREチームだけがBill Oneの信頼性を向上していく組織だとスケールしないので各開発チームも信頼性に向き合います。SREチームでは各開発チームが信頼性の向上をより効率的に行えるようにする仕組みや文化作りに焦点を当てて活動をしています。詳細は以下の記事もご覧ください。

buildersbox.corp-sansan.com

それでは私がやってきたことを振り返っていきたいと思います。

Site Reliability Engineerとしてやったこと

主に以下の活動をしてきました。

- SREチームのミッション定義
- 負荷試験を用いた性能問題の解消
- オブザーバビリティの向上
- 各サービスでSLI/SLOを導入
- 採用活動

私はSRE NEXT 2022 Topotal TakamuraさんのKeynoteの「さまざまな形があるSREが組織で活動をしていく上でMission/Vision/Values（MVV）を定義することが大切」という話にとても共感していました。そのため入社後落ち着いたあたりでMVVを作ってみたいと提案し、ミッション定義などを推進していきました。詳細については以下スライドをご覧いただければと思います。

また利用者が増えていく中で高負荷時に性能問題も発生しました。そこで負荷試験による原因分析も実施しました。これは、、、マジで辛かったですww 先の見えないマラソンを全力疾走し続ける感覚でした。最終的にDBのログ量が多くなりすぎたことが原因だと判明し、改善することができました。この問題の難しいところはGCPの提供するメトリクスやログなどから我々ユーザ側では原因を特定できないことです。詳細については以下スライドをご覧ください。

性能問題に向き合う中で組織のオブザーバビリティに課題があると感じました。特にトレースの活用余地が多くあったためApplication performance management(APM)製品の導入により課題を解決していくことになりました。ただ、私は後述するBill Oneビジネスカードの案件に参画することになり製品選定は他のメンバが主導しました。そのタイミングでオブザーバビリティ・エンジニアリングという神本に出会えたのも本当に良かったです。選定する中でオブザーバビリティの理想を持ち、それが実現できそうかという観点で皆んなで評価できたのは良かったと思います。

APMを導入しても課題はまだたくさんありますが形になってきた状況です。この話についてはSRE NEXT 2023で紹介予定です！！SRE NEXTは自分の憧れのイベントで、「いつか出られるように頑張るぞ〜」と思って活動をしてきました。感慨深いです。

いやったああああああ！！「勘に頼らず原因を見つけるためのオブザーバビリティ 」がSRE NEXT 2023に採択されましたああああ！！皆様ありがとうございます！！#srenext は転職前に色々考えを整理するのに大変お世話になったので、今回自分も少し貢献できるのは本当に嬉しいです！！

— じょーし (@paper2parasol) 2023年8月9日

インフラが得意なエンジニアとしてやったこと

あえて、Site Reliability Engineerとは別に書きますが以下のような活動をしてきました。

- Bill Oneビジネスカードのインフラ設計・構築
- IaC推進チームの立ち上げと推進
- 新規サービスなどでのインフラ関連の相談対応

Bill Oneビジネスカードは他のマイクロサービスと要件が大きく異なることもあり私や他のメンバがスポットで案件に参画しました。めっちゃ大変でしたが自身が設計・構築したシステムがビジネスになっているのはこの上ない喜びでした。Bill Oneの事業成長を目指してSREの活動をしてきてはいますが、指標としては見えづらい部分もあります。自身が根幹を担ったサービスが具体的な売上に繋がっているのが見えるのはとても嬉しく、エンジニア冥利につきる案件でした。

他にもメイン業務以外での活動としてIaC推進チームの立ち上げもしました。組織の課題解決をしたいメンバが任意で集まって、ワイワイしながら改善していけるのが楽しくて仕方ないです。Bill Oneの大好きな文化の一つです。詳しくは他の立ち上げメンバが書いた以下ブログをご覧ください。

buildersbox.corp-sansan.com

見習いバックエンドエンジニアとしてやったこと

前職からインフラ周りが主軸過ぎることに危機感を感じていました。現職も自身の強みを活かすとアプリケーションを書く機会が少なくなるためプライベートで勉強して、色々な工夫をしてボールを取ったりしています。多くはないですが具体的には以下のような部分でコードを書いてBill Oneに貢献できました。見習いバックエンドエンジニアとしての実績は解除できたのではないかと思い込んでいますww

- Go
  - Bill Oneビジネスカードの根幹サービスを師匠と一緒に実装
  - エラー運用サービスの機能追加
  - JavaScriptのCloud Functionsを他のメンバと一緒にリプレイス
  - OpenTelemetryで計装をしたサンプルアプリケーションの作成
- Kotlin、Ktor
  - 特定データの削除バッチAPIの実装

組織のプレゼンス向上施策

以下のように組織のプレゼンス向上にも積極的に関われました。

- 登壇
- 自社テックブログでの連載企画

登壇数は2回と多くはないですが初登壇に挑戦できたので自分的にはよくやったなという感想です。GCPでの登壇が次の大きなイベントのお誘いに繋がったり、経験が活きてSRE NEXTのプロポーザルも採択されたりと次に繋がっている感もあったりします。

また開発組織のブログリレーも企画しました。「Sansan Tech Blogを7本以上執筆する」という目標を157%で達成できました。まあまあ広まった記事はあったのでこちらもプレゼンス向上には一定効果があったと思います。何より皆んなで祭りごととしてワイワイ記事を書けたのが楽しかったです。

buildersbox.corp-sansan.com

メンバの成長

私の組織はフラットで皆んながリーダーシップを持つのが前提です。テクニカルリードもやっていますしリーダーシップも発揮していますが、リーダーではないです。それでも他のメンバの成長をサポートするのも大切な仕事です。例えば以下のようなこともやっています。

- メンバに挑戦の機会を積極的に提案する
- パニックゾーンにならないかはめっちゃ聞く
- 全力でサポートする

これからどうするか

プロダクトのSREなのでメインではBill Oneの信頼性を向上する活動を続けると思います。各チームが信頼性を向上できるより良い仕組みなどを作っていきたいです。一方である程度落ち着いてきたら大きな課題をSREチームで直接解決していき信頼性を向上することもやっていきたいです。継続してバックエンドエンジニアとしてのスキルも少しづつ磨いていきたいです。

また関わる範囲も徐々に広げていけると良いなと思います。最近だと営業から相談を受ける接点もできています。そのようにBill One事業を推進する様々なメンバと関わってより組織を俯瞰した良い施策を検討していけると良いなと思います。

まとめ

結構色々やってこれたなと思っています。そして、本当に良い組織に転職できたなと思います。日々自身の成長を感じており、転職の目的は大きく達成できています。毎日めちゃくちゃ楽しいです。当然辛いこともありますが成長痛だと思っています。今後もBill Oneの事業を成長させるべく、頑張っていきたいと思いまっす！！

スタッフエンジニア マネジメントを超えるリーダーシップ

中級から上級エンジニアが技術職のキャリアパスを歩んでいく上での方向性を検討したり、上級より上のエンジニアが自身の役割を模索するのに役立つ１冊だと思います。 第1部では上級エンジニアより上のスタッフエンジニアの役割とあり方を解説しています。第2部からは実際のスタッフエンジニアのインタビューが18人分記載されており、スタッフエンジニアの多様な形を理解できます。 スタッフエンジニアがどのようなことをするのかなど、具体的なイメージも湧くので第2部はとてもお勧めです！！

上級エンジニアより上とあるように、この本に書かれている内容は非常にレベルが高いと感じます。私のレベルが低いだけかもしれませんが1部の内容を読んでもスタッフエンジニアが何かを説明できる自信は持てませんでした。。。スタッフエンジニアを網羅的ではないという前提で４つのパターンに分けて分類もしています。テックリード・アーキテクト・ソルバー・右腕がその4つです。非常に興味深い内容で面白かったのですが、スタッフエンジニアが何かと聞かれるとなんとなく輪郭は掴めたけど、、、うまく説明はできないという感じでした。。。

一方で第2部は大変良かったです。スタッフエンジニアの具体的で多様な仕事内容を知れて、自身がスタッフエンジニアを目指すとしたら何が足りないかを考えることができました。一緒に各個人の信念なども記述されており大変刺激になりました。一番印象的だったのは

スタッフエンジニアになるには、今の自分よりも多くのことを知り、実行する必要があります。つねに今の限界を広げる努力をすることが大切で、自分にとって難しすぎるかも、と思える仕事を恐れてはなりません。

という言葉です。まぁ「挑戦しろよ！！」という一般論かもしれませんがスタッフエンジニア級の人が言っているとなんか響くものがあります。

雑感ですがシニアより上のレベルのエンジニアの共通項なんてそんな綺麗にまとめられないのかなとも思いました。まとめたとしても「組織において大きな良いインパクトを出し続ける」くらいの味気ないものになってしまうのかもしれません。それを試みたのが当書籍かもしれませんが、私は結果的に説明できるほど理解はできていません。現状スタッフエンジニアはグレードの定義くらいの認識で留まってしまっています。。。書籍全体を通して、何となく輪郭を掴めただけでも進歩なのかもしれません。少なくとも第2部に関しては自身の考えや行動に影響する内容だったので非常に良かったです。

エンジニアリング組織論への招待

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

概要

「不確実性に向き合う」という一貫したテーマで経済学、心理学、哲学などの様々な成果を結びつけ、エンジニアリング問題の解決方法を体系的に説明しています。組織論における近年良いとされるプラクティスが網羅的かつ体系的にまとめられているので大変おすすめです。また物事の本質を綺麗に言語化している箇所が多く、大変感動しました。

こちらの書籍は社内の読書会で読みました。私は特にメンタリング周りの知識が少なかったので大変勉強になりました。また原理原則として様々な問題の根幹には「不確実性」があるという抽象的な捉え方を持てたことで日常の思考過程にも変化がありました。非常に気づきを多く得られる一冊でした。

一方で有名な内容が多いようなので博識な人には発見が少ないのかもしれません。また、博識な同僚は「解釈が誤っていたり、根拠として提示する割には出典が明示されていない所が気になってしまい、信頼して読めない」と言っていました。似たような口コミもありますね。そのため、知識としては一部疑った方が良い内容があるのかもしれません。特に行動指針や考え方などの気づきを得ることを意識すると良さそうです。私は自身を変える気づきが多かったので総合的にはこの１冊をおすすめします！！

次にメンタリングに関連する内容を本書の引用なども交えて紹介します。

メンタリングに関する内容の一部

自分から考えて動いた結果、評価されたとか、周囲からの尊敬を集めたとか、そういったポジティブな結果を手に入れた人は、正のフィードバックループサイクルの中に「自律的に動くことは、楽しい」といった回路が組み込まれることになります。このような感覚を「自己効力感（self-efficancy）」と言います。メンタリングは、自立型人材を作るために、信頼関係の上に期待値を調整して、適切に自己効力感を持てるようなフィードバックループを作り出していきます。

自己効力感大切ですね。自身も「自律的に動くことは楽しい」が染み付いていく過程にこのループがあった気がしています。組織全体でこういうループを作り上げていけると良いんだろうな〜と思いました。

また、メンティが効率的に成長できるためのメンターとメンティの関係性における条件として以下が紹介されていました。

• 謙虚：お互いに弱さを見せられる
• 敬意：お互いに敬意を持っている
• 信頼：お互いにメンティ（自身）の成長期待を持っている

特に前職の上司との関係でこれらを満たしていた気がします。その中で中堅として成長できた感覚があるため、重要なことだと実感しています。

他にも「悩んでいる」と言うのは「次にすべき行動」がはっきりしていないという考え方も非常に良いなと思いました。そのため悩みを解消するためには以下のいずれか、または全てを解消し、次の行動が明確になるようにサポートすることが重要になります。

• 「選択肢」が不明確
• 「比較軸」が不明確
• 「評価方法」が不明確

この簡易的なフレームワークでメンティの結構使えそうという感覚です。

まとめ

組織論のプラクティスが網羅的かつ体系的にまとめられていて大変良かったです。多くの気づきを得ることができました。是非読んでみてください！！

エンジニアリングマネージャーのしごと ー チームが必要とするマネージャーになる方法

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

エンジニアリングマネージャー（以降EM）が必要とする実践的な内容が多く記載されています。ネットの情報は断片的なので体系的に説明されている本書はこれからEMを始める方には特におすすめです。自組織のEM陣と一緒に輪読会を実施しましたが、多くのところで共感していました。なので本当に必要な内容が詰まっているのは確かだと思います。また、今までの経験や直近の課題感なども踏まえ色々と気づきを得ているようでした。

私は特にEMになるつもりも予定もなかったです。主に以下のことを考えていました。

• メンタリングや採用などのEMの技術は自身のテックリードのキャリアとしても役立つ
• EMの仕事を理解することで互いにより効果的に価値を生み出せる関係を築きたい

実際に書籍を読んで期待は満たされました。またEMとの関わりに関して改善提案もできました。当時のSREチームは歴史的な経緯から専任のEMがいませんでした。当書籍を読んだ上でEMに対して期待して良いことや、他のチームではそれが実現されていそうなことを感じたので相談してみたところ、専任のEMをつけてくれました。

より詳細な内容を紹介していきます。当書籍はビジネス論やリーダーシップ論ではなく実践的な内容の記載がされています。具体的な内容も多くとてもイメージしやすかったです。例えば1on1についてもマネージャとしては何をすべきかはわからないでしょう。4章は丸々1on1について記載されており、実施頻度の考え方から1on1での準備、1on1中のメモの仕方などとても細かく指南があります。

その他の内容もいくつかピックアップしてみます。

マネジメントをする立場になることで、あなたの言葉には権威が伴うことを自覚する

EMになった際の重要な差分ですね。今までとは異なる振る舞いをしないと効果的に動けないということは意識しなければいけません。

マネージャーのアウトプット ＝ あなたのチームのアウトプット ＋ あなたが影響を与えた他のチームのアウトプット

この考えは当プロダクトのEM陣がとても共感していました。プレイヤーとして自身のアプトプットにだけフォーカスするとEMとしてはうまく動けません。またつい自身のアウトプットにフォーカスしてしまい、最初苦しむそうですww EMとしての価値を示す重要な式だと思いました。

また、私はこれはSREチームなどの横断的な組織にも活用できる式ではないかと考えています。自チームでは開発者が信頼性向上をできる仕組み作りをしているため、自らのアウトプットのみが成果ではありません。チームとしてのアウトプットを主張する際にも、この式は活用できそうだと感じました。この式をEM陣と共通認識として持てたのは良かったことかもしれません。

このように当書籍ではEMが必要とする実践的な内容が丁寧に説明されています。これからEMになる人には特にオススメですし、EMで試行錯誤している人も基礎として再整理することで色々と気づきを得られる書籍だと思います。

アジャイルサムライ

アジャイルサムライ――達人開発者への道

言わずと知れたアジャイル開発の王道書籍です。以前から知ってはいましたが優先度が上がらずなかなか読めていませんでした、、、。 私の所属するSREチームでスクラムを導入する話が挙がってきたので読んでみました。

アジャイル開発の本質や実践的なノウハウを網羅しており、初心者に役立つ内容が盛りだくさんでした。絶対の正解がない領域なので雰囲気でアジャイルをやっている経験者にも役立つと思います。アジャイル開発に関心がある方や、実践を考えている方にはぜひお勧めしたい一冊です。

それでは書籍の中で特に良かった点をご紹介していきます。

アジャイル開発の本質を分かりやすく教えてくれる内容が多くありました。まず、価値ある成果を毎週届けることの重要性が丁寧に説明されており、アジャイル開発の根幹を理解する上で非常に役立ちました。また、アジャイル開発を進めるためのコツが書かれているので、実践的なノウハウを学ぶこともできます。

荒ぶる四天王（品質、予算、時間、スコープ）を考慮して、プロジェクト推進において何を優先し、何を諦めるかを明確にすることが重要であることを説明しています。アジャイル開発に限らずこの考え方はとても重要だと思っています。QCD（「Quality（品質）」「Cost（コスト）」「Delivery（納期）」）などで馴染みのある概念ではありますが、「荒ぶる四天王」などの表現やイラストでユーモアを交えて説明をしているところもこの書籍の面白いところです。

アジャイルな計画作りについても、具体的な説明が多く自身で実践するイメージがしやすかったです。見積もりに関しては、正確ではない概算見積もりであることを前提に、見積もらないよりかはうまく回るという考え方が示されており、共感できる点が多かったです。またそれを踏まえた期待値コントロールの話など、プロジェクトとして重要なトピックを説明しています。

エンジニアリングプラクティスの実践がアジャイルな開発プロセスを成功させる上で重要であることが説明されているのも良かったです。ユニットテスト、リファクタリング、テスト駆動開発（TDD）、継続的インテグレーションといったプラクティスについて簡潔に説明した上でアジャイル開発でなぜそれらが重要なのかを丁寧に説明しています。

アジャイル開発に関心がある方や、実践を考えている方にはぜひお勧めしたい一冊です。

実用Go言語

実用 Go言語 ―システム開発の現場で知っておきたいアドバイス

当書籍ではGoを開発業務で使っていくための基礎的な内容が丁寧に説明されています。Goの標準ライブラリだけではなく便利な外部ライブラリも紹介しつつ、クラウド環境でのGoアプリケーション開発で役立つ実用的な内容を網羅的に学べます。他言語の経験者でも「Goらしく」書けるようになることを重視しており、サードパーティライブラリやチーム作業を円滑にするための方法なども解説しています。また文法だけではなく、実践的な視点からの指導が含まれています。今後Goを開発業務で利用したい中級者に大変おすすめの書籍です！！

私の以下3つのおすすめポイントを紹介していきます。

1. 「Goらしさ」をわかりやすく説明している
2. 開発で役立つ実用的な内容を網羅的に学べる
3. 動かし方だけではなく、使う上での考え方なども説明している

「Goらしさ」をわかりやすく説明している

実践的な内容と共に「Goらしさ」を学べる点はとても良かったです。複数の言語への言及がありますが、メインではJavaとの比較が多かった印象です。Javaの経験がある方はより理解がしやすいと思います。言語を使いこなす上ではイディオム、時には現状辛いところなどの理解が重要になると思います。これらは量をこなさないと把握できないため、最初からピンポイントで学べるのは非常に大きな利点だと思います。いくつか例として引用してみます。

Goで構造体を宣言し、レシーバーを定義していくことが使い勝手の良いコードへの第一歩です。

シンプルなインタフェースを使うAPIをコアとして作り、それをラップして使いやすいAPIを別に提供するのが、標準ライブラリを含めGoで広く行われている設計手法です。

GoのテストはTable Driven Test（以下、TDT）と呼ばれる形式で実装されることが大半です。

開発で役立つ実用的な内容を網羅的に学べる

網羅的に基礎を学べたのはとても良かったです。例えば「Goらしさ」の説明（1章）から始まり、構造体（3章）などでGo言語の特徴的な構造体の考えや使い方も丁寧に説明しています。開発には欠かせないテスト（13章）やリレーショナルデータベースの利用（9章）だけでなく、開発環境構築（7章）まで紹介されています。また実運用には欠かせないエラーハンドリング（5章）や、ログとオブザーバビリティ（12章）もしっかりと説明されています。一部を挙げましたが、経験豊富な筆者陣が網羅性を意識して記載してくださったことをとても感じる内容になっていました。

動かし方だけではなく、使う上での考え方なども説明している

設計がないただ動くだけのコードは量が増えるにつれて保守性が悪くなりビジネスの足枷となります。また、想定通りの使い方をしないと予期せぬ問題に遭遇することもあります。そのため、どう動かすかだけでなくどのような考え（設計）のもと動かすのかが重要です。当書籍では設計に必要な情報を説明するだけでなく、難しいポイントでは一定のガイドラインも示してくれます。Go初心者が実用的なコードを書いていく上で大変参考になるでしょう。

例えば私はcontext.Context型はキャンセル処理を実現するもの・とりあえずプログラム全体で共有したいものを入れるやつくらいの理解しかまだできていなかったです。それに対して以下の説明でより深い理解をした上での活用が可能になりました。

このコンテキストには、次の2つの役割があります。今回紹介するのは前者です。
- 1セッションから派生するすべての処理をまとめてキャンセルする（タイムアウトでの終了も含む）
- 1セッションの中で共有される情報を保持する

コンテキストには入れようと思えば何でも入れられますが、あくまでもメインの処理ではない副次的な情報を格納する目的に限定しましょう。また、コンテキストは長時間扱うものではなく、セッションのように、ある程度の寿命を持った処理を扱うための補助的なデータ構造でしかありません。セッションの寿命よりも長い、たとえばアプリケーションが実行されているあいだ残り続けるような情報を保持するのは良くない設計です。

1セッションを意識すると、無駄な情報伝搬を防げます。このような本質的な考え方がしっかりと示されているのも当書籍のおすすめポイントです。

おわりに

Goの開発業務に携わりたい人にとてもおすすめです。私自身も大変勉強になり、業務でGoを使い始めてからも師匠と基礎的な会話ができています。ぜひ、皆さんもGoの開発業務に役立ててください。

（参考）私のレベル感

どのレベル感の私にとってとても有用だったのかがわかるように参考までに私のレベル感を説明しておきます。私は「A Tour of Go」で学習を始め、PaizaでAランクを取るために1~2ヶ月Goを休日に書いてたくらいです。情報工学科でプログラミングの基礎をJavaやC言語で学びましたがインフラ周りを専門としていたためWebアプリケーション開発の実務経験はほぼないです。主な対象読者として「Javaなど他のプログラミング言語を多少かじったことがある入社数年程度のプログラマー（後輩）」を想定していると書かれていたのでもしかしたら満たせてないかも？くらいの感じでした笑 それもあってか、実践的なことを含め学習量が多く大変勉強になりました。実際に最近業務で使い始めていますが、同僚からの指摘はすんなり理解できますし、基礎的な会話は可能になるレベルにはなれていると思います。