目次
はじめに
こんにちは。
フューチャーアーキテクト株式会社の棚井です。
略歴として、フューチャーに新卒入社、Technology Innovation Group で IT コンサルタントを 3 年、Global Design Group で新規事業開発を 1 年と担当し、現在は Human Resources（つまり HR）でバックオフィスの新卒採用業務を担当しております。2023 年 4 月には当社に 100 名超の新卒が入社予定でして、その新人研修のリーダーを担当する予定です。
今回は 読書感想文連載 ということで、私のパートでは「スッキリわかる Java 入門 実践編 第 3 版」を選びました。同じ著者から「スッキリわかる Java 入門 第 3 版」というベストセラー本も出版されており、新人研修での参考書籍としてや Java の習得が必要になったタイミングで同書のお世話になったエンジニアは多いのではと思います。私の周囲でも「スッキリ Java」の単語だけで話が通じるくらい普及しており、「プログラミング初心者におすすめの本は何ですか？」と聞かれた際にその人の職場が Java 環境であれば、真っ先にこの本の「入門編」を進めています。
ただし、今回取り上げたのは「実践編（ブックカバーが濃い緑）」の方です（以降、「スッキリわかる Java 入門 第 3 版」を「入門本」「スッキリわかる Java 入門 実践編 第 3 版」を「実践本」と呼びます）。
当社の新人研修でも「入門編」と「実践編」の両方が参考図書に指定されており、購入経費が会社から支給されるほどには購入が推奨されています。
「入門編」は Java の基本文法からオブジェクト指向についてまで説明されているため多くの新人が購入するのですが、「実践編」の内容については 実践 という言葉からも「まだ自分には早いのでは？」感があり、「配属後に必要となったら購入しよう」→「購入せずのまま」の流れにいる方も多いのではと思います。恥ずかしながら私もその 1 人で、研修時代に書店で流し読みした際に「いまは不要かな」と判断して購入までには至りませんでした。
そして時は経過し、エンジニア歴 4 年目にして偶然に「実践本」の内容を見返す機会がありました。
一通り目を通したところ、本書後半の特に「第 Ⅲ 部 効率的な開発の実現」の内容が、まさに「現場エンジニアとして最初に求められるスキル」を体系的に説明していると感じまして、今回の読書感想文連載の本として選ばせていただきました。
以下に、実践編の目次を記載します。
- 第 0 章 Java を使いこなす技術者をめざそう
- 第 I 部 さまざまな基本機能
- 「入門本」の理解を前提とした応用編
- 第 Ⅱ 部 外部資源へのアクセス
- データベースやネットワークの利用
- 第 Ⅲ 部 効率的な開発の実現
- チーム作業や品質を意識した開発について
- 第 IV 部 より高度な設計をめざして
- デザインパターン、並列処理
本記事は「読書感想文」なので、特に目を引いた「第 Ⅲ 部 効率的な開発の実現（第 10 章 ~ 第 14 章）」のみを限定して取り上げます。
どんな人にオススメか？
この「実践本」は、
- プログラミング経験はあるが、チーム開発は未経験の駆け出しエンジニア
- 研修は一通り完了し、配属までのアベイラブル期間の学習教材を探している新人
- チームに新人を受け入れる予定だが、まずは何を教えるべきか迷っている人
のようなステータスの方にオススメです。
本記事を執筆時点（2023 年 2 月下旬頃）の私は、新卒採用業務を担当しています。「採用」の業務範囲は幅広く、「会社説明会の準備・実施」「採用面接の調整・遂行」「学生向けのイベント企画・推進」「採用広報活動」などを進めております。
そんな業務の中では「当社に入社予定の新人さん」から HR 宛に質問をいただくこともあります。入社予定の学生さんから受ける質問には「入社後に活躍するために、入社前に何をやっておくべきですか？」というのが多くあります。「やっておいて欲しいこと」はもちろん沢山あるのですが、個々の状況により適切なアドバイスは変わってくるため、一律の回答が難しい質問です。なので私は、以下のように「プログラミング経験はあるか」と「Git によるコード共有を前提としたチーム開発の経験はあるか」という判断軸のもと、アドバイス内容を調整しております。
- プログラミング経験なし（グループ A）
- プログラミング経験あり
- Git によるコード共有を前提としたチーム開発の経験がない（グループ B）
- Git によるコード共有を前提としたチーム開発の経験がある（グループ C）
今回取り上げた「実践本（第 10 章 ~ 第 14 章）」がオススメなのは、特に「グループ B」に所属する方々です。
このグループに属する人達には、
- 大学時代にプログラミングの経験あり
- 経験内容の大まかな方向性は
- Python 経済圏でのデータ分析
- 競技プログラミング
- 個人趣味レベルでの Web サービス開発（フレームワークを動かしてみた）
- Git の本格的な利用経験なし（コマンドは知っているが）
- チーム開発の経験なし（別エンジニアとの共同作業経験なし）
のように、これまでのプログラミングの範囲が「個人で完結」していたという特徴があります。
「IT によるアウトプット ≒ コーディング」のフレームでも十分なアウトプットが出せていた方々、とも表現できます。
本書はこのような、プログラミングの基本・基礎は身につけているが「チームでの開発経験」が不足しているエンジニアに読んでもらいたいと思います。また視点を変えると、チームに新人メンバーを受け入れる予定の上司エンジニアが「まず、キャッチアップして欲しい内容をリストアップするための参考教材」としても有効活用できると思います。
感想メモ
第 10 章 ~ 第 14 章を読んで、特に「この考え方は現場で大事だな」と思ったところから、さらに厳選した 2 つです。
線で捉える進捗と、面で捉える進捗
仕事で大事なことの1つに、アウトプットの認識合わせがあります。より具体化すると、上司にとっての「ここまでやって欲しいライン」と、部下にとっての「これくらいやれば大丈夫のライン」という 2 つのラインについて、そのズレを早い段階で無くして「成果物に求められれるラインを双方で合意すること」が手戻りなく作業を進める上では重要です。この合意ラインの設定作業を怠って先に資料作成や開発作業を進めてしまうと、後になって「それ、聞いてないし間違っている」からの手戻り作業で「もっと早く確認しておくべきだった」の後悔ルートというのは、おおよそ殆どの新人が最初に通る道だと思います（目線を変えると、新人は最初にこんな感じで転ぶことを知っている上司の元に配属になっていたら、その手戻り分も裏のバッファで考慮されていたりして、後から先輩社員の凄さに気づいたりします）。
開発フェーズでの具体的な認識合わせとしては「進捗確認」があります。チーム単位であれば毎日の朝会や、規模の大きいプロジェクトなら週次での「進捗確認」が開かれており、いろいろなドラマが繰り広げられているのだと思います。進捗確認にて、上司が不安になるタイミングの会話を再現すると、
（上司）「この A 機能、来週末にリリース予定ですが、開発進捗に問題ありませんか？」
（部下）「はい。開発は予定通りに進んでいまして、オンスケでリリース可能です」
というものです。
この 2 人の間で既に「成果物の積み重ねに基づいた信頼関係」が築かれているならばこの会話でも違和感はありませんが、配属して間も無くあまり実績を残していない新人さんがこの回答を投げてきたら黄色信号だと思います。というのも、進捗を聞かれている時点で「上司は何かしらの問題を感じている」のであり、それを部下側は認知できていない（≒ 上司のここまでやって欲しいラインと、部下のここまでやれば大丈夫のラインがズレている）可能性があるからです（もちろん、マイクロマネジメント的な属性を持つ場合や、1 人 1 人全員に進捗を聞くという非効率なマネジメント方法を取っているならば話は別ですが）。
私自身の経験やいくつかのプロジェクトを見てきて、この認識ズレは「進捗の捉え方」で説明可能なケース多く、本書の「線で捉える進捗と、面で捉える進捗」の進捗イメージによる説明がまさにその通りだと思いました。詳細内容は「実践本の p.407」を参照頂きたいのですが、ざっくり表現すると
（1） 進捗状況を、開発の 1 軸 でイメージしているパターン
（2） 進捗状況を、開発と品質の 2 軸 でイメージしているパターン
という 2 パターンの話です。もちろん、（2） が望ましい進捗把握です。
新人さんの進捗認識だと「進捗率は『完成した機能数と残りの機能数』で表現でき、0％~100％の間になる。全 5 機能中 3 機能完成しているならば、進捗率は 3/5 で 60％である。残りは 40％なのでスケジュール的に問題なし」だったとしても、レビュアーの視点では「機能開発は 60％進んでいるが、品質テストが十分になされておらず、リリース可能とは言い難い」のように、視点の数で認識相違が発生するパターンです（1） の視点だとオンスケで問題なしですが、（2） の視点だとアラート or リスケ調整というように、視点の違いで状況判断が反転することもあります。通常の開発進捗に加えて 品質の視点 を意識できているかどうかが、脱新人に向けた一歩になるのだと思います。
より上級職のマネジメントになると、視点の数がより増えて面を超えて立体で把握するだけにとどまらず、数多の経験から洗練された「進捗把握の視点」があるのだとろう思いました。普段の業務に加えて、読書により「代理経験」を積むことでより多くの視座を獲得することが重要なんだなと、改めて理解させられる内容でした。
チームによる開発
実践本の第 Ⅲ 部では「開発効率を向上する方法」が取り上げられ、その大枠として以下の 3 つが提示されています。
（1） 個人の知識と技能を上げる
（2） 道具を使う
（3） 複数人で手分けする（つまり「分業」）
「実践本」では、（1） と （2） に比べて （3） の分業は 諸刃の剣 であると指摘し、（3） の「手分けしたことによって生じる非効率性」として以下の 2 点をあげています。
（1）連携が悪いと開発効率に悪影響を与える
（2）人数が増えるほど連携が難しくなる
「実践本」では上記問題を提示して以降はスコープを「開発者の連携」に絞り込み、Git によるソースコードの共有、アジャイルな開発話へと進んでいきます。
ここでは「諸刃の剣」について、ポストコロナの働き方を絡めて考えていきます。
プロジェクトでの働き方は「分業」が基本になるとはいえ、最初から業務が細分化されている訳ではありません。「規模の拡張に合わせて、メンバーを増員する」ことに伴い、これまで個人が処理していた業務が分割され、分割されたそれぞれの業務により細やかに対応できるようになる、ということが繰り返されるのが分業の進み方 1 だと思います。
この「メンバーの増員」についてはソフトウェア業界では昔からの難題らしく、人月の神話では「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる」というブルックスの法則が語られています。なぜ人員追加が更なるスケジュールの遅延につながるかというと、新規メンバーの参画直後は「既存メンバーの作業リソースの一部を、新規参画メンバーのフォローアップに割り当てる必要がある」からです。もちろん人員追加は「フォローアップ後の活躍」を期待したものですが、プロジェクの状況次第ではこの「フォローアップ中の一時的な作業遅延」を許容できない（人員追加したはずが、アウトプット量が減ってしまうことが耐えられない）ために、既存メンバーがより疲弊することもあります（この件の話は、Clean Agile 基本に立ち戻れに詳しい記述があります）。
また、業務の引き継ぎではなく、分業のためにメンバーを追加する場合はその新規メンバーに「担当範囲が限定される分、現状よりも細やかな対応を期待する」ということになり、フォローアップ期間の延長要因となります。メンバーのリモートワーク適正次第では、知らないうちに取り返しのつかないトラブルが発生していることもあります。
ポストコロナの働き方については巨人の肩に乗った方がより将来を見通せると思うので、中島聡さんの「ニュー・エリートの時代 ポストコロナ「３つの二極化」を乗り越える」参照すると、社会への進化圧として以下 3 つが進行するとの記載があります。
（1） 時代遅れな習慣の淘汰
（2） 職務の明確化
（3） 個人の能力・生産性の可視化
これらの内容詳細は書籍を読んで頂きたいのですが、直近の数年に会社で進んだ「仕事の進め方の変化」を思い返すと、この進化圧に沿ったものが多くあるため、今後の「チームによる開発の進め方」についても、このような法則を踏まえた計画・設計・実践が必要になるのだと思いました。
また「実践本」では、「分業のメリットを最大限に発揮するために」という注意書きにて
分業のデメリットを抑制し、メリットを享受するためには、連携を維持改善するための方法、道具、ループ、メンバーの努力が欠かせない。
との記述に加えて、その直後に
「くれぐれも、ただ席を並べているだけでチームメンバーになれるとは思うなよ。」
という登場人物のセリフがあります（p.468）
常に知識や方法論をアップデートしなければいつの間にか「席がなくなっている」かもしれないので、ナレッジの吸収と実践・発信は継続しなければと思いました。
おわりに
今回は読書感想文連載ということで、オススメの本の紹介と、本を読んで触発された思考内容をフリーに書かせていただきました。色々な本を読むと「この内容、あの本では違う切り口で語られていた気がする。Kindle でもう一度読み直してみよう。お、いい感じにライン引いてメモが付いている。前の私はどんなメモを残したのだろうか」と思考が広がるのが面白かったりします。まだまだ積読本はたくさん眠っているので、引き続き消化していきたいと思います。
ここまで長文にお付き合いいただきありがとうございました。読書感想文連載はまだ続きますのでお楽しみに！
次は伊藤さんの「リーダブルコード」を読んでTerraformの可読性について考えるです。
1 プロジェクトの初期メンが色々なことを知っているように見えるのは、業務が細分化される前に色々担当していただけで、より正確に言語化すると「1 つ 1 つの業務が細分化・詳細化されておらず、少人数でも回るレベルの作業量で業務が回っていた」だけなのだと思います。いざ初期メンが最前線に戻ってくると、実務ではあまり活躍できず、むしろ顔の広さを活用した調整役として動いてもらった方が有難かったりします。