はじめに
初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回はCryptoGamesに入社してから2ヶ月後に新サービスをリリースしたことと、そこから学んだことをまとめていきたいと思います。
ちなみに開発した新サービスは以下の『OasChoice』というサービスです（現在も新機能を開発中です）。
現在（2023年6月23日）、ユーザー数は250万人を突破しています。
毎日AM7:00~PM23:59までの間に、翌日の『OAS』という仮想通貨の価格が上がるか下がるか予測し、予測が当たると『OAS』を報酬として受け取れるサービスです。
以下の記事でも『OasChoice』の開発について取り上げられています。
本記事の対象者
この記事の対象者としては全エンジニアとなります。
ただ、特に自分と同じようなこれから新サービスの開発に携わる方や「実務未経験」という方に読んでいただきたいです！
前提
本題に入る前に、まずは当時の自分の技術レベルを簡単にまとめます。
-
バックエンド
- PythonやDjango使って簡単なシステムを開発したり、スクレイピングの経験あり。
-
フロントエンド
- Reactをちょこっと触ったことある程度。
-
インフラ
- チュートリアルやったことある程度。
-
スマートコントラクト
- 簡単なコントラクト（NFT発行など）をしたことがある。
＊記事後半の「学んだこと」や「苦労したこと」については今後も追記していく予定です。
開発開始まで
この章では開発が始まるまでの流れを振り返りたいと思います。
スタート前
入社してから1ヶ月たったある日、社長から「新サービス考えているんだけどやってみない？」と唐突に声をかけられました。
僕自身先のことは考えすぎずとにかく突っ込んでいくタイプなため、「はい！ぜひお願いします！」と喜んで引き受けました。
正直具体的な開発の流れなどは浮かんでいない状態でしたが、不思議とワクワクしていました。
設計段階
引き受けてからまずしたこととしては、「使用技術の選定」と「設計」です。
（仕様はすでに決まっていたため、それに沿って上記2点を決めました）
「使用技術の選定」はシニアエンジニアの方一緒に決め、設計についてもだいぶ手伝っていただきました（スタート部分でこけるわけにはいかないため）。
弊社のシニアエンジニアの方々は手助けを惜しまない素敵な人ばかりなので感謝でいっぱいです✨
開発
この章では開発の流れを振り返っていきたいと思います。
開発初期
とにかく不慣れな技術を使用しているため、ドキュメントや記事を見ながら実際に動かして理解や感覚を深めていました。
環境構築と不慣れなインフラに時間がかかりそうだったので、この2つはシニアエンジニアの方にも力を貸していただきながら構築していきました。
上記ループを延々に繰り返していました。
他にエンジニアに聞こうにも、「なにがわからないのかわからない」ため、当時は必死でサイクルを回していました（競輪選手もびっくりするほど）。
この時エラーがあっちこっちからひょこひょこ出てきていたため、以前よりもエラーと仲良くなることができました。
（以前はエラーに遭遇すると、ご飯の中に虫が入ってしまったくらい嫌な気持ちになっていました）
開発中期
だんだん使用している技術にも慣れてきた頃です。
開発初期よりはやっとスタート地点につけたくらいは理解できるようになっていました。
ただ、「なにがわからないのかわからない」を脱すると、よりわからないものが増えます。
例えばReactのuseEffectやuseStateなどの「React Hooks」達です。
個性豊かな彼らを使いこなすのは愚か、理解することもままなりませんでした（今も理解しきれていません）。
この時意識してことは、「まずは動くことが第一」です。
いきなりベストなコードを書くことはできないので、動かすことができれば「OK」と思いながら開発していました。
あとは、フロントのデザインをより良いものにしようとして、時間をだいぶ取られてしまっていました。
ここでは「まずは最低限で大丈夫」を意識していました。
開発中期でも学びをまとめると「まずは最低限にして、動くことが第一」となります。
テストに出るので覚えておいてください。
開発後期
リリース予定時期が迫っているということでとにかく焦っていました。
「やばい！全然間に合わない！」
と毎日ひたすら開発初期のサイクルを回しながら開発を進めていたのを思い出します。
ここでも足を引っ張ったのがデザインへのこだわりです。
「あと少し、あと少し...」
とゲーム時間が決められている子供のように引き延ばしてしまっていました。
また、リリースが迫っているにも関わらず、エラーは遠慮なく出てきて途方に暮れていました。
気持ちとしては、「進んでいない？むしろどんどん後退してない？」という状態です。
わかりやすいイメージは、空港にあるような歩く歩道を逆走している状態で、時々前方から障害物が飛んできて後ろにぶっ飛ばされている感じです。
常に走っているのに全然進んでいないのが辛いところです...。
それでもなんとかリリースできるところまで開発を完了し、開発開始から約1ヶ月でリリースすることができました。
リリース後の開発
現在（2023年6月23日）も新機能の開発を行っています。
リリースしてから3ヶ月以上経っているため、その部分の開発の流れについてもまとめていきたいと思います。
リリース ~ 1ヶ月目
当初実装予定が決まっている機能で、リリース時には反映していない機能の開発を行っていました。
この時にスマートコントラクトも絡めての作業を行なっていたため、より細心の注意を払っていました（ここで脆弱性やバグが発生するとお金に羽が生えてどこかに飛んでいくことになるため）。
シニアエンジニアの方などにも見ていただきながら実装していました。
また、合わせてバグがよく出ていました。
実際にリリースしてみると、多くのユーザーが触ることになるため、開発の時点では気付かなかった様々なバグの報告が上がっていました。
新機能の開発と並行して対応していたためなかなか大変だったことを記憶しています。
リリース ~ 2ヶ月目
小さなバグがより多く報告されていた時期でした。
1つずつ潰していくしかなかっため、順々に潰していったことを覚えています。
また、コードをシニアエンジニアの方にペアプロ（ペアプログラミング）を通して見ていただき、「脆弱性がないか」や「より良い実装方法はないか」、「ファイルなどの構成について問題ないか」など確認していただきました。
ペアプロを通しての指摘いただいた部分やアドバイスいただいた部分については、エンジニアとして大きな学びになりました。
他にもTwitter APIを使用してTwitter共有させる機能の実装などもしていました。
Twitter APIは直近v1.1のサポートを停止したため、多くの開発者が困っていましたね...。
リリース ~ 現在
そして、直近では新機能の開発とWallet Connect v2を使用してウォレット接続する部分の実装をしています。
現在はバグの量も緊急度も以前と比べると少なくなっているため、開発の部分に専念できている状態です。
と言いながら気を抜いていると容赦無く問題が降りかかっているのが常なので、気を抜かず引き続き開発を行っていきます。
バグが出ると心臓がバクバクするため、バグの報告が減ると心が穏やかになります。
（思い出すだけでも心臓がバクバクしてきます...バグ...バクバク...似てる...）
人によってはメンタルをやられると思いますので、何かしら心が休まる場所を用意しておくと良いと思います。
学んだこと
ここまで『OasChoice』をリリースするまでを辿ってきました。
この章ではリリースまでの開発を通して学んだことをまとめていきます。
デザインは突き詰めすぎない
前章でも述べているようにデザインは突き詰めすぎず、まずはざっくり決まっているデザインに沿うところまでで十分です。
前提として、デザイナーによりFigmaなどのデザインツールでデザインが決まっている場合は、自分なりの工夫を入れるのではなくそのデザインに従うことが重要です。
しかし、ざっくりデザインが決まっていてスピード重視のプロジェクトにおいて、エンジニア目線でのデザイン微調整はほとんど意味がないです。
まずは**MVP（Minimum Viable Product）**を完成させることを目指しましょう。
コードは雑でも良い
今回の『OasChoice』ようなスピード重視のプロジェクトにおいて、コードを綺麗にしすぎる必要はありません。
もちろん中堅エンジニア以上であれば、これまでの経験から初めから綺麗なコードを書けると思います。
しかし、使い慣れていないプログラミング言語などで最初から綺麗なコードを書こうとすると、いくら時間があっても足りません。
まずは動くことを目指し、コードはいくら雑でも良いと割り切りましょう。
開発していく中でより良い書き方を知り、後でリファクタリングなどを通して綺麗なコードに書き直すことはできます。
誰でも最初から完璧なはずはありません。
徐々に成長していければ良いです。
ChatGPTは親友
昨今さまざまな生成AIが出てきています。
その中でも有名なのが「ChatGPT」というAIチャットサービスです。
この「ChatGPT」を使用すると、エンジニアの強い味方になります。
例えばエラーが出た時、そのエラー文やなにをしようとしていたかを入力すると解決法を提案してくれます。
その他にもソースコードを生成してくれたりするため、今回のような不慣れな技術を使用するときは大変助かります。
他にも、今までわからないことがあり、先輩エンジニアに聞いてきたことをChatGPTに聞くことで解決することがありました。
先輩エンジニアの時間を取ることなく、いくらでも質問し放題の個別教師を手に入れたような感覚です。
ググるよりも早く解決することもあるため、今ではもう手放せません。
ただし、1つ注意点があります。
それは「ChatGPTを信じすぎないこと」です。
「ChatGPT」を万能なものだと思い、出力されたものに全幅の信頼を寄せているニュースや記事をよく見かけます。
「ChatGPT」は平気で嘘をつくこともあるため、「本当にそうなのか？」という視点は必ず持っておく必要があります。
その点ではエンジニアにとってはラッキーです。
なぜなら、ソースコードを生成してもらっても、実際に実装してみて動かなければどこかがダメということがすぐにわかります。
また、エラーが出た時の解決法を提案してくれた時、解決までの選択肢が増えるだけだからです。
エラーが出た時にありとあらゆる手を使って解決していますが、その選択肢を増やしてくれるため、エラーが解決すればその解決法が合っていて、解決しなければ今回はその解決法ではなかったということがわかるからです。
真っ暗な洞窟を想像してください。
方向感覚も狂い出口がどちらかわからない状態で、ふとある一点が明るく光っていることに気づきます。
これこそがまさに「ChatGPT」です。
迷ったエンジニアにどちらへ進めば良いかのヒントをくれる優しい存在です。
エンジニアは（特に弱々エンジニアほど）積極的に「ChatGPT」を使っていきましょう！
苦労したこと
この章ではリリースまでの開発を通して苦労したことをまとめていきます。
不慣れば技術の使用
これまで使用したことがない技術を、スピード感が求められるプロジェクトで使用するのはなかなか大変でした。
悠長にチュートリアルをやる暇もなく、実装記事やドキュメントを見ながらいきなり実装して動きを確認していました。
ベストプラクティスなんて愚か、基本的な使い方もあっているかどうかすらわからないままとりあえず前に進んでいました（時には使い方間違っていて、気付かず逆走していたこともありました）。
ただ、良かった点としては、ドキュメントを読みながら実装する経験ができたことです。
誰が書いたものかわからない記事よりも、公式が用意しているドキュメントを読む方が使い方を学ぶ上では確実です。
しかし、大体のドキュメントというものは人を寄せ付けない結界を張っているものです。
その結界を意に介さず通り抜けるには修行が必要なものです。
ただ、今回のようにドキュメントを読むしかない環境だと、ダメージを負いながら全力で結界に体当たりして脳筋で結界を突き破ることができました。
一回突き破ると結界への抵抗が和らぎ、以前よりもドキュメントが読めるようになれるため良い経験ができたと喜んでいます。
工数見積もりとは？
開発を始めるにあたり、「どれくらいの工数でリリース/機能開発できるか？」の「工数見積もり」が必要になります。
様々な記事を読んでそれっぽい工数表を作成して、「よし！これでいけそうだぞ！」と意気揚々と開発を始めました。
しかし、開発初期であることに気づきます。
「あの工数表嘘つきじゃん」ということに。
楽観的すぎて絶対無理な工数で見積もりを立てていました。
いくら記事を読んでも、「この機能だったらこれくらいにできそうだな！」という根本の想定が狂っていると工数表が何の意味もなさなくなります。
他にも以下の部分が工数見積もりをするうえで特に足りていませんでした。
- 開発の経験
- 開発項目の細分化
開発の経験
そもそも開発の経験が少ないと「どんなことに工数がかかるか」、「開発するうえで必要な項目」、「どこに工数がかかるのか」などがわかりません。
開発の経験があると、これまでの開発経験や感覚で上記の項目について答えることができます（できるはずです）。
しかし、開発経験が少ない自分にとっては、どれも何となくの楽観的な感覚値でしか答えることができませんでした。
開発経験の有無はが影響してくることは当たり前と言えば当たり前なので、徐々に見積もりの精度を上げていきたいものです。
そもそも、見積もりの時点でシニアエンジニアに確認を取るべきでした...。
開発項目の細分化
開発するにあたり、開発する項目の細分化ができておらず、「フロントエンドは〜」や「バックエンドは〜」など大きい括りで見積もっていました。
頭では「こんな機能が必要で〜」とわかっていても、実際に各機能を開発するうえでどのくらい期間が必要かを書き出すことはしていませんでした。
そのため、実際に開発にかかった工数と見積もりの工数とに差分が生じてしまいました。
工数見積もりのまとめ
今でも工数の見積もりは決してできているとは言えません。
そのため、『OasChoice』の開発を通して学んだことを活かして、今後の工数見積もりに活かしていきたいと考えています。
最後に感想として、今回の工数見積もりと実際の開発にかかった工数を比べると、楽観的に見積もった工数の1.5~2倍は実際に工数がかかるということを学べました。
適当に工数見積もりすると痛い目見るよというお話でした。
リリース後の開発での気づき
学びの転用
1つのサービスを開発している中で学ぶことは多いです。
『OasChoice』を通して学んだことで、他プロジェクトに転用しているものとしては以下になります。
- 設計段階においてのシーケンス図やAPI設計書の書き方。
- アーキテクチャについて。
- コードの書き方。
- バグとの向き合い方。
- シニアエンジニアに逐一確認を取る。
- などなど...。
ここで学んだことは別プロジェクトに活用することができます。
「最初から〇〇のようにしておけば...」ということや「〇〇のようにした方がより良いらしい」があれば、別プロジェクトでは最初から導入・対応しておけば開発の効率が上がって開発もスムーズに進むこと間違いなしです。
これを繰り返していけば強強エンジニアに一歩ずつ近づいていけるような気がしています（RPGゲームみたいにどんどんレベルアップしていくイメージで、レベル感的にはポケモンで言えばマサラタウンをやっと出れたくらい）。
バグとの向き合い方
バグが出て、それに対処していく中でだんだんバグとの向き合い方がわかってきました。
プログラミングを始めたばかりの頃はバグを敵と見做していましたが、徐々にバグは味方ということがわかってきました。
エラーメッセージも出してくれる大変親切な友達です（「はい！それダメー！」という感じで少々ウザくなる時もありますが、喧嘩するほど仲が良いと言いますよね）。
バグが出た時にエラーメッセージを見た上で、
- どこでそのエラーが起きているのか
- どんな原因で起きているのか
- どこを修正すれば良いのか
などを明確にする必要があります。
ただ、バグが出なくなって動けば良いという思考でバグ修正を行っていると、再発の可能性が拭いきれません。
「バグの上澄部分を修正しただけで、根本部分にはまだ脆弱性があり再発する。」
これでは修正したとは言えません。
しっかり原因を追求した上で修正することが大切です。
友達でも表面を知っただけではまだまだ仲良くなったとは言えません。
しっかり相手の中身を知ることが大切です（いったい何の話をしているのだろうか...）。
最後に
この記事では、弱々エンジニアが約１ヶ月で『OasChoice』というサービスをリリースした開発の流れと、そこからの学などをまとめてきました。
いかがだったでしょうか？
「何を当たり前のことをつらつらと言ってんだ」という方は、初心を忘れてしまっているかもしれないので、一度あの純粋だった頃を思い出してみてください。
＊天才の方は除きます
共感した方などはぜひコメントをいただけると嬉しいです。
批判は僕の心が傷つかない程度にお願いします。
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
採用強化中！
CryptoGamesでは一緒に働く仲間を大募集中です。
この記事で書いた自分の経験からもわかるように、裁量権を持って働くことができて一気に成長できる環境です。
「ブロックチェーンやWeb3、NFTに興味がある」、「スマートコントラクトの開発に携わりたい」など、少しでも興味を持っている方はまずはお話ししましょう！