Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

インターンシップで感じたアカツキの文化

 

はじめまして!

2019年12月11日~12月27日にサーバサイドエンジニアとして、 モバイルゲームの一部新機能実装に携わらせて頂きました三島です。

本記事では、「インターンシップを通して苦労した点&学んだ点」と「インターンシップで感じたアカツキの文化」について記述します。

目次

インターンシップを通して苦労した点&学んだ点

今回、約2週間のインターンシップで課題が2つありました。

  1. 新機能のログ出力の機能追加
  2. 管理画面の新機能項目の追加

 上記の課題の詳細を語るよりも成果発表会で用いたプレゼンを見て頂いた方が分かりやすいので、資料を以下に貼ります。(諸事情によりスライドの情報を一部削除しています)

 

 課題の概要は省き、インターンシップを通して苦労した点&学んだ点を3つ記述します。 

理解しやすいコード

  インターンシップに参加して苦労したことの一つ目は「理解しやすいコード」を書くことです。インターンに参加する前は主に研究でコーディングをしていました。研究では、自分以外がコードを読むことを想定していませんでした。そのため自身のコーディングルールを決めたり、主観で分かりやすいメソッド名・変数名を定義したりしていました。いざ、インターンに参加してプルリクエストを送った時に、RuboCopから「半角スペースが含まれている」、「改行が含まれている」などなど大量に指摘されました。その他にも様々な方からレビューを頂き、大幅にコードを修正しました。

 チーム開発はざっくりとした指摘をRuboCopが機械的に実施してくれます。そして変数名・クラス名などRuboCopでは感知されない部分を、人の目が入り客観的なレビューの2重チェックがされていました。これは、個人でコーディングする上で考えられなかったです。ですが、2重チェックを行うことで チームに配属された人が理解しやすいコードを読み、「迅速に作業に取り掛かること」、「デバックのしやすさ」に繋がります。以上から、「理解しやすいコード」を書くことの重要性を知りました。

膨大な量のコード

 2つ目は、膨大な量のコードを理解することに苦労しました。チーム開発で、今まで実装された機能のコードが大量に存在します。その中から、課題に関連するコードを理解して情報を取り出してくる必要があるため、大量のコードを読んでいきました。ですが、コードの中に「Rubyで実装されたメソッド」か「プロジェクトの中で実装されたメソッド」なのか区別がつきにくいメソッドがありました。そのためコード理解が非常に時間が掛かりました。

 結果的に、「要点を絞りコード見て理解する力」が身に付きました。大量のコードをだらだら読んでいくのは、非常に効率が悪いです!! そのため、ファイル名、変数名などから関連するコードを絞ることにしました。これは、上記で記述した「理解しやすいコード」で書かれているため可能になると感じました。

操作しやすいView

 3つ目は、利用者(非エンジニア)に対して操作しやすいViewを作ることに苦労しました。課題2では課題1と違い、明確な利用者が存在します。その存在を考慮して、Viewをデザインする必要があります。ですが、操作しやすいデザインの選択(チェックボックス、プルダウンなど)や操作性を主観で考えてしまいます。そのため、操作しやすいViewのデザインについて迷いました。

 操作しやすいViewのデザインは、客観的に評価して頂くのが一番適切でした。その他に、管理画面には似た機能が実装されているので、既存コードを参考にしました。先人達のコードは、「理解しやすいコード」を書くことや「操作しやすいView」のデザインを作る上でとても勉強になりました。

 

 以上がインターンシップを通して苦労した点&学んだ点です。まとめると、個人チームの開発の違いについて学べました。

インターンシップで感じたアカツキの文化

 ここでは、インターンシップ期間中に読んだ本と紐づけながらアカツキの文化について感じた点を記述します。成果発表会で用いた資料にも記載しているので、そちらも見てください。

下記に、インターンシップを通して感じた点を2つ記述します。

コミュニケーションの頻度

 1つ目は、インターンシップ中に発生したコミュニケーションを取るイベントの頻度についてです。私は13日間(営業日)で、12回(プロジェクトに関するイベントは除く)もコミュニケーションを取るイベントが発生していました。ほぼ毎日イベントが発生しています。なぜ業務中にこのようなイベントが頻繁に発生しているのか、とても不思議でした。

 その答えは、「Team Geek」の「2.9章 すべてはコードに通ず」に、こう記述されていました。

コードを書くことを目的とする強いチームを作るには、膨大なコミュニケーションが必要となる

 アカツキでは、エンジニア同士のコミュニケーションを取る機会が多かったです。エンジニアとのコミュニケーションを通して技術的用語を多く知れました。そして、知らない単語を調査して、日報に調査結果を記述していました。コミュニケーションによるインプットと日報によるアウトプットを毎日繰り返すことで短期間で様々な技術を効率的に学びました。

 「2.4章 成功する文化のコミュニケーションパターン」では、こう記述されていました。

同期コミュニケーションの人数を減らし、非同期コミュニケーションの人数を増やす

 アカツキの同期コミュニケーションでは、業務中に「1 on 1」や「エンジニアコミュニティ制度」などで、少人数のエンジニアとコミュニケーションを取りました。少人数のため個々で発言する機会が多く、技術的な知識共有を深めることができました。

 非同期コミュニケーションでは、Slackなどのツールを用いて業種が異なるチームや会社を休んだ人でも1日の出来事を辿ることがきます。業種と時間を問わず、多くの人が業務知識の共有を行う仕組みができていると感じました。

 「1.5章 3本柱」では、こう記述されていました。

人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基盤となる:

謙虚(Humility)、尊敬(Respect)、信頼(Trust) HRTが大事

  私がチームに配属された時に、多くの方に話しかけて頂けました。他にもランチに誘って頂き、円滑にコミュニケーションを取ることができました。すぐにチームに馴染むことができ、気軽に質問をすることができる環境でした。

 上記を通してアカツキでは、ソフトウェア開発を効果的かつ効率的にするチーム作りが徹底されています。

当事者意識

 2つ目は、チームの一員としての携わり方についてです。チームに配属され課題を告げられた時に、「ログDB設計に対してどんどん意見を出してください」と言われました。そして、課題は実際のサービスに取り入れる機能を実装することでした。これは、開発に対して当事者意識を持ち、自身がチームにどのように関わっていくかを考えさせられました。

 「THE TEAM 5つの法則」の「第1章 Aim(目標設定)の設定」では、チームの成果を上げる1つの方法として以下の記述がありました。

チームが何のために存在し、どんな影響を与えていくべきなのか意義目標をすべてのメンバーが意識し、自発的に行動し、成果を上げるチーム作り

 これは、各メンバーが当事者意識を持つことが成果に繋がることを示しています。

 私が配属されたプロジェクトは最も人数が多いです。本には「人数が増えるほど、個々の当事者意識は薄れていく」と記述されていました。ですが、アカツキでは成果を上げるために個々の当事者意識を、配属当初から持つように働きかけているように感じました。私も課題を告げられた時にチームの一員として当事者意識を持つように働きかけて頂いて、とても感謝しています。

 上記を通してアカツキでは、成果を上げるチーム作りが個々の意識作りから行われています。

最後に

  短期のインターンシップでしたが、開発現場に携わり、実際のサービスに使われる機能を実装させていただく、貴重な体験でした。そして、 アカツキの強い(成果をあげる)チームを作る文化を感じることができました。短い間でしたが、ありがとうございました。