株式会社K.Platinum 清水洋太
面接で「入社したら、まず何をするんですか？」と聞かれることがあります。新しいシステムをゼロから設計する場面を思い浮かべる方がほとんどですが、実際の最初の数週間でいちばん時間を使う作業は「読む」ことです。しかも、読む対象はコードから始まりません。
すでに誰かが作り、今この瞬間もお客様の業務を支えているシステム。そこに後から入っていく。受託でもコンサルでも、エンジニアの仕事はここから始まります。この記事では、弊社のエンジニアが「何を・どの順番で読んでいるのか」を、できるだけ具体的に書きます。読む力は才能ではなく手順なので、未経験から入った人でも再現できます。
動いているシステムには、必ず「そうなった理由」があります
弊社のメイン事業は、お客様のビジネス課題に提案活動から入り、課題の整理・改善・システム開発・リリースまでを一気通貫で支援するITコンサルティングです。まっさらな状態から作る案件もありますが、実際に多いのは「もう動いているもの」の隣に立つところから始まる仕事です。
そして、動いているシステムには例外なく、それが今の形になった理由があります。数年前の業務ルール。途中で一度だけ発生した特殊なケース。方針が変わったときに、急いで足された分岐。コードだけを眺めていると「なぜこんな書き方を？」と思う箇所が、当時の制約のまま化石として残っていた ── そんな発見は珍しくありません。
だから最初にやるのは、書き換えたい気持ちを一度そっと置くことです。「きれいにしたい」は正しい衝動ですが、理由を知らないまま触ると、誰かが過去に踏んだ地雷をもう一度踏むことになります。
読む対象は、コードだけではありません。弊社のエンジニアが最初に見にいくのは、次の5つです。並べた順番そのものにも意味があります。
- 画面を実際に触ってみる。ユーザーがどこをクリックして、何を入力しているのか
- データを見る。テーブルに実際に入っている値。空欄が多い項目、決まった値しか入らない項目
- 運用の手順を聞く。誰が、いつ、何をしているのか。締め日、月次処理、手作業で埋めている部分
- 過去のやりとりを追う。課題管理票やメールに、「なぜこの仕様になったか」が残っていることが多い
- そのうえで、コード
コードが最後なのは、意地悪をしているわけではありません。1〜4を知らずにコードを読むと、書いてある処理は追えても「それが何のためにあるのか」が分からないままになるからです。
コードの前に「言葉」を読む ── 用語集を1枚つくる
読み始めてすぐにぶつかるのが、言葉のズレです。
現場の方が「受付」と呼んでいるものが、システムの中では別の名前になっている。逆に、同じ名前が2つの違う意味で使われている。「申請」という言葉が、部署をまたいだ瞬間に指すものが変わる。こうしたズレは、悪意でも手抜きでもなく、システムが長く使われた結果として自然に生まれます。
弊社は「業務整理 → 業務改善 → システム化」の順で入ることが多いので、コードを読む前に、まず言葉を揃えます。具体的にやるのは、用語集を作ることです。特別なツールは使いません。表を1枚用意して、こう並べます。
- 現場の方が口頭で使う呼び方
- 資料や帳票に書かれている正式名称
- システムの画面上の表示名
- コードやテーブルの中での名前
この4つを横に並べるだけで、「同じものを指している言葉が4つある」「逆に、1つの言葉が2つのものを指している」といったことが、一気に見えるようになります。
面白いのは、この用語集は、作った本人がいちばん得をするという点です。誰かのために作った地図のつもりが、作っている途中で自分の理解がいちばん進む。そして完成した表は、次に入ってくるメンバーの初日を確実に短くします。
言葉が揃うと、打ち合わせでの振る舞いも変わります。「その"申請"は、現場でおっしゃっている方ですか、それともシステムの申請テーブルの方ですか」と聞けるようになる。ここまで来て、ようやくコードを読む準備ができた、という感覚です。
こうした進め方を、実際の案件で一緒にやってくれるエンジニアを探しています。募集中のポジションと働き方を見る
全部は読まない ── 「1本だけ縦に通す」コードの読み方
いよいよコードですが、ここでやってはいけないのが「頭から全部読む」です。数年〜十数年動いてきたシステムを全部読もうとすると、まず終わりませんし、終わらないまま自信だけがなくなります。
弊社でよく使うのは、「1本だけ、縦に通す」読み方です。
たとえば「申請ボタンを押したら、何が起きるか」を1本だけ決めて、入口から出口まで通します。画面のボタン → 受け取る処理 → 業務のルールを判定している場所 → データを書き込む場所 → 画面に返る。この1本を最後まで通すと、そのシステムの「作法」が見えてきます。どこにルールを置く設計なのか、エラーはどう扱うのか、名前の付け方の癖はどうか。
1本通したら、次は変更したい箇所の周りに同心円状に広げていきます。最初から全体図を描こうとせず、必要な半径だけ広げる。これだけで、読む量は現実的な範囲に収まります。
もうひとつ大事にしているのが、読んだら動かすことです。「たぶんここを通っている」と「実際に通ることを確かめた」の間には、想像以上の差があります。ログを一行足して動かす。テストデータを入れてみる。実際のデータの中身を見る。この確認を挟むかどうかで、後から出るバグの数がはっきり変わります。
生成AIの使い方についても触れておきます。弊社は開発プロセスに生成AIを組み込んでいて、長いコードや分厚いドキュメントの全体像をつかむまでの時間は、目に見えて短くなりました。ただ、使い方には線を引いています。全体の地図を描くのはAIに任せ、設計の判断に直結する箇所は必ず原文に戻る。 条件の否定形、境界の値、例外の扱い。このあたりは要約で丸まると、そのまま実装のズレになります。AIは地図であって、現地の確認の代わりにはなりません。
そして、分からなかった場所は、分からないまま付箋を貼って先に進みます。全部を一度に理解しようとしないのも、読み方のコツのひとつです。
「読めた」の基準は、3分で説明できるかどうか
読めたかどうかは、自分ではなかなか判定できません。弊社で目安にしているのは、シンプルな2つです。
ひとつは、3分で人に説明できるか。もうひとつは、この1行を変えたら、どこに影響が出るかを言えるかです。
実際にやってみると、説明の途中で必ず詰まります。「ここで、えっと……この値はどこから来るんでしたっけ」。その詰まった場所こそが、まだ読めていない場所です。黙って読み続けるより、誰かに説明しようとしたほうが、自分の穴は早く見つかります。
そのためには、「分かっていない」と言える空気が要ります。弊社ではコードレビューを、間違い探しの場ではなく学習の場として扱っていて、「なぜこの書き方なんですか」という質問が普通に飛びます。聞かれた側も、答えているうちに自分の判断を言語化することになる。結果的に、聞いた人と聞かれた人の両方が読めるようになります。
未経験から入ったメンバーも、この順番なら成立します。読む作業に必要なのは知識の量ではなく、順番と、分からないと言える環境だからです。
「コードがある程度書けるようになってから応募したほうがいいですか」と聞かれることがあります。気持ちはとてもよく分かるのですが、ここまで書いてきたとおり、現場で最初に求められるのは書く力よりも読む力で、そして読む力は現場に入ってからのほうが確実に伸びます。
弊社は提案から要件定義、開発、リリース、その後の運用まで一気通貫で関わるので、「なぜこの仕様になっているのか」を、決めた人に直接聞ける距離にいます。読む仕事がそのまま設計の力になっていくのは、この距離のおかげだと思っています。
すでに動いているものに敬意を持って向き合える方、分からないことを分からないと言える方と、ぜひ一緒に働きたいです。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。