株式会社K.Platinum 清水洋太
転職の面接でよく聞かれるのが「入社したら、最初は何をやることになりますか？」という質問です。新しい機能の開発、と答えられたらかっこいいのですが、弊社で実際にお願いすることが多いのは、もっと地味な仕事です。すでにあるものが「ちゃんと動いているか」を確かめる工程。いわゆるテストです。
地味だと書きましたが、これは下積みのつもりでお願いしているわけではありません。確かめる仕事は、そのシステムの設計を短時間で理解するための、いちばん確実な入り口だと考えているからです。この記事では、K.Platinumのエンジニアがテストという工程をどう扱っているのか、確かめる条件の4つの型、そして業務まで踏み込む確認の進め方を書いてみます。
「まずテストから」は、下積みのお願いではありません
新しくプロジェクトに入った人に確認作業をお願いすると、たまに申し訳なさそうな顔をされることがあります。コードを書かせてもらえないのかな、という顔です。
でも、順番を逆にして考えてみてください。あるシステムの仕様を理解したいとき、仕様書を最初から最後まで読むのと、実際に一通り動かして「この条件ならこう動く」を自分の手で確かめるのと、どちらが速く頭に入るでしょうか。私たちの経験では、圧倒的に後者です。仕様書は「そう書いてある」だけですが、確認作業は「本当にそうなっている」を自分で確かめた結果として残ります。
しかも、確認作業をしていると、必ず引っかかる場所が出てきます。想定と違う動きをする、そもそも仕様書に書かれていない条件が出てくる、画面の表示と裏側の処理が食い違っている。その引っかかりこそが、そのシステムのいちばん難しい部分です。新しく入った人がまっさきにそこを見つけてくれるのは、チームにとってもありがたいことなのです。
実際、入ってきたメンバーが最初の数週間で書いた確認メモが、そのままチームの共有資料になったことが何度かあります。長く関わっている人ほど「これは当たり前」として飛ばしてしまう前提を、新しい人は飛ばせません。その不便さが、そのまま価値になります。
だから「まずテストから」は、簡単な作業から慣れてください、という意味ではありません。いちばん学べる場所を先に渡しています。
テストケースが書けないときは、まだ仕様が分かっていません ── 確かめる条件の4つの型
確認作業のなかで、私たちがとくに時間をかけるのが「何を確かめるかを決める」工程です。実際に動かす時間より、その前の設計に時間がかかることも珍しくありません。
たとえば「金額を入力して申請する」という単純な機能ひとつでも、確かめるべきことは、少なくとも5つあります。ゼロを入れたらどうなるのか。上限ぴったりの金額ならどうか。上限を1円超えたら、きちんと止まるのか。入力せずに進めたら、どんなメッセージが出るのか。途中で通信が切れたら、申請はどちらの状態で残るのか。
もう少し踏み込むと、確かめるべき条件には型があります。ふつうに使ったときの正しい流れ、ぎりぎりの値、決められた範囲から外れた値、そして途中で中断されたとき。この4つを頭に置いておくと、初めて触る機能でも抜けの少ない一覧を作れます。先輩から最初に教わるのも、この型の話です。
こうした条件を並べていくと、自分がその機能をどこまで理解しているかが、容赦なく可視化されます。手が止まったら、それは「テストの書き方が分からない」のではなく「仕様がまだ分かっていない」というサインです。そこで初めて、設計した人や業務の担当者に質問しにいく。この順番だと、質問の中身が具体的になるので、相手の時間も無駄にしません。
確かめる相手は、コードではなく業務です
弊社のメイン事業は、お客様のビジネス課題に提案段階から入り、業務整理から改善、システム化、そしてリリースまでを一気通貫で支援するITコンサルティングです。この関わり方をしていると、テストという工程の意味合いが少し変わってきます。
たとえば、ある業界向けの業務システムで、申請から承認までの流れを作り直したことがあります。このとき私たちが確かめたのは「ボタンを押したら次の画面に進むか」だけではありません。現場の方がふだんやっている手順どおりに操作したときに、最後まで滞りなく終わるか。例外的なケース、たとえば承認する人が不在のとき、締め日をまたいだとき、過去の申請を修正したいとき。そういう業務の都合が、システムの上でもちゃんと成立するかどうかです。
この確認は、業務を知らないとできません。逆に言えば、テストのシナリオを書けるようになるころには、お客様の業務をかなり深く理解できているということでもあります。提案から入って要件を整理してきた会社だからこそ、確認の場面でも「仕様どおりか」ではなく「業務が回るか」を基準にできる。ここは弊社のエンジニアが早い段階で身につける視点です。
お客様と一緒に確認を進める日は、会議室でもオンラインでも、画面を見ながら「ここはいつもこうしています」という話が次々に出てきます。設計の打ち合わせでは出てこなかった情報が、実物を目の前にすると自然に出てくる。私たちにとって確認の工程は、最後の関門であると同時に、最後の要件ヒアリングの場でもあります。
そして、この視点を持っていると、次の提案が変わります。確認作業の途中で「この手順、毎回二度手間になっていませんか」と気づける人は、次のシステムを設計するときに、その無駄を最初から潰しにいけるからです。
こうした「業務まで踏み込む」開発の進め方に興味を持たれた方へ ── 募集中のポジションと働き方を見る
自動テストと生成AI ── 増やすこと自体は目的になりません
弊社では開発のプロセスに生成AIを組み込んでいて、テストコードの下書きをAIに書いてもらう場面も増えました。ただ、ここには気をつけている点があります。
AIは、コードを読んで「ありそうなテスト」を並べるのは得意です。一方で、そのシステムを使う人の事情までは知りません。締め日の運用、例外的な承認ルート、過去のトラブルから生まれた特別な仕様。そういう「人間側の都合」は、コードのどこにも書かれていないことが多いからです。
だから私たちは、AIに書いてもらったテストをそのまま採用せず、必ず一度「この条件は、業務のどの場面に対応しているのか」を言葉にして確かめます。対応する場面を説明できないテストは、通っても安心材料になりません。逆に、業務上いちばん困る失敗の仕方を言語化できていれば、テストの本数が少なくても十分に守れます。
もうひとつ。テストは書いたら終わりではなく、これから先ずっとメンテナンスしていく対象になります。目的を説明できないテストが増えるほど、後から入った人が「これは直していいのか、残すべきなのか」を判断できなくなる。だからこそ、数を増やすことそのものを成果にはしません。確かめる価値のある場所を選び取ることのほうが、ずっと難しく、ずっと意味のある仕事だと思っています。
おわりに ── 「動くことを確かめられる人」は、どこでも通用します
作る仕事は華やかに見えて、確かめる仕事は地味に見えます。でも、現場で長く信頼されるのは、後者ができる人です。自分が書いたものを自分で疑える人、リリース前に「ここは確かめましたか」と一言差し込める人。この習慣は、言語やフレームワークが変わっても持ち運べます。
K.Platinumでは、提案から設計、開発、そしてリリースまでを一つのチームで担当します。確かめる工程が誰か別の人の仕事として切り離されていないぶん、若いうちから「どこを確かめるべきか」を自分の頭で決める経験を積めます。最初は先輩と一緒に、慣れてきたらお客様と直接。そうやって守備範囲が広がっていくのを、私たちは何度も見てきました。
経験年数よりも、目の前のものを丁寧に疑える姿勢を大切にしています。もし、そういう働き方に興味を持っていただけたなら、ぜひ一度お話ししましょう。お待ちしています。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。