nocoの開発チーム2022年度の振り返り
noco株式会社取締役CPOの多田です。2022年4月にジョインし、プロダクト・技術に関する責任者をやっています。
業務としては、いわゆるプロダクトマネージャとして、事業としてのプロダクトの目標やビジョンの設定、チームへの共有・取りまとめはもちろん、他社でいうところのいわゆるCTOに属することもやっており、機能・アーキテクチャー設計、中長期的な技術選定、開発組織開発、メンバーマネジメント、採用など多岐にわたっています。
ジョインして1年が経過し、蒔いてきた種の成果が出始めたので、ここで中間報告としてアウトプットしておこうと思い記事を書きました。
この記事では、技術に関した取り組みについて、報告を兼ねて共有したいと思います。
以前の開発体制と問題点
私がジョインする前、私たちの開発体制は一見すると機能していましたが、いくつかの問題点が存在していました。技術的な負債やリリース作業にかかる時間など、細かい問題は明確にありましたが、それだけではありませんでした。
よくある話ですが、短期的なタスクに追われ、中長期的に解決したい開発上の課題の改善や、そのためのメンバーのスキルアップができないということが潜在的に発生していると感じたのです。
そこで、ジョイン直後に行ったのは、開発における中長期的なビジョンの策定・浸透でした。
CI/CDの意識改善
まずチームとして大事にしたかったのは「中長期的な改善は地続きなものであって、短期的なタスクを押しのけてでもやる価値がある」という考え方でした。
それまでも、CI/CDとして一部CircleCIをつかったものがありましたが、インフラは手で作成されていたり、リリースフローに手作業が含まれていたりと、改善の余地がありました。
そこで、まずはチームとしてGitHub Actionsへの統一、Terraform化を決めました。
CircleCIとGitHub Actionsは正直やりたいことに対して、どちらもクリアしていたのですが、最近のGitHubの改善スピードや、CircleCIのアクセスキー漏洩事件により不安があったことから、徐々に移行を進めています。
Terraformについては、AWS CloudFormationという選択もありましたが、AWS以外の管理も統一することで、チーム全体でTerraformに触れるようにしたい、という考えからTerraformに統一しました。
それだけでなく、開発中のlinter/formatterの整備や継続的改善やOpenAPI生成コードの自動適用など、いわゆるCI/CDより手前の効率化についても、取り組んでいます。
例えば、本日同時に公開したこちらの記事では、ESlintをつかった取り組みについて紹介しています。「これESLintにしたら？」といったら何日かで作ってくれました。
継続的スキルアップ機会の提供
スタートアップでは自学自習が求められがちですが、それだけでは各人のスキルセットの底上げは果たせません。
スクラムのように一丸となった開発のためには、メンバー間の意識やレベルについて現状の下限を把握し、それを上げていく仕組みを組織的に行うことが重要だと考えています。これは、「スキルの深さ」だけでなく「スキルの幅」についても言えることで、特定領域でプロフェッショナルであっても、隣接する技術領域を知ることで、イノベーションが生まれます。
そのために企画したのが、社内で「Quick Hacks」と呼ばれる、プチハッカソンです。出題される課題に対してチームに分かれ、制限時間（数時間程度）で回答します。
2023年春から始めた取り組みなので、まだ実施回数は少ないですが、過去には「モダンなCSSを使ったマークアップ」「React Server ComponentsをつかったTODOアプリ」を出題しました。
1チーム数人で、Visual Studio Code Live ShareやSlackハドルを利用して、各チームごとに競争する形になります。参加者には、フロントエンドエンジニア、バックエンドエンジニア、デザイナーが含まれるのですが、それぞれの得意不得意を補いつつ、普段触らない技術領域に強制的に触れることになります。
副次的な効果として、ペアプロ/モブプロのために必要な環境構築やノウハウの蓄積ができたという嬉しい話もありました。
マネージドサービスの活用
我々の開発しているサービスには、画像や動画アップロード機能があるので、何も考えず実装しようとすると、普段使い慣れているImageMagickやFFmpegを利用することになります。
開発は速いかもしれませんが、処理をWebサーバからWorkerに分離したり、その死活監視をしたりと、運用コストは低いとは言えない状況でした。
そこで、検証も兼ねてAWS Elemental MediaConvertを本格的に使い始めました。アーキテクチャとして設計する範囲は広がるのですが、監視すべきものを減らし信頼できるマネージドサービスに括りだすことで、今後の開発効率に良い影響をもたらすはずです。
画像動画処理だけでなく、認証や動画配信など、今後も検討したい機能は多数あります。チームメンバーには、「いままでこうだったから、実績があるから」だけでなく、新しい手法でどのようなメリット・デメリットがあるのか意識して様々な技術選定をしてもらいたいと考えています。
ChatGPTの使用から活用へ
弊社では、今年の早い段階からChatGPT/GitHub Copilot for Businessの全社展開を進めており、いまやビジネス開発、プロダクト開発問わず、無くてはならないものになっています。nocoでは、この「無くてはならない」という感覚を、我々の顧客にも感じてもらいたいのです。
GitHub Copilot for Business導入はそれなりのコストがかかりますが、まず開発者として体験する重要性に比べれば、些細なものです。定期的に開発チーム内でGitHub Copilotのノウハウの共有会が開かれるようになり、浸透段階は進んでいます。
また、coderabbitai/ai-pr-reviewerやGitHub Copilot Chatといった新しいAIツール/サービスについても、自発的に検証や改善サイクルが回るようになり、「AIの利用」については思っていた以上のスピードで定着しています。
同時に、「AIをつかった機能提供」も進んでいます。「トースターチームのAI自動マニュアル作成機能」のリリースは、2週間ほどの短期間でリリースまでこぎ着け、お客様からは好評を頂いています。
「AI自動マニュアル作成」については、企画段階から「顧客が望んでいるものなのか」という点が何度も議論されました。このように「顧客が明確には意識していない潜在的なニーズ」の設計は、出してみないと評価が分かりづらいという問題がありますが、普段からAIを自分自身で利用していることから、実現すれば使われる、というある程度の確信がありました。さらに短期間で開発できたことで、リーン的な仮説検証としても有効でした。
デザインプロセスの開発統合
我々の開発プロセスは、Figmaをつかってデザインしたものを、そのまま開発チームに渡すというフローになっています。
Figmaの「コンポーネント」を使っている箇所は、多くの場合フロントエンドでも「Reactコンポーネント」として抽象化可能です。そのときに、デザイナーの考える抽象レベルをフロントエンドエンジニアとすり合わせることで、どのように共通化するべきかディスカッションするように定めました。具体的には、スプレッドシートで共通化可能なパーツを洗い出し、それをレビューするというステップを加えました。これによって、将来考えている「デザインシステムの導入」の大きな一歩を踏み出せています。
また、「AIをつかった機能提供」には、これまで以上に「技術からUI/UXへのフィードバック」が重要だと考えます。
例えば、ChatGPTのWeb UIを触ったことがある方はわかると思いますが、あの流れるような体験はServer-Sent Eventsが重要な役割を果たしています。
しかし、それが設計段階で考慮されていなければ、統合されて効果的なUI/UXは「開発時点での偶然」に依存してしまいます。
新しい技術に対していかに開発者が感度高くキャッチアップし、設計フェイズに取り込むことができるか、というのはプロダクト開発でとても面白い点であり、難しいところでもあります。今後も意識的に新技術のフィードバックを続けていきたいと考えています。
データパイプラインの整備
事業の計数管理においては、プロダクトデータを簡単に、迅速にビジネスチームや経営が見れる体制をとる事が重要です。それまでは、社内用管理画面から、スプレッドシート等に手動で転記することで成り立っていましたが、機能追加におけるモニタリング項目の修正やリアルタイム性について課題がありました。
ちょうどその時、GCP Datastream for BigQueryによるCDC が発表され、早速パイプラインの改善を行いました。これは控えめに言って神機能でした。
それまでは、AWS S3やGlueをつかって複雑な初期実装が必要だったものが、個人情報のマスクも含め、実質作業1時間程度で、リアルタイムな分析環境が整うことになりました。いまでは、BigQueryをデータマートとし、スプレッドシートと接続することで、社内の誰でもプロダクトの生きた数字にアクセスすることができるようになりました。
将来的には、BIの整備やSalesforce連携などが発生することが予想されますが、その第一段階としては非常に満足な取り組みになりました。
まとめ
ここで紹介したものは、数々の取り組みの内成功したものか、進行中で効果がありそうなものになります。これの裏には失敗施策が多数あるのも事実です。
しかし、組織開発もプロダクト開発と同じで、小さく始めて大きく育てることが重要だと考えます。大きな方針としては一貫しつつ、各論としては様々な方面から取り組むことで、打率を上げ効率的な開発を実現しています。
個別の事例については、今後詳細な記事にするつもりなので、ご期待ください。
nocoにご興味があれば
カジュアル面談や採用応募の情報はこちらまで！