未経験のインターン⽣が、2ヶ⽉半で社内の勤怠管理システムを構築するまで

Dynamo Tech Solutions Co., Ltd. インターンシップ ／ 鍋島 航

約2ヶ⽉半で、社内で使う勤怠管理システムを1つ作りました。

画⾯数は10、サーバーとデータをやり取りするAPIは34、データベースの設計は21回やり直しました。
着⼿した時点で、私にプログラミングの実務経験も知識もありませんでした。
この記事では、何を課題として設定し、どの技術を選び、何を削ったのかを書きます。
うまくいった部分だけでなく、作り直した部分も含めて記録します。

1. 誰が、何を作ったのか

私は鍋島航、23歳です。
⼤学を卒業後、カンボジアのプノンペンにあるDynamo Tech Solutions のインターンシップに参加しました。専攻はマーケティングと消費者⾏動が中⼼で、開発の実務経験とは無縁な学⽣時代を過ごしました。
インターンシップの課題として与えられたのが、社内で使う勤怠管理システムの構築でした。

― 作ったもの

社員本⼈がログインし、出退勤の打刻から各種申請までを1つの画⾯で完結できる、社内向けの勤怠管理システムです。
提供している機能は次のとおりです

・出退勤の打刻、履歴の確認、⽉次の勤務時間の集計
・カレンダー表⽰と、⽇ごとの予定メモ
・出退勤の修正・追加の申請と、その承認
・有給休暇の申請・承認・取り消しと、残⽇数の⾃動管理
・祝⽇の管理（⽇本・カンボジアの切り替えに対応）
・スタッフ管理と、チーム全体の出退勤の確認（管理者向け）
・⽇本語・英語の表⽰切り替え

― 規模

⽤語について
API：画⾯とサーバーがデータをやり取りするための窓⼝です。「今⽇の出勤時刻を教えてください」といった依頼が1件ごとに1つの窓⼝になります。
スキーマ変更：情報を保管する表の構造を変えた記録です。項⽬を1つ追加するたびに1回と数えます。
画⾯コンポーネント：ボタンや⼀覧表など、複数の画⾯で使い回せるように切り出した部品のことです。

数字だけを⾒ると順調に進んだように⾒えるかもしれませんが、データベースの設計を21回やり直しているという事実が⽰すとおり、実際には作っては戻すことの繰り返しでした。
その過程は、第3章以降で具体的に書きます。

2. なぜ作ることになったのか

最初に受け取ったのは「勤怠管理システムを作ってほしい」という依頼だけでした。
どんな機能が必要なのかは、決まっていませんでした。そこで私は、実装に⼊る前に、代表の吉⽥さんと、勤怠を管理している⼭⼝さんに話を聞くところから始めました。
「何を作るか」を決める前に、「何に困っているか」を特定する必要があると考えたからです。

― 聞き取りで⾒えた課題

― そこから決めた開発⽅針

この5つを並べたときに、共通していたのは「操作そのものが⾯倒である」という⼀点でした。
打刻を忘れることも、修正が滞ることも、根っこは同じところにあります。
そこで、開発の⽅針を2つに絞りました。

・勤怠に関する操作を、1つのシステムの中で完結させる
・1回あたりの操作の⼯程を、できるだけ減らす

「機能を増やす」は、⽅針に⼊れていません。
システムをシンプルに保つことで操作しやすさを重視し、操作の際の⼩さな⼿間やストレスを感じないよう にするためです。
この2つが、次の章で書く技術の選び⽅と画⾯の作り⽅、そのすべての根拠になっています。

3. 技術的な⼯夫・こだわり

― 何を使い、なぜ選んだのか

技術は、流⾏しているからという理由では選びませんでした。
第2章で決めた2つの⽅針を満たせるかどうかだけを基準にしています。

― 特に⼒を⼊れた3つの画⾯

このシステムの中で、私が⼀番時間をかけたのはマイページ・カレンダー・有給申請
の3画⾯です。どれも社員が毎⽇、あるいは毎⽉必ず開く画⾯だからです。
3画⾯には、共通のルールを決めました。

・ページ全体をスクロールさせない。画⾯の⾼さから共通ヘッダーと余⽩を引いた分に、内容をすべて収め
る
・横幅を3画⾯とも同じ値に揃える。画⾯を移動したときに、内容の位置が横にずれないようにする
・画⾯の幅が狭いときだけ、縦並びに切り替える。そのときはスクロールを許容する

スクロールを禁⽌したのは、⾒た⽬の問題ではありません。
探す・下げる・戻るという動作が、毎⽇積み重なるからです。

― マイページ ― 傾いて⾒える画⾯を、なくす

左に「本⽇の出退勤」と「直近の履歴」、右に「今⽇のメモ」と「有給の残⽇数」を置いた2列の構成です。
ここで⼀番時間を使ったのは、左右の列の下端を揃えることでした。
表⽰される内容は、⼈によっても⽉によっても変わります。そのたびに⽚⽅の列だけが下へ伸びると、画⾯が傾いて⾒えます。⾼さを固定するのではなく、内容が多い側に全体を合わせる形にしました。

もう1つ、条件を決めています。
出勤・退勤のボタンは、どんな画⾯の⾼さでも、スクロールせずに押せること。
1⽇に必ず2回押すボタンです。ここだけは譲りませんでした。

― カレンダー ― ある⽇、祝⽇が1つ消えた

⽇本とカンボジア、両⽅の祝⽇を同じカレンダーに表⽰し、国旗の⽬印でどちらの国のものかがわかるよう にしています。
作っている途中で、祝⽇が1つ消えました。
原因は、年によって、両国の祝⽇が同じ⽇に重なることでした。後から読み込んだほうが、先にあったほう
を上書きしていたのです。実際に2026年は、カンボジアの祝⽇と⽇本の祝⽇が重なる⽇がありました。
重なった⽇は、両⽅の名前を並べて表⽰する形に変えています。このとき、画⾯にエラーも警告も出ていません。
祝⽇が1つ⾜りないだけで、カレンダーはそのまま表⽰されてしまいます。間違っているかどうかは、こちらから⾒に⾏かないと分かりませんでした。

― 有給申請 ― 崩れるのは、いつも端だった

有給申請は、申請する側と承認する側が同じデータを⾒る画⾯です。
項⽬が多く、やったことのほとんどは、表⽰の崩れる箇所を1つずつ潰すことでした。

・申請⽇時の列に幅を指定した。指定しないと隣の列と幅を奪い合い、⽇時があふれて承認ボタンの上に重
なる
・操作の列は、最初から縦並びにした。横に並べると、折り返したときに⽚⽅だけ左端がずれる
・承認が要らない取り消しには、⾏に⾊を付けた。その場で確定してしまうため、承認する側が⾒落としや
すい

どれも、機能としては何ひとつ増えていません。
増えるどころか、ボタンの位置を変えただけで終わった⽇もありました。
それでも、毎⽇この表を⾒る⼈にとっては、新しい機能が1つ増えることよりも、この3つのほうが価値があると判断しました。

― 画⾯の外側で決めたこと

⾒た⽬よりも先に、決めたことがあります。
初⽇、私はコードを1⾏も書きませんでした。
最初にやったのは、「何ができたら完成とみなすか」を⽂書にすることです。

・ログインできること
・本⼈のデータだけが表⽰されること
・状態に応じて、必要なボタン以外が押せなくなること

など、先に条件を決めておけば、迷ったときに⽴ち返る場所ができます。
そのうえで、構造として決めたことが4つあります。

・勤怠の状態を3つに限定した。未出勤・出勤中・退勤済みだけ。
状態が決まれば、押せるボタンが⾃動的に決まります。組み合わせが増えないので、ありえない打刻が構 造的に起きません

・画⾯とサーバー側の処理を分離した実装とした。そうすることで、サーバー側が完成する前から画⾯の開
発を進められました。完成後の画⾯は、サーバーの接続先設定を変更するだけで本番環境として利⽤できます

・祝⽇をコードからデータベースへ移した。最初はコードの中に直接書いていましたが、それでは毎年の更
新が「開発作業」になってしまう。管理者が画⾯から登録できる形に変え、有給の⽇数計算からも⾃動で除外されるようにしました

・他⼈のデータは、⾒ることも変えることもできない。管理権限を持つ⼈であっても、本⼈⽤の画⾯から他
⼈のデータには触れません。パスワードは元に戻せない形に変換して保存しています。

― 修正申請 ― 3つの⼯程を、消した

第2章で挙げた課題のうち、最も直接的に⼿を⼊れたのがここです。
当初、打刻の修正は⾃由記述のコメントで依頼する⽅式でした。
「昨⽇9時に出勤したのに記録がありません」と書いて送る。受け取った側はそれを読み、意味を解釈し、正しい時刻を⼊⼒し直す。
これを、正しい出勤時刻・退勤時刻をそのまま⼊⼒する⽅式に変えました。
承認する側は、届いた時刻を反映するだけで終わります。
読む・解釈する・⼊⼒し直す。この3つの⼯程が、まるごと消えました。

細かい話が続きましたが、これが2ヶ⽉半で最も時間を使った部分です。
機能を1つ増やすことより、1か所のずれを直すことのほうに時間がかかりました。そしてその判断の根拠は、すべて第2章で決めた「操作の⼯程を減らす」に戻ってきます。

4. AIをどう使い、どう制御したか

― 書いてはくれる。決めてはくれない

正直に書きます。
実装そのものは、AIを使って進めました。
実務経験のない私が2ヶ⽉半でこの規模のシステムを組み上げられた最⼤の理由は、AIを有効活⽤できたからです。
わからない⽤語や仕組みを理解するためにも使いました。ただ、AIに渡す前と、返ってきた後は、すべて⾃分の仕事でした。

渡す前に、紙に書き出していました。⽬的は2つあります。
1つは、⾃分の考えやアイデアを⾔語化して、整理すること。もう1つは、依頼する内容を「修正するところ」「削除するところ」「追加するところ」の3つに分けて書き出すことです。ざっくりとは書きません。ボタンの位置、幅、⾼さ、使う⼈から⾒てどうか。そこまで細かく書いてから渡します。
ほかにも、進め⽅として決めていたことがあります。

・返ってきたものは、必ず画⾯で動かした。読んで納得するのではなく、動かして、⽬で⾒て、違えば直す
・同時に複数の内容を進めなかった。1つずつ、確実に潰した
・すべてレビューを通した。⾃分の判断だけで完成にしたものは、1つもありません

やってみてわかったことが2つあります。
AIは実装してくれますが、何を作るべきかは決めてくれません。
そして、原理を理解しないまま作らせると、動いていても中⾝のないものができあがります。
動くかどうかは、AIが教えてくれます。
それが正しいかどうかは、教えてくれません。

― AIを使うほど、判断する側の専⾨性が要る

「AIに書かせたのなら、未経験でも誰でも作れるのではないか」そう思われるかもしれません。やってみた実感は、逆でした。

・出てきたものを読めなければ、それが正しいかどうかを判断できない
・何を作るべきかを決めるには、使う⼈の業務を理解している必要がある。勤怠が給与にどうつながるのか
を知らなければ、守るべき条件が分からない
・原理が分かっていなければ、どこを直せばいいのかも分からない
・レビューで指摘された内容が理解できなければ、直すこともできない

私の⽴場は、はっきりしています。
AIは優秀です。ほとんど何でもできます。ただし、完璧ではありません。だから、常に疑いながら進めてきました。出てきたものを鵜呑みにせず、必ず⾃分の⼿で動かして確かめる。
この2ヶ⽉半、その姿勢だけは崩しませんでした。

AIに任せられる範囲が広がったとき、最後に効いてくるのは「これは本当に正しいのか」と問える⼒です。
それが、2ヶ⽉半でたどり着いた結論です。

5. 壁にぶつかったこと・学んだこと

― 動いているのに、なぜ動くのかを説明できない

出退勤のボタンは、状態によって押せたり押せなくなったりします。
私はこれを「ボタンを押したら、別のボタンを無効にする命令が⾛っている」のだと思っていました。
実際は違いました。
状態が変わると画⾯そのものが描き直され、その結果として押せるボタンが変わっている。命令でボタンを
操作しているのではなく、状態が先にあって、⾒た⽬は後からついてくる仕組みでした。
「動くものを作ること」と、「なぜ動くのか」を説明できることは、別でした。

― 画⾯が動くことと、システムが動くこと

開発の前半、扱っていたのはブラウザ内に保存される仮のデータでした。ログインも、打刻も、履歴も、すべて画⾯の中だけで完結していました。これを実際のサーバーとデータベースにつなぎ替えたとき、動かなくなる箇所がいくつも出ました。仮のデータでは起きなかった問題が、通信を挟んだ途端に現れる。ここで Docker を導⼊し、データベースを含めた環境を、コマンド1つで誰でも同じ状態にできるようにしました。
画⾯が動くことと、システムとして動くことの間には、いくつもの層がありました。

― 便利にしようとして、使いにくくした

2ヶ⽉半で⼀番⼤きい失敗は、これです。
当時の私は「便利であることが最優先だ！」と考えていました。
思いつく限りの機能を⽚端から⾜していきました。「あれば助かるはずだ」と。
結果どうなったか。
画⾯の統⼀感が失われ、押せるものが多すぎて、どこから⼿をつければいいのか分からない画⾯ができあがりました。
レビューで受けた指摘は、こうでした。

・使う側の⼈に⽬線を合わせること
・機能を増やす＝便利ではない
・シンプルに作ること
・何が必要とされているかを考えること
・いま開発しているものを商品として売るとしたら、⾃分は500円払ってでも使いたいと思えるか？
・お客様は、今の状態の商品に500円払ってでも使いたいと思ってくれるか？

500円の問いが、⼀番応えました。
⾃分が作ったものに、私は500円を払えませんでした。

ここから⽅針を変えました。機能もレイアウトも、増やすのではなく減らす。
第3章で書いた3画⾯の作り込みは、すべてこの転換のあとの話です。機能を⾜すことと、品質を上げることは、同じではありませんでした。
そして、「500円払ってでも使いたいか」という問いは、いまも何かを作るたびに⾃分へ向けています。

― 「＠」さえ⼊っていれば、通っていた

メールアドレスの形式を確かめる処理に、⽳がありました。「＠」が⼊ってさえいれば、それ以外がどんな⽂字列でも登録できる状態になっていたのです。
原因は単純でした。
確かめるとき、私がいつも正しい値を⼊れていたからです。正しい値を⼊れれば、正しく動きます。動いたのを⾒て、できたと思いこんでいました。
不具合は、いつも「動かない」という形で現れるわけではありませんでした。

― すべて、レビューを通っている

このシステムで私が書いたものは、すべてレビューを経てから統合されています。
⾃分の判断だけで完成にしたものは、1つもありません。
指摘を受けて作り直した回数は、数えていません。
ただ、そのたびに「なぜそれではいけないのか」まで説明してもらえたことが、そのあとの判断の基準になりました。
第1章で「データベースの設計を21回やり直した」と書きましたが、その21回の⼤半は、ここから⽣まれています。

6. 5つの課題は、どう解決されたか

第2章で、聞き取りから5つの課題を挙げました。
それぞれが、最終的にどういう形に落ち着いたのかを整理します。

いずれも、運⽤でカバーするのではなく、仕組みとしてそうなるように設計しています。
「気をつける」で解決する課題は、1つも残していません。

7. まとめ ― 何が残ったか

実務経験も知識もない状態から着⼿し、約2ヶ⽉半で勤怠管理システムを1つ作りました。
ただ、この2ヶ⽉半で本当に⾝についたものは、実装の技術だけにとどまりません。
作る前に「何ができたら完成か」を決めること。
できたものを、使う側の⽬で評価し直すこと。
この順序です。

― このシステムについて思うこと

勤怠管理システムは、働く⼈が毎⽇必ず触れるものです。そして、給与に直結します。
つまり、使いにくさが、そのまま業務の負担になり、かつ⾮常に責任の重い領域でした。
だからこそ、機能を増やすことに価値はありませんでした。
価値があったのは、操作の⼯程を1つ減らすことのほうです。
修正申請から3つの⼯程を消したこと。出退勤のボタンを、スクロールせずに押せる位置に置いたこと。
どれも地味ですが、毎⽇使う⼈にとっては、新しい機能が1つ増えるよりも効きます。⾃分が作ったものを、作った側ではなく使う側の⽬で⾒られるようになったこと。
これが、2ヶ⽉半で起きた⼀番⼤きな変化です。

― ずっと、⾒ている側でした

もともと私は、コンピューターで問題を解決していく⼈に憧れていました。
映画やドラマで⾒た、画⾯に向かって何かを打ち込み、物事を動かしてしまう⼈たち。単純に、かっこいいと思っていました。
プノンペンに来て、それを実際にやっている⼈たちを間近で⾒ました。困っていることを聞き、仕組みを作り、解決してしまう。憧れていたのは、こういうことだったのだと分かりました。
この2ヶ⽉半で、私はその⼊り⼝に⽴ちました。
実際のところ、ここまで来られたのはAIがあったからです。実務経験のない私が形にできたのは、その⼒を借りたからにほかなりません。ただ、AIがやってくれたのは「作ること」だけでした。憧れていたのは、まさにそこでした。
打ち込む速さでも、知識の量でもない。困っている⼈がいて、それを解決する形を決められること。

― これから、AIとどう向き合うか

AIと張り合うつもりは、まったくありません。
これから先は、AIを使えること⾃体が前提になると思っています。どの分野でも使われるようになる以上、知識であり、武器です。
ただ、2ヶ⽉半使ってみて、強く感じたことがあります。使う側が、物事をよく知っていなければ意味がない。
AIに曖昧なことを伝えても、何も返ってこないわけではありません。状況から「これだろう」と推測して、それらしいものを返してくれます。
問題は、それが本当に⾃分の求めていたものかどうか、こちらにはわからないことです。

⾃分が思っていることと、AIが理解したこと。
その間にズレを抱えたまま進むと、望んだ形にたどり着くまでに何度もやり直すことになります。最後に正解へ届いたとしても、かかった時間を考えれば、効率的とは⾔えません。
だから私は、渡す前に紙に書き出していました。抽象的なまま投げず、できるだけ具体的に伝える。
遠回りに⾒えて、それが⼀番の近道でした。
そして、返ってきたものを解釈するには別の⼒が要ります。これは正しいのか。質として⼗分なのか。それを判断できる⽬利きをする⼒です。
最終的に決めるのは、⼈間です。AIが速く正確になるほど、物事の本質を⾒抜く⼒が必要になると思っています。

もっと⼈の役に⽴つものを作りたい。
憧れて⾒ている側ではなく、作る側に⽴ちたいと改めて思いました。