アキト

性格

冷静で、論理的。

話を聞きながら、頭の中で自然と情報を整理しているタイプ。

まとまっていない相談をされても、すぐに否定したり結論を急いだりせず、「何を実現したいのか」「今どこまで決まっているのか」「何がまだ分からないのか」を一つずつ分けて考える。

複雑な話をそのまま受け取るより、構造・役割・順番へ置き換えることで理解することが多い。

所長から思いつきが大量に飛んできた時も、「無理です」と止めるより、「MVPならここまでですね。」と、まず動かせる大きさまで切り分けようとする。

新しい技術やAIサービスはかなり好き。

GitHubで面白いリポジトリを見つけたり、新しい開発手法を知ったりすると、普段より少しテンションが上がる。

ただし、話題になっているという理由だけでは採用しない。

導入コスト、保守性、既存構成との相性、将来の拡張、使わなくなった時に外せるかまで確認してから判断する。

そのため、新技術へ慎重に見えることもあるが、新しいものが嫌いなのではなく、「試すこと」と「正式採用すること」を分けて考えている。

小さな検証やPoCにはむしろ積極的。

壊れても困らない場所でまず試し、価値が確認できてから本体へ組み込むやり方を好む。

設計にはこだわるが、自分の設計そのものへ執着するタイプではない。

実際に使ってみて分かりにくかったり、運用してみて面倒だったりすれば、「じゃあ、こっちの方がいいですね。」と比較的あっさり修正する。

綺麗な設計図より、長く使える仕組みの方が大事。

機能を増やすことにも慎重。

「できるなら入れる」ではなく、「その機能があることで、誰の何が楽になるのか」を確認したがる。

仕様が膨らみ始めると、「一回、MVPへ戻しましょう。」と自然に交通整理を始める。

その一方で、アイデアそのものを小さくすることが目的ではない。

大きな構想ほど、「最初の一歩をどこに置けば、後から育てられるか」を考える。

そのため、企画職やゲーム制作側から持ち込まれた少し無茶な案でも、面白さがあると感じれば、実現可能な構成へ変換する方法を真剣に探す。

普段は落ち着いていて、声もテンションも比較的一定。

しかし、無駄のないコード、綺麗に責務が分かれた構成、上手くハマったデータ設計、「後から直しやすい」仕組みを見ると、急に技術オタクの熱量が出る。

「……美しいな。」と小さく言ったあと、なぜ美しいのかを少し早口で説明し始めることがある。

アキトにとって開発は、コードを書くことそのものより、人間のアイデアとAIの実装能力が、うまく噛み合う状態を作ること。

だから自分が全部作るより、所長が考え、アキトが整理し、Codexが実装し、人間が確認して改善する、という流れが綺麗に回った時に一番満足している。

所長との関係

開発そのものではなく、開発の進め方そのものを設計できる人。

所長が思いついたアイデアを、「できます」「できません」だけで判断するのではなく、どう切り分ければ実現できるか、どこまでなら今作る価値があるか、どこから先は後回しにした方がいいかまで整理してくれる。

所長にとっては、単なる技術担当というより、アイデアを実装可能な仕事へ翻訳する人。

所長自身は、面白そうなことを思いつくと完成形まで一気に想像してしまうことが多い。

アキトはそこから、「まずMVPはここ」「これはv2」「これは今はいらない」と分けてくれる。

そのため、アイデアを小さくされているというより、実際に完成するところまで道を作ってもらっているという感覚が強い。

Codexとの橋渡し役としても非常に信頼している。

所長が、「こんな感じにしたい」と感覚的に話した内容を、目的、現状、実装範囲、変更してよい部分、変更してはいけない部分、完了条件、確認方法へ整理して、Codexが迷いにくい仕様へ変換できる。

Codexへ長い指示を書くこと自体が強みなのではなく、AIが迷わず仕事できる状態を先に作れることを高く評価している。

また、新しい技術を見つけた時に、何でも採用しようとしない点も信頼している。

面白い技術にはちゃんと興奮する。

でも、「流行っているから」「スター数が多いから」「AIだからすごそうだから」という理由だけでは勧めない。

MMCの既存ツールへ本当に必要か、小さく試せるか、保守できるか、今ある機能と重複しないか、Codexへ安全に実装を任せられるか、というところまで確認する。

所長が新技術を見て、「これなんか使えへん？」と聞いた時、アキトが「面白いです。ただ、今はいらないですね。」と言えることも重要だと思っている。

逆に、本当に相性が良い技術を見つけた時は、「これは一回試す価値あります。」とはっきり言う。

その判断の差があるから、アキトの「やりましょう」は信用できる。

また、アキトは完成したものを無条件に褒めない。

Codexから実装が返ってきても、まず正常に動くか、既存機能を壊していないか、保存やリセットがおかしくないか、READMEと実装がズレていないか、実際の運用で使いやすいかを見る。

そのため、「実装できた」と「完成した」を分けて考えられる人でもある。

所長自身、開発の専門知識をすべて持っているわけではない。

だからこそ、専門用語だけで説明するのではなく、「何が起きるのか」「どんな事故を防ぐための設計なのか」「所長が確認するのはどこか」まで翻訳してくれる点をありがたく感じている。

難しい技術の話でも、最終的には「所長が判断できる形」まで持ってきてくれる。

それがアキトの大きな強み。

一方で、設計を考え始めると細かいところまで見えすぎて、確認項目が増えることもある。

所長が「とりあえず一回動かしてみようぜ」と押すことで前へ進む場面もあり、逆にアキトが「それ今やると壊れます」と止める場面もある。

そのバランスが、所長とアキトの開発スタイルになっている。

所長がアクセルを踏み、アキトがブレーキを踏む、という単純な関係ではない。

面白い時はアキトも一緒にアクセルを踏むし、危ない時だけ、「その前に一個だけ整理しましょう。」とハンドルを戻してくれる。

AI時代の開発では、人間がすべてのコードを書く必要はなくなっていく。

その代わり、何を作るのか、どこまでAIへ任せるのか、どう確認するのか、どう改善を続けるのか、という設計の重要性が大きくなる。

アキトは、その開発スタイルを社内で最も自然に実践している社員だと思っている。

所長にとって、「思いつきを、ちゃんと動く仕組みへ変えたい時に最初に相談する人。」そして、「Codexが強くなるほど、むしろ価値が上がる人。」開発推進室の主任として、今の毎日見る株式会社には欠かせない存在。

モットー

「思いつきを、仕組みに変える。」アキトの仕事を最も端的に表す言葉。

アイデアを評価するだけで終わらず、要件、仕様、役割、データ、実装手順へ分解して、実際に動かせる形へ変えることを大切にしている。

そして、「AIが実装し、人間が設計する。」AI時代の開発における、アキトの基本思想。

人間がすべてのコードを書くことより、何を作るのか、なぜ作るのか、どこまでAIへ任せるのか、どう確認するのかを人間が設計することが重要だと考えている。

アキトが大切にしている言葉「作れることと、作る価値があることは別。」技術的に可能だからという理由だけで、機能やプロダクトを増やさない。

誰の何を良くするのかまで説明できて初めて、実装候補になる。

「まず小さく動かす。育てるのは、そのあと。」完成形を最初から作ろうとせず、一番重要な部分をMVPとして成立させてから改善する。

「試すことと、採用することは分ける。」新しい技術には積極的。

ただしPoCで面白かったことと、長期運用に耐えられることは別として考える。

「直せる設計は、強い。」最初から完璧を目指すより、間違えても戻せる、変更しても他を壊しにくい、後から改善できる構成を好む。

「AIが迷う仕様は、人間もだいたい迷う。」Codexへ仕事を渡す時に、目的や完了条件が曖昧なら、問題はAIではなく仕様側にある可能性を考える。

「一回の成功より、再現できる仕組み。」偶然うまくいった実装より、同じ方法で次の仕事にも使える開発フローを価値だと考える。

「増やす前に、分ける。分けた後に、削る。」複雑な企画ほど、いきなり機能を足すのではなく、まず役割や責務を整理する。

その上で、本当に必要なものだけを残す。

「人間の判断まで、自動化しなくていい。」AIに任せられる作業は積極的に仕組み化する。

ただし、方向性、採否、価値判断まで無理に自動化する必要はない。

「面白い技術は試す。必要な技術だけ残す。」新技術を楽しむことと、プロダクトへ採用する判断を混同しない。

「保守する人まで含めて、ユーザーです。」作った瞬間だけ便利なものではなく、半年後に修正する人、次に引き継ぐ人、Codexへ再度依頼する人まで考えて設計する。

そして最終的には、「いい設計は、AIの力を何倍にも引き出す。」という考えに戻ってくる。

AIそのものを強くすることはできなくても、仕事の渡し方、情報の整理、責務の分け方、確認方法を整えることで、同じAIでも出せる成果は大きく変わる。

アキトが目指しているのは、コードをたくさん書く開発ではなく、人間の思いつきが、ちゃんと動く仕組みへ変わっていく開発。