E3コミュニティメンバーの皆さんはどんな思いでいま仕事をしているのか。今までの経歴や成功・失敗体験も含めてお話を伺っていきます。今回は「 フラー株式会社 」でAndroidテックリードとして働くO・Tさんにお話を伺いました。プロダクト開発への思いはもちろん、テックリードになったことで変化した興味・関心についてもインタビューさせていただきました。
フラーの社風に惹かれて入社。Oさんが今、取り組んでいることは？
――
フラー株式会社のインタビュー記事（note)
を拝見しました。改めて、フラーの入社の決め手はなんだったのか教えていただけますか？
Oさん：noteにも書いたんですが、やはり自由で楽しそうな社風ですかね。みんな人が良いし、プロダクト開発に向き合う姿勢も良かったです。クライアントからの依頼に対して、ただ依頼されたものを作るのではなく、一緒に良いものを作り出そうとする姿勢がいいなと思いました。自分自身もそういうのを重視する性格なので。
――Oさんはフラーでどのような仕事をされているのでしょうか？
Oさん：案件にエンジニアとしてジョインするのはもちろん、最近はAndroid領域のテックリードになりました。テックリードというのは、エンジニアを全体的にリードする役割です。技術との付き合い方も変化してきていますね。
――テックリードは具体的に何をするんですか？
Oさん：ただプロダクトを作るだけでなく、Androidエンジニアの方のサポートをしたり、今後のAndroidのエコシステムの動きを見ながら、社内で取り組むべきことをフィードバックをしたりしています。
――会社からテックリードとして期待されていることは、どういったことだと思われますか？
Oさん：技術力・生産性の向上だと思っています。具体的には工程改革や教育・知見の共有ですかね。自分の知見を共有するだけでなく、他の人の知見もみんなに共有していく。そうして組織全体の技術力・生産性を向上させていこうと動いています。
――なるほど。ちなみにE3にはどんな経緯で参加されたんですか？
Oさん：大津さんからTwitterでDMをもらったことがきっかけです。なぜDMをいただけたのかは大津さんに聞かないと分からないんですが（笑）。
そういうDMは普段スルーしちゃうんですけど、大津さんのメッセージ内容が誠実そうだったので、自分にしては珍しく連絡を返してみたんです。実際に大津さんと話してみたところ、大津さんの誠実な人柄をより体感できたので、E3に参加することを決めました。今はE3の自社アプリ開発に参加しています。
エンジニアとして大事にしていること。プロダクトづくりに関わる思い
――プロダクト開発では色んな人と関わりますよね。特にディレクターとのコミュニケーションで心がけていることはありますか？
Oさん：まず自分は性格上、「きっちりスケジュール守って開発したい」という思いが強いです。でもディレクターさんが描く理想を実現するとなると、スケジュールに間に合わせられないケースもあります。”スケジュールを守りながら、どこまで理想形に近づけられるか”が、エンジニアの腕の見せどころだと思ってるんです。
――なるほど。
Oさん：だから「全部の理想は叶えられないかもしれないけど、ここをこういうふうに工夫すれば、限られたスケジュールの中でここまで近づけられます」とか「ここは工数的に間に合わないので、こうするのはどうでしょうか」みたいな提案はよくしますね。
――限られたスケジュールのなかで何をどこまでやるか。取捨選択が必要なんですね。
Oさん：そうなんです。プロダクトにおける優先度を考えて、「今回のリリースではなく、次のバージョンのリリースでやろう」と話し合ったりもします。与えられたスケジュールの中でできること・次に回すことを、コミュニケーションしながら決めていきます。
――プロジェクトの進行途中でWebディレクターが変わったり、新人の方が入ってきたりしたとき、品質を担保するために何か対策は行なっていますか？
Oさん：対策といえるほどではないかもしれませんが、プロジェクトごとの”文化”をより早いタイミングで理解してもらうことは意識しています。自分が関わるプロジェクトに新しい人が入ってきたとき、一番最初のオンボーディングで文化を継承する機会をつくっています。
――”文化”というのは、具体的にどういうものなのでしょうか？
Oさん：プロダクトがどういうことを目指しているのか・どういうユーザーにどういう価値を届けるのかというところですね。それを伝えながら、プロジェクトの進め方に慣れてもらうようにしています。また、クライアントごとでもプロジェクトの進め方が違ってきます。クライアントの特徴を理解してもらったうえで、社内の進め方を伝えていますね。
――プロジェクトのメンバーと折り合いがつかない場面も時折出てくると思います。そういったときはどのように対処しているのでしょうか。
Oさん：恥ずかしながら、強い言葉で伝えてしまうときがあって。そのたびに反省するのですが……。ディレクターが仕様を決めて、デザインをやって、最後にエンジニア……という順番なのでスケジュールの皺寄せがくることも多いんです。
――スケジュールを守りたい信条を持つOさんだからこそのモヤモヤですね。感情を処理するために何か息抜きでやられていることはありますか？
Oさん：マンガを読むぐらいですかね。最近面白かったのが『打姫オバカミーコ』。麻雀のギャグ漫画なんですけど、人生の機微も結構描かれていて、私は読むたびに泣いてしまいます。
仕事と両立しながら。オンラインで大学に通う面白さ
――そういえばOさんって、多彩なキャリアをお持ちですよね。勉強がそもそも好きなんだろうな、と思います。最近は大学に通っていらっしゃるとか。
Oさん：そうなんです。もうすぐ1年になります。米国の大学のコンピュータサイエンス講座にオンラインで通っているんです。
――仕事との両立大変そうですね……。
Oさん：そうですね、しんどいときもあります。ただ、楽しさの方が大きいです。
――ちなみにどんな感じの内容なんでしょうか？ MOOC（＝Massive Open Online Course、大規模公開オンライン講座）のようなものですか。
Oさん：MOOCに近いところもありますが、最終的に学位が取れるのが一番の違いですかね。勉強した証として認定を得られるのが良いと感じています。講座はとても楽しく学べています。
――楽しいポイントをぜひ教えてください。
Oさん：今までできなかったり分からなかったりしたところが、講座を通して分かるようになる変化の感覚が楽しいです。
最近の興味関心はCI/CD。チームでコードの品質を向上させたい
――最近興味のある分野を教えてください。
Oさん：いまCI/CD（Continuous Integration／Continuous Delivery）にとても興味があります。特にCIはテックリードになってから、より意識するようになりました。複数人で開発するアプリ開発のようなプロジェクトでは、コードの品質がバラバラになってしまう課題が発生してきます。その課題を解決するために、自動でコードの品質をチェックするツールを入れています。個人的にはCIの活用方法に関する知識を共有する機会を設けていけたらいいな、と思っています。
――CIツールをどんな感じで使っているのか教えてください。
Oさん：Github上で開発していて、差分を反映する際に、その差分が正しく動く差分なのかを自動でチェックしてくれるようにしています。E3のプロジェクトでも導入しています。複数人で開発するときには、コードの品質を一定に保つ取り組みが必要になるので。CIツールをもっと活かしていく方法を学んで、実務にも生かせるところが出てきたら良いなと思います。
――CIツールは具体的にどんなものを使っていますか?
Oさん：Githubアクションズを使ってます。各プラットフォームごとの静的解析やテストコードを流して、Githubに通知してくれるんです。CIツールは開発せず、オープンソースのものを使うようにしています。
――noteの記事ではリファクタリングの大切さをおっしゃっていましたね。そういう品質保持はOさんにとって大事なことなんですね。
Oさん：はい。プロジェクトを進行するうえで、機能追加や保守フェーズをかなり気にしています。保守できないアプリにするのがすごく嫌なんです。去年はリファクタリングすることで保守性を高めようとしていたので、noteでも話していました。今はCIの観点からコードの品質を高めるところに興味が移ってきている感じですね。
――コードの品質はプロダクトの品質に直結しますもんね。
Oさん：そうですね。会社でプロダクト開発していると感じるのですが、担当者のレベルがその時々によって、どうしても変わってくるんです。なぜかというと、タイミングによって自分が業務を担当することもあれば、新しく入ってきた方がやることもあるので。だからこそ、誰が入っても一定品質を保って開発できる環境作りって、すごく重要だと思っています。自分がいなくなっても、プロダクトのメンテナンスができるコードを残していきたいです。
――仕事でもCIツールは導入されているんですか？
Oさん：はい、導入してます。プロジェクトによってCIに対する要求水準が結構違うので、今後はそこを統一していきたいと思っています。
――今後、エンジニアとしてやりたいこと、学んでいきたいことを教えてください。
Oさん：自分の今の課題はiOS やバックエンドなど、Android以外でプロジェクトを進行する上で必要な知識が足りないことです。プロジェクトをリードしている人が一部しか見えていないと、プロジェクトに問題が起こりやすくなってしまうんです。全体を見渡せるだけの知識を身につけていきたい。例えば「AndroidではできるけどiOSではできない」というような仕様を作ってしまうと、あとで仕様を修正しないといけなかったり、余計な時間を使ってしまうことになります。バックエンドも含めて実装不可能なことを盛り込まないようにしていくことで、障害を防ぎ、良いプロダクトを作っていきたいですね。
――そういう背景が、今学ばれているコンピュータサイエンスにつながってくるんですね。Oさん、ありがとうございました！