自社開発に夢を見るのは自由だ。
最新の技術を使い、ウォーターフォールのような厳しい納期とはおさらば。アジャイルで自由に開発して、Claude Codeも使い放題。もちろんフルリモート。
そんなイメージだけを求めて自社開発に転職するつもりなら、やめておいたほうがいい。
いや、もし本当に夢のような職場があるなら、僕にも教えてほしい。
現実には、地味な運用保守も、ユーザーからの問い合わせも、古いコードとの格闘もある。
僕はヤフーや楽天、スタートアップで、自社サービスの開発に関わってきた。
そんな僕にとって、自社開発の醍醐味は、正解のない答えを追いかけることだ。
ユーザーの困りごとを考え、チームで作って、試して、また直す。その繰り返しでサービスが育ち、使う人が増えていく。
僕は、そんな自社開発の話をしたい。
作って、試して、また直す
自社開発では、仕様書が出来上がる前から、エンジニアも一緒に考えることがある。
PdM（プロダクトマネージャー）が何を作るべきか考え、デザイナーが使いやすさを考え、エンジニアが実現方法を考える。もちろん、そんなにきれいに役割が分かれているわけでもないし、会社によっても違う。
ゼロから生み出す
ヤフーで、テレビ向けのアプリを作っていたことがある。テレビのデジタル化が進んでいた頃で、メーカーごとに独自のプラットフォームがあった。
トップ画面を作るとき、UI/UXチームが中心となってデザインコンペを開いた。エンジニアも加わり、いくつもの案を検討した。
テレビを使う人が、みんなITに詳しいとは限らない。誰でも分かりやすく、操作しやすく、しかも格好いい画面にしたい。
そんなことを、デザイナーもエンジニアも一緒になって考えた。
まず、動くものを作ってみる
いくら格好いいデザインでも、実際に操作しやすいかは別の話だ。
そこで、何パターンものデザインコンセプトから、いくつか実際に動くものを作って試した。
デザイン画を眺めるだけでは分からないことも、動かしてみれば見えてくる。コードを書くことが、何を作るか考えるための手段になる。こういう仕事は面白い。
最終的に選ばれたのは、黒い背景に、カーソルを動かすとアイコンが光る、iPhoneのUIやソニーのUIを思わせる立体的なデザインだった。
プロジェクトメンバー全員が自慢できるようなものが出来上がった。
ただ、この話にはおまけがある。
ヤフーの顔になるサービスということで、孫さんにもレビューしてもらうことになった。ヤフーのトップページはどのデバイスでも白背景だ、という趣旨の指摘があった。
結果、すべて作り直し。
立体的で格好よかったUIが、のっぺりしたウェブサイトのようになってしまった。
画面ひとつにも、ブランドや経営の考えが入り込んでくる。なかなか思いどおりにはいかないものだ。
正解は、実際に使ってもらわないと分からない
もちろん、フィードバックをくれるのは社内の人たちだけではない。
ヤフーでは、グループインタビュー（リリース前の製品を実際の利用者に見てもらい反応をもらうこと）を通じて機能を改善したこともあった。
自分たちでは使いやすいと思っていても、利用者にとって使いやすいとは限らない。
だから、まず作ってみる。実際に使ってもらう。反応を見て、また考える。
コードが完成しても、それが正解だったかどうかは、まだ分からない。
僕は、この繰り返しが好きだった。
「仕様です」で済ませたら、そこで試合終了ですよ
自社サービスを育てる、と書くと、何だか大きな仕事に聞こえる。
でも、日々の仕事はもっと地味だ。
あるとき、ユーザーから入力項目の制約について問い合わせがあった。カスタマーサポートを通じて、開発チームに相談が届いたのだ。
「仕様です」で片づける前に、そもそもその仕様が本当に正しいのかを確かめたい。
PdMがビジネス上の要件を確認する。入力できる最小・最大文字数はどこまで必要なのか。それをもとに、デザイナー兼フロントエンドエンジニアが画面を修正する。
一方、バックエンドのエンジニアはAPIの入力チェックを変更する。DBの仕様も確認し、データの追加・更新処理を修正する。
調べてみると、新規追加と更新で入力チェックの条件まで違っていた。そこも直すことになった。
たかがバリデーション、されどバリデーション。
画面で入力できても、APIが受け付けなければ意味がない。APIが受け付けても、DBに保存できなければ困る。
入力欄ひとつを直すにも、いろんな人の知識と仕事が必要になる。
では、こういう仕事を普段どうやって進めているのか。
この改善を題材に、僕が経験してきた2週間単位の開発の様子を紹介しよう。
この2週間で、何を終わらせるか
僕が経験してきたアジャイル開発の現場では、2週間を一区切りにして仕事を進めることが多かった。この区切りをスプリントと呼ぶ。
最初にチームで集まって、次の2週間で取り組むことを決める。スプリント計画だ。
例えば、今回は入力チェックの問題を改善しよう、と決めたとする。
まず仕様を確かめ、画面やAPIの修正、動作確認までに必要な作業を洗い出す。
誰が何を担当し、どの作業が次につながるのか。
そうしたことを相談しながら、必要な作業をチケットにしていく。
チケットは、担当や進み具合を共有するための作業メモだ。
もちろん、計画したからといって、すべて予定どおりに進むわけではない。
だから、毎日話す。
朝会は、小さな相談の連続
毎朝、チームで集まって進み具合を共有する。
例えば、こんな話だ。
「必要な文字数の条件を確認できた」
「画面の修正は終わった」
「APIを直したので、コードレビューをお願いします」
一つひとつは小さな報告だけど、全部同じ改善につながっている。
PdMが確認した仕様をもとに、画面とAPIの修正が進み、やがて一つにつながっていく。
コードレビューも、単に他の人に間違いを探してもらうだけではない。なぜそう実装したのかを説明したり、自分が気づかなかった問題を教えてもらったりする。
朝会では、もっと小さな困りごとも出てくる。
PR（コードの変更をレビューしてもらうための依頼）の出し方が分からないとか、最近ならClaude Codeのクレジットを使い切ってしまったとか。
AIは疲れなくても、利用枠は先に力尽きる。
そんな相談も、仕事を進めるうえでは大事だ。誰かに聞けばすぐ解決することもあれば、新しく対応が必要になることもある。
新しい作業が必要になればチケットを作る。ただし、仕事を追加したからといって、残りの日数が増えるわけではない。
何を先にやり、何を後に回すか。そこもチームで相談する。
朝会は、単に昨日やったことを報告する場所じゃない。
自分の仕事を、次の誰かの仕事につなげる場所でもある。
バラバラだった仕事が、一つになる
こうして、少しずつ作業が進んでいく。
仕様の確認、画面の修正、APIやDBの修正。
レビューやテストを経て、別々だった仕事が一つになる。
僕が経験したチームでは、スプリントの終わりに、完成したものをみんなで確認する時間があった。スプリントレビューと呼ばれるものだ。
入力チェックの例なら、テスト済みの画面からAPIを呼び出し、DBまで正しく動くところをみんなで確かめる。
別々に修正したものが、目の前で一つの機能として動く。
当たり前のことなんだけど、やっぱりうれしい。
一人ひとりが進めていた仕事が、ユーザーの困りごとを解決するための、一つの改善になる。
そして、必要なリリース作業へとつなげていく。
作り方だって、改善していく
2週間の最後には、もう一つ大切な時間がある。
振り返りだ。
今回の仕事はうまく進んだか。仕様をもっと早く確認できなかったか。コードレビューをお願いするときに、もう少し情報があればよかったんじゃないか。
そんな話をして、次の2週間に活かしていく。
サービスを少しずつ良くするのと同じように、自分たちの仕事の進め方も少しずつ良くしていく。
アジャイルというと、何だか特別な開発手法に聞こえるかもしれない。
でも、僕が好きだったのは、こういう日々の小さなやり取りだった。
自分の担当だけを終わらせるのではなく、みんなで一つの仕事を終わらせる。
その積み重ねで、サービスが少しずつ育っていく。
作る自由と、作った責任。自社開発の「自」は自分じゃない
自社開発だからといって、好きな技術を選んで、好きなように作れるわけではない。
そもそも、開発は一人でやっているわけじゃない。そして、作ったサービスを使うユーザーもいる。
自由に作れることと、好き勝手に作れることは、ずいぶん違う。
自分の正解が、チームの正解とは限らない
例えば、新しいサービスを開発するとしよう。
自分はPythonが最適だと思っている。でも、チームの他のメンバーは全員Node.jsがいいと言っている。
もちろん議論すればいい。Pythonがいいと思う理由を説明して、他の人の意見も聞く。その結果、Node.jsで作ることになったら、そっちで作る。
自分だけPythonで書き始めたら、もはやチーム開発というより反乱である。
技術選定だけじゃない。仕様の認識を合わせたり、コードをレビューし合ったり、自分がなぜそう実装したのか説明したり。
面倒に感じることもある。でも、他の人の意見を聞いて、自分一人では思いつかなかった答えにたどり着くこともある。
自分の正解を通すより、チームでより良い答えを見つける。それも自社開発の面白さだと思う。
障害対応を頑張るより、障害を起こさない努力をしたい
そして、もう一つ忘れてはいけないのがユーザーだ。
24時間365日使われるサービスなら、深夜だろうが休日だろうが、ユーザーはサービスが動くことを期待している。
当然、運用保守も仕事になる。障害が起きれば調査するし、必要なら夜間や休日の緊急対応もある。
ただ、エンジニアが24時間365日働いていたら、サービスより先に人間が壊れてしまう。
だからこそ、障害が起きにくい設計にする。壊れても影響が広がらないようにする。監視や復旧を自動化する。
夜中に呼び出されないために、昼間に頑張る。これも立派なエンジニアリングだ。
そのコード、誰が喜ぶんですか？ —— コードの完成は、仕事の完成じゃない
僕はコードを書くのが好きだ。できるなら一日中書いていたいし、会議だって少ないほうがいい。
でも、どれだけ気持ちよくコードを書いても、それだけでユーザーの困りごとが解決するわけではない。
設計もきれいにできた。テストも通った。リリースも終わった。エンジニアとしては「できた！」と言いたくなる。
でも、そのサービスを使う人が何も便利になっていなかったら、それは僕らだけの達成感だ。
仕事の評価をするのは上司かもしれない。でも、作ったものに価値があるかどうかを教えてくれるのは、ユーザーだ。
だから、デザイナーと一緒に使いやすさを考える。問い合わせを受けて仕様を見直す。自分の案が通らなくても、チームで別の答えを探す。
正直、面倒なことも多い。コードだけ書いていられたら楽なのに、と思う日もある。
もちろん、仕様の相談や運用保守より、コードを書くことに集中したい人もいるだろう。そんな人にとっては、僕が面白がってきた仕事が、かえって負担に感じられるかもしれない。
それでも、自分たちが作ったものが誰かの困りごとを減らし、使い続けてもらえたら、それが一番うれしい。
僕らの仕事は、コードを完成させることじゃない。ユーザーに価値を届けることだ。
もう少し知りたい人へ
チームで進めるアジャイル開発に興味を持った人には、『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発』をおすすめしたい。スプリント計画や朝会、振り返りが何のためにあるのか、スクラムの考え方や進め方をもう少し知りたい人に向いている。
一方、作ったサービスをどう改善し、成長させていくかに興味があるなら、エリック・リースの『リーン・スタートアップ』もおすすめだ。「構築・計測・学習」という循環は、作って、試して、また直す仕事にもつながっている。
自社開発の会社なら、どこでもこんな仕事ができるわけじゃない。エンジニアがどこまで企画に関わるのか。ユーザーの声をどう開発に反映しているのか。求人を探すときには、そんなところにも目を向けてほしい。
自分もこんなチームで働いてみたいと思った人には、僕が使った転職エージェントと情報収集サービスの比較も参考にしてもらえたらうれしい。
