新しくプロダクト開発に入ったときにやっていること

年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。

自分がウェブやアプリのエンジニアなのでその文脈で話します。
「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。

プロダクトのあるべき姿と現状を把握する

関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。

1. アプリやサイトをすみずみまで触ってみる

まず正常系をさわってみます。ECサイトだったらカート追加から購入まで。ゲームだったらチュートリアルからある程度の面をクリアするまでです。その後、各画面にいってありとあらゆるボタンをおしてどのような機能があるか確かめます。機能の概要をメモりつつ、バグなど見つけたら再現方法などもメモしておきます。あとから「短期的に貢献できること」を探すときに役立ちます。

2. アプリやウェブのレビューを読む

レビューはユーザの意見の宝庫です。App StoreやGoogle Playなどは直接ユーザがレビューを書いているのですぐ意見がわかります。
ほかにもTwitterでプロダクト名でエゴサしてみたり、2chで検索してみたりします。ストアのレビューでは見えないようなことが書いてあることがあります。

3. 家族や知り合いにアプリをさわってもらう

エンジニアだとITに慣れているというのが一般的ですがそうでない人がアプリをさわっているのをみるのは有益です。ほとんどのひとがITに慣れていないのが実情なので自分たちのほうが外れ値としてみるべきです。実際にユーザやITに慣れていない人の行動をみると思いもよらない考えや行動をしていて参考になります。

4. 社長やプロダクトオーナーに話を聞く

だいたい1~3をやれば「プロダクトの現状」については把握していると思うので、「プロダクトのあるべき姿」について探っていきます。

一番さくっと聞けるのは社長やプロダクトオーナに直接聞くことです。入社前の面接の段階だったり、入社してから面談する機会があるかもしれないのでそこで話をします。なかなかメンバーと長くはなせる機会はそうそうないので最初の段階で話せるように設定して聞くといいです。

その他に業界の雑誌や競合の記事なども見てみると理解が深まります。

5. プロダクトのドキュメントをよみまくる

timakinさんのコメントをみておもいだしました。
ドキュメントをよむのもとても大事です。10Xには月報や週報などあるのですがよみまくります。あと個人のメモなどもよみまくります。他の人が何をやっているのかどのようなことを得意としているのかわかります。

え、ドキュメントがない？チャンスです。作りましょう。いまのおすすめはnotionです。

短期的・長期的に貢献できることを探す

プロダクトのことについてだいたいわかったので次にエンジニアとして貢献できることを探します。このときに「短期」と「長期」にわけて貢献できることを探すといいです。「短期」というのは今日とか明日とか数日以内のイメージです。「長期」はそれ以上でプロダクトの大きなインパクトがでる貢献です。

「短期」の貢献を素早く行うのは信用貯金をためるためです。入ったばかりなので他のチームメンバーは自分がチームに何を貢献できるか期待しています。素早く成果をだすことで自分がプロダクトに貢献できることを示すことができその後の協力も取り付けやすくなります。協力が得やすいとその後の「長期」の貢献につなげやすくなります。

「長期」の貢献はいわずもがなプロダクトに大きく貢献するためです。小さい「短期」のインパクトを残すことも大事ですが、それだけだと大きくプロダクトがかわることはありません。あるべき姿から考えてプロダクトをどのようにかえれば10倍(10x)プロダクトが成長できるか考えてやります。(10Xは自分が働いている会社の名前でもあります。突然の宣伝！)

「短期」と「長期」の貢献をするためにエンジニアとして以下を最初にしています。

1. クライアントのリクエストとリスポンスの内容を確認する

クライアントがサーバにどのようなリクエストを出し、どのようなレスポンスを返すか確認します。時間がなければ正常系のみやります。ユーザ作成からやるといいです。

どのようなやるかですが、ローカルの環境でアプリのシミュレータもサーバも動かせれば非常に楽です。自分はREST APIにせよ、GraphQLにせよ、gRPCにせよリクエスト・レスポンスをJSONで出して必要があればjqコマンドで整形してみてます。ログを出していない場合は、コードをかえて出すようにするか面倒ならCharlesやWiresharkで中身を見にいきます。　
ローカル環境がたてられずアプリだけだとしてもCharlesでREST APIならみえます。GraphQLはどうかわかりませんが、gRPCの場合はCharlesとかで確認できないのでローカル環境をなんとかたててJSONでログを出すようにします。

リクエスト・レスポンスの中身がみえると、インプット・アウトプットの間のブラックボックスとしてのサーバの動作が想像できるようになります。動きが想像できない場合は該当のソースコードをみるといいです。

さらに可能なら正常系のリクエスト・レスポンスをみながらどのようなデータがデータベースに保存されているかもみると理解が深まります。データベースをからにしてからやるとゴミデータがないのでより見やすくなります。

2. GitHubのIssuesとPRを眺める

GitHubだとissueですが要するにどのような課題や問題があるかの内容を理解します。プロダクトの大きさにもよりますが自分はタイトルだけはクローズされたものも含めて見れるだけみます。特に気になるものは内容もみてリンクされていればコードもざっと見ます。
issueは機能や不具合を解決するために立てられるものなので直近なにを大切にして課題を解決してそれはどのような場所のコードで解決されているかわかります。
PR(Pull Request)もできるだけみます。issueがリンクされているとより理解しやすいですがまあ気にせずどんどん近いものからみていきます。

3. データベースの構造をER図で見てみる

データがどのような関係なのか理解するのはプログラムの動作を理解するのに役立ちます。リレーショナルデータベース限定ですが自分はER図を出して確認しています。ツールはいろいろありますがERAlchemyが簡単なのでそれで出しています。

PostgreSQLの場合ですが以下のようにすればER図がでます。

eralchemy -i "postgresql+psycopg2://user:password@host:port/db" -o erd.pdf

こんな感じででるので実際にデータベースにつなぎながらデータの中身を見ながらみるといいです。
データベースはDataGripを使ってみていますが見れればなんでもいいと思います。

4. プロダクトの環境を再現してみる

これは結構時間がかかるしできないこともあるのですがGCPなどのクラウドにプロダクトが動いているなら、別のまっさらなプロジェクト上に同じようにデプロイしてプロダクトのコピーを作ります。構築する上で気づかなかったことが気づけ、いっきにプロダクトでできることが広がります。
構築する上でクラウド上でのデバッグを行うので本番で問題がおきても素早く対処することができます。構築する上で不明点をあきらかにすることにより理解がより深まります。

結構面倒ですがいっきに理解が深まるのでおすすめです。もちろん会社の組織のプロジェクト上で試してください。費用もかかるので。

まとめ

かかわるプロダクトや、関われる時間によってやれることやれないことありますが、ここまでやると間違いなく貢献できるようになっています。
プロダクトは知れば知るほど面白いので素早く貢献して楽しいエンジニアライフをおくりたいものです。