もくじ

 

• ・自己紹介
• ・なぜ、プルリクが必要なのか？
• ・プルリクを見る時に何を見ているのか？
• ・EMoshUならではのプルリクのやり方
• ・サーバーエンジニアとアプリエンジニアの連携について
• ・プルリクを作成する際に困ったこと
• ・メッセージ
• ・おわりに

 

 

 

EMoshUに入社したばかりの私は今、日々のタスク中で実装したコードのプルリクを作成する機会が多くあります。

 

※ プルリクとはプルリクエストの略でGitを用いてコードの変更をレビュアーに通知する機能のことです。

 

独学中に数回プルリクを作成したことがありますが、入社してやり方やソースコードの管理方法が変わり悪戦苦闘しています。

 

そこで、今回はチーム開発におけるプルリクのやり方や、疑問に思っていることを取締役CTOの将太郎さんに尋ねてみようと思いインタビューを敢行しました。

 

 

それでは是非、ご覧ください！！

 

 

 

 

 

 

しゅんた では将太郎さんへのインタビューを始めさせていただきます。
本日はよろしくお願いします。

 

将太郎さんよろしくお願いします。

 

 

 

 

自己紹介

 

しゅんたでは、初めてこの記事を見る方もいらっしゃると思うので、簡単な自己紹介をお願いします。

 

将太郎さん EMoshU取締役CTOの松村将太郎（まつむらしょうたろう）です。
最近、お茶にハマっていますw

 

しゅんた確かに、将太郎さんが入れてくださるお茶、めちゃめちゃ美味しいです！

 

将太郎さんえーっと…　他に何か言った方がいいのかな？w

 

しゅんた 今回は大丈夫ですよw
将太郎さんについてもっと詳しく知りたい方は下記のブログにアクセスしてみて下さい！
将太郎さんの学生時代の話やEMoshUを創業した経緯を知ることができて、とても面白い内容となっています！

 

 

 

 

将太郎さん宣伝ありがとうございますw

 

しゅんたwww

 

 

 

 

なぜ、プルリクが必要なのか？

 

 

しゅんたでは、本題の内容に入っていきます。

ズバリ、聞きます！
そもそも、なぜプルリクが必要なんでしょうか？

将太郎さんそうですね、そもそもチーム開発において、自分が書いたコードを他の人が把握しておくことは重要なので、プルリクは必要です。

 

しゅんたなるほど、自分が書いたコードをチームメンバーに共有する目的があるんですね！

 

将太郎さん簡単に言うとそうですね。
あとは、チーム開発というのは同じコードをみんなで共有しています。

しかし、コードの書き方が人によって違っていると保守性に欠けてしまいます。
なので、プルリクの中で、コードの統一を図ったり、仕様書と照らし合わせて、実際の実装と間違いがないかを確認する目的があります。

 

 

 

 

プルリクを見る時に何を見ているのか？

 

しゅんたなるほど、そういった目的があったんですね！

現在、私はプルリクを作成する機会が多いのですが、将太郎さんはプルリクを見る時に何を気をつけて見ているのでしょうか？

 

将太郎さんそうですね。
まずは、プルリクのタイトルと概要。
そして、どういった修正をしたのかを確認して、その影響範囲を確認します。

 

しゅんた最初はコードではないのですね！？

 

将太郎さんはい、私の場合はプルリクの概要がちゃんと書かれていないとコードは見ませんw

 

しゅんたなるほど…w

 

将太郎さん特に影響範囲の部分は大事で、コードを書いた人が修正内容をちゃんと把握しているかどうか。

そして、影響範囲に対して何をテストしているのかを重要視しています。

 

しゅんたそうなんですね。

 

将太郎さんというのもの影響範囲に対するテストをさぼってしまうと、不具合が多くでてしまいますし、後々動作を確認する人や不具合を直す人への負担も大きくなってしまうので、その前の段階でしっかり確認するようにしています！

 

しゅんたなるほど、勉強になります！

 

将太郎さんあと、プルリクを作成した時に”影響範囲なし”と書く人をたまに見かけるんですけど、コードを修正してプルリクを出しているわけなので、何かしらの影響はあるはずですよね？w

 

しゅんたそうですねw　これは私も身に覚えがあります…。
EMoshUで初めてプルリクを作成したときに、”影響範囲なし”と堂々と書いてしまって、将太郎さんからご指摘を受けことを思い出します。

ご指摘いただいてからは、プルリクを作成するときに影響範囲はどの部分だろうと意識するようになりました！

 

将太郎さんちなみに、ゆうた君やインターン生も最初、影響範囲なしと書いてましたw

 

しゅんたそうなんですねw　他には何かありますか？

 

 

将太郎さんそうですね、この概要などの部分をしっかり確認した後はコードの差分を確認します。

基本的には修正した内容の差分になっているか、余計な修正が入っていないかを確認します。
仮に余計な修正が入っていた場合は、やんわりと「何のために入れた修正なんですか」的なことを聞いてコミュニケーションを取るようにしています。

プルリクのコメントの書き方って難しいですよねw

 

しゅんたはいw　難しいです。

 

将太郎さんあとは、チーム開発なのでコードのインデントやフォーマットがおかしくなっていないかを確認します。

その辺、しゅんた君に結構指摘していると思うんだけどw　その辺は癖とかあるんですか？

 

しゅんたそうですねw　インデントやフォーマットに関しては、個人開発の時にあまり意識をしたことがなくて、いわゆる俺俺コードだったので、その辺りは苦戦しています。

現在、EMoshUに入社して、きちんとレビュアーの人がいる状態で開発をしていて、誰が見ても見やすいコードを書くというのは、常に意識していかなければならないなと思っています！

 

将太郎さんはい、よろしくおねいがしますw

 

しゅんたちなみに、プルリクっていうのはエンジニアしか見ないものなんでしょうか？

 

将太郎さん基本的にはエンジニアしか見ませんね。

 

しゅんたなるほど、ディレクターさんも見ないんですかね？

 

将太郎さんディレクターさんはプルリクではなく、実装したアプリを見ます。

例えばテストアプリを配信したときに、ちゃんと仕様書通りになっているかを確認するという形ですね。

 

しゅんたなるほど！　ありがとうございます。

 

 

 

 

EMoshUならではのプルリクのやり方

 

しゅんたさて、ここからはさらに深掘りした話になるんですけど、EMoshUならではのプルリクのやり方ってありますでしょうか？

 

将太郎さんまぁ、基本的には一般的なプルリクのやり方と変わらないのですが、ルール化してやっているところは、レビューした人がプルリクをマージするという方針を取っています。

 

しゅんた確かに、そうですよね。この方法は珍しいのですか？

 

将太郎さん会社にはよるんですけど、特別珍しいことではないですねw

 

しゅんたそうなんですねw　レビューした人がプルリクをマージする理由って何なんでしょうか？

 

将太郎さん理由としては、他の会社ではレビュアーが特に何もせず、承認のボタンを押すだけの場合があると思うんですけど、EMoshUではちゃんと責任を持ってレビューするという意味を込めて、プルリクのレビュアーがマージします。

 

しゅんたそうなんですね！
私もプルリクを作成して、将太郎さんの”マージしました”のSlack通知が飛んでくるととてもテンションが上がりますw

 

将太郎さんwww

 

しゅんた他に何かありますか？

 

 

将太郎さんあとは、EMoshUらしさで言うと…　そうだな…
最近は、リモートワークで開発を進める企業も増えてきているとは思うんですけど、EMoshUでは基本的に出社することが前提なので、何かわからないことがあれば、対面でコミュニケーションを取れるのでそこはいい部分かなと思います。
プルリクのコメントに関しても直接話をして説明できるので。

 

しゅんた確かに！
対面でコミュニケーションが取れるというのは、めちゃめちゃありがたいです。

私も転職の時は出社できる会社に絞って活動していましたし、実際に入社してみて思うことはリモートだと、キャッチアップの速度が全然違うんだろうなと日々感じています。
将太郎さんとは、席が隣なので軽い世間話をしてコミュニケーションをとったり、私が悩んでいることを察して下さって、声をかけてくださる時があるので、とても助かっています！

 

将太郎さん開発はチームワークなので、なるべく対面でコミュニケーションをとるというのは会社運営のこだわりの一つです。

 

しゅんたそうなんですね！
ちなみに、EMoshUではソースコードの管理をGitHubではなく、Bitbucketで管理していますよね。
それには理由があるんですかね？

 

将太郎さんそれはまぁ、前職で使っていたからですw

 

しゅんたあー、そうなんですねw
個人的にはBitbucketの方が使いやすくていいなって思います。

 

将太郎さんGitHubの方が機能はたくさんあるんですけど、プルリクを使ってチーム開発する分には問題ないかと思っています。
ただ、画像のスクショを貼るときにBitbucket上でサイズの変更ができないのは困りますよねw

 

しゅんた確かに、画像がドカンって表示されますもんねw

 

将太郎さん是非、運営側には修正して欲しいですねw

 

しゅんたwww

 

 

 

 

サーバーエンジニアとアプリエンジニアの連携について

 

しゅんたあと気になっていることとして…
サーバーエンジニアとアプリエンジニアの連携部分で、プルリク上でやりとりすることはあるんでしょうか？

 

将太郎さんそうですね。
基本的にはアプリエンジニアとサーバーエンジニアの連携部分で言うと、API関係になると思います。

 

しゅんたはい。

 

将太郎さんその時に、APIの仕様書を作るんですが、それもGit上で管理しています。

 

しゅんたそうなんですね。

 

将太郎さんはい、API仕様書の作成だとOpenAPIを使ったりすることが多いのですが、その時にサーバーエンジニアとアプリエンジニアがプルリク上でやりとりして、こういうインタフェース仕様書でいいのかというのをすり合わせしていますね。

 

しゅんた基本的にはサーバーエンジニアとのやりとりはAPIの仕様書くらいなんですかね？

 

将太郎さんそうだな…
あとは…　機能を実装する際はアプリ側、サーバ側の立場で懸念点を出し合ったり、こういう動きの場合はどうなるの的なすり合わせはしたりしますね。

 

しゅんたそうなんですね！　ありがとうございます。

 

 

 

 

プルリクを作成する際に困ったこと

 

しゅんたさて、ここからは私のお悩み相談のお時間です。

 

 

将太郎さんお悩み相談ですかw

 

しゅんたはいw

私はEMoshUに入社して、ありがたいことにたくさんプルリクを作成して、将太郎さんにレビューをしていただいているのですが、その時に困ったことだったり、疑問に思ったことをまとめてきましたのでお伺いしていこうと思います！

 

将太郎さんどうぞ！

 

しゅんたまずは一つ目です。

チーム開発の時に、コードの修正量が多くなった時はどうすればいいんでしょうか？

 

将太郎さん えーっと…
まず、事前に修正量が多くなることがわかる場合は、そもそもプルリクを分けることが一番ベストです。

 

しゅんた確かに、そうですよね。

 

将太郎さんもし、それができなかったら、最低限コミットが作業単位で分かれているのであれば、大丈夫かなって思いますね。

 

しゅんたありがとうございます。
では修正量が多くなりそうだなって時に、開発メンバーに相談して、タスクを細分化することが一番いいんですかね？

 

将太郎さん はい、そうですね。

例えば、データ永続化の仕組みなどをガラッと変える時はタスクを細分化出来ないか？
と開発メンバーに相談するといいですね。そこは、報告、連絡、相談です！

 

しゅんたはいwww　ありがとうございます！

続いての質問です。
これはEMoshUのことではないんですけど、他社のエンジニアさんと連携してチーム開発する時になかなかレビューしてくれなかった時とかはどうすればいいんでしょうか？

 

将太郎さん他社さんとやる場合は、その時の状況にもよるんですけど…
もしコードレビューで作業が止まってしまう場合は…　そうだな…　先方さんの都合とかもあるので、そこは話し合いで解決するしかないですねw

 

しゅんたまぁ、そうですよねw

 

将太郎さんただし、EMoshUだけのチーム開発でプルリクのレビューが遅れている場合は遠慮なく”煽って”くださいw
（EMoshUでは、確認や実装を促す時は愛を込めて、”煽り”という表現をしておりますw）

 

 

しゅんたわかりましたwww

 

将太郎さんwww

 

しゅんたちなみに、プルリクのレビューを返す目安期間はあるんですかね？

 

将太郎さん 基本的には早ければ早いほどいいです！
というのも、プルリクが溜まってしまうと…　その間にも他の開発が進んでコンフリクトが発生してしまいます。

 

しゅんた確かに。

 

将太郎さん余計なメンテナンスの時間がかかってしまうので、なるべく早くレビューすることを意識しています。

 

しゅんたちなみに、将太郎さんはどのくらいで返そうっていうのはあるんですか？

 

将太郎さん一日以内には返すようにしていますね。

 

しゅんたそうなんですね。ありがとうございます！

最後の質問です。
プルリクを提出して、”ここを修正してください”という形でレビューの返答が返ってきますよね。

 

将太郎さんはい。

 

しゅんたその修正した内容だけ、レビュアーの人にわかりやすく伝えるために意識することはありますでしょうか？

 

将太郎さんそうですね。
プルリクにどういった意図で実装しましたなどの補足のコメントを入れるようにしてください。もしくはSlackでよく見てもらいたい箇所を伝えるとかですかね。

あとは、そうだな…　実装した内容が相手に伝わりにくそうだなって思った場合は、該当箇所にあらかじめコメントを入れておくのも効果的です。

こうすることで、無駄なやり取りがなくなるので、スムーズな開発ができます！

 

しゅんたあ〜、なるほど！
まだまだ、私はレビュアーに対する視点というか…　想像力が足らない部分がありますね。

 

将太郎さんこれは経験としか言いようがないんですけど、見る側も機械的に「プルリク作成しました。あとはよろしく〜」だと、あんまり進んで見る感じにはならないと思うし、レビュアーにとっていい感じに書いてくれればいいので、そこはよろしくお願いします！

 

しゅんたはい！　しっかり考えるようにします！

 

 

 

 

メッセージ

 

しゅんたでは、最後に言い残したことはありますか？

 

 

将太郎さんそうですね。
今回、インタビューしてくれた内容はEMoshUでプルリクをやりとりする際に意識しているところになります。

弊社ではプルリクにおいても対面でのコミュニケーションを意識して開発を進めているので、このインタビューを通して弊社に興味がある方は是非ご応募ください！

 

しゅんた綺麗にまとめていただいてありがとうございます！w

ということでインタビューは以上となります。
ありがとうございました！

 

 

 

 

おわりに

 

今回は取締役CTOの将太郎さんに、EMoshUのプルリクのやり方についてお話を伺いました。

 

このような機会でないとじっくり聞くことができない、EMoshUのプルリクの作成方法やチーム開発の進め方、さらにはなぜプルリクを作成しなければならないのかという基本的なところまでお伺いすることができ、改めてプルリクはチーム開発において必要不可欠なものなんだと、理解することができました。

 

私も、レビュアー目線に立った思いやりのあるプルリク作成をこれから意識していきます！

 

最後に、弊社のチーム開発やメンバーにご興味を持たれましたら、是非下記の募集要項をご覧ください。
ご連絡お待ちしております。

 

今回はお忙しい中、インタビューありがとうございました。

 

 

 

 

 

 

募集要項

• iOSエンジニア
• Androidエンジニア
• サーバーサイドエンジニア
• ディレクター
• エンジニアインターン

 

 

 

まずは話を聞いてみたいという方へ

• カジュアル面談
• カジュアルランチ

 

 

 

 

 

取締役CTO将太郎さんとの一枚

 

とても勉強になりました！
インタビューありがとうございました！

 

日々の仕事風景
これからもよろしくお願いします！