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

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

脆弱性診断用に非ルート化端末でも動作するCUIのメモリ改ざんツール「apk-medit」を作った話

こんにちは、セキュリティエンジニアの小竹 泰一(aka tkmru)です。 アカツキでは、Webアプリケーション、ゲームアプリに対する脆弱性診断や社内ネットワークに対するペネトレーションテスト、ツール開発/検証などを担当しています。

メモリ改ざんによるチートとは

UI上に表示されている値を端末のメモリ上から検索し、見つけた値を改ざんすることでチートを行うことができる場合があります。 これはゲームのチート方法の中で最も簡単な方法で、脆弱性診断の際にも実際にメモリ上のデータを改ざんをすることでチートできるかどうか確認しています。 対策としては、XOR等を使ってメモリ上ではエンコードされた状態で値を保持し、UI上に表示されている値を検索されても見つからないようにする方法があります。

作ったツール

apk-meditという脆弱性診断のためのAndroidアプリ向けメモリ改ざんツールを作成しました。 CUIで動作し、非ルート化端末でも動作するのが特徴です。また、Goで実装しているため、Android NDKに依存していません。

github.com

使い方

非ルート化端末でメモリを読むためには、run-asコマンドを使い、実行しているアプリの権限でシェルを動作させる必要があります。 run-asコマンドはdebuggableなアプリにしか使えないため、対象のアプリがdebuggableでなかった場合には、 AndroidManifest.xmlを開きapplication nodeに対して、以下のattributeを追加する必要があります。

android:debuggable="true"

対象のアプリの準備ができたら、adbコマンドで/data/local/tmp/以下に実行バイナリをpushしてください。

$ adb push medit /data/local/tmp/medit
medit: 1 file pushed. 29.0 MB/s (3135769 bytes in 0.103s)

run-asコマンドの引数にターゲットのアプリのパッケージ名を指定し実行したあとは、自動的にディレクトリが変更されます。 apk-meditの実行バイナリを/data/local/tmp/からコピーして、実行してください。

$ adb shell
$ pm list packages # パッケージ名を確認
$ run-as <target-package-name>
$ cp /data/local/tmp/medit ./medit
$ ./medit

apk-meditを実行すると、インタラクティブなプロンプトが立ちがります。 プロンプト上に実装されたfindコマンドやpatchコマンドを用いて以下のようにメモリを改ざんすることができます。

f:id:TAKEmaru:20200327153009g:plain
apk-meditを使ってメモリ改ざんする様子
f:id:TAKEmaru:20200327153127g:plain:w175
メモリ改ざん対象のゲームの様子

フィルタ機能

小さく、キリがいい値はメモリ上にいくつもあり、1回の検索で目的のアドレスを見つけることは困難です。 そこで前回の検索で見つけたアドレスの中から、指定した値に変化しているアドレスを見つけるfilterコマンドを実装しました。

> find 100
Search UTF-8 String...
Target Value: 100([49 48 48])
Found: 712!
------------------------
Search Word...
Target Value: 100([100 0])
Found: 6605!
> filter 94
Check previous results of searching UTF-8 string...
Target Value: 94([57 52])
Found: 0!!!
------------------------
Check previous results of searching word...
Target Value: 94([94 0])
Found: 1!!!
Address: 0xe7021f70
> patch 5
Successfully patched!

filterコマンドを繰り返し使って見つかるアドレスを絞っていくことで、目的の値に到達することができます。

実装

ここでは、Goを使って開発することの利点は何なのか、 どのようにしてメモリ上のデータを読み込んでいるのかについて解説します。

開発にGoを使うメリット

今回の開発にあたり、Goを使って感じたメリットは以下の4つです。

  • ARM向けにバイナリを用意するのが簡単
  • システムコールの呼び出しが簡単
  • 大きいバイト列から目的のバイト列を高速に検索するのが簡単
  • GitHub ActionsとGoReleaserのおかげでバイナリを配布するのが簡単

ARM環境向けにLinuxバイナリを用意するのが簡単

Goコンパイラはクロスコンパイルをサポートしており、環境変数GOARCHGOARMにアーキテクチャ名とバージョンを、 環境変数GOOSにOS名を指定するだけでARM環境で動くLinuxバイナリを作成できます。

$ GOOS=linux GOARCH=arm64 GOARM=7 go build -o medit

システムコールの呼び出しが簡単

Golangにはシステムコールをいいかんじにラップしてくれているunixパッケージがあり、 システムコールを簡単に呼び出せます。 ptraceシステムコールを用いてプロセスへのアタッチするコードをC言語の場合と見比べてみましょう。

C言語でptraceシステムコールを用いたプロセスへアタッチは、<sys/ptrace.h>をインクルードすることで以下のコードでできます。 ptrace()の第3引数はcaddr_t addr, 第4引数はint dataとなっており、それぞれに読み出しや書き込みの対象とするメモリのアドレス、 書き込むデータを指定できるのですが、第1引数にPTRACE_ATTACHを設定したときは第3引数、第4引数がともに無視されます。 そのため、プロセスへアタッチする際にはそれぞれにNULLを指定する必要があります。

ptrace(PTRACE_ATTACH, pid, NULL, NULL);

Goではunixパッケージを使うと、以下のようなコードでptraceシステムコールを用いてプロセスへのアタッチができます。 Goでは不要な引数を指定しなくていいように、利便性を考えてシステムコールをラップしており、アタッチに使う関数の引数はひとつだけです。

sys.PtraceAttach(pid)

このようにGoではC言語を使うより簡単にシステムコールを扱うことができます。 Goにおけるシステムコールの扱いについては、少し古いsyscallパッケージを使ったものになりますが以下の記事が詳しいです。

ascii.jp

apk-meditでは動きが激しいアプリの動作を止めるために、ptraceシステムコールによるアタッチをattachコマンドを使ってできるようにしていますが、 メモリの読み込み、メモリへの書き込みにはptraceシステムコールを使っていません。 どのようにして、メモリ上のデータを検索しているのかは後ほど、解説します。

大きいバイト列から目的のバイト列を高速に検索するのが簡単

Rabin-Karp string search algorithmという高速に文字列を検索するアルゴリズムが bytes.Index()の内部で使われています。 これによって、複雑なアルゴリズムを自前で実装することなく、bytes.Index()を使うだけで高速にメモリ上のデータを検索することができました。

ja.wikipedia.org

GitHub ActionsとGoReleaserのおかげでバイナリを配布するのが簡単

これはGoの仕様によるものではなく、Goを使った開発を便利にしてくれるツールのおかげですが、 GoReleaserというGithub Releasesにバイナリを登録してくれるツールを、 GitHub Actions上で動かすことで、リリースバイナリを簡単に配布することができました。 以下のようなymlファイルを.github/workflows/以下に配置するだけで、GitHubにtag付きのコミットがアップロードされた際に、 GitHub Actions上でビルドが走り、GoReleaserがGithub Releasesにバイナリを登録してくれます。

name: release
on:
  push:
    tags:
    - "v[0-9]+.[0-9]+.[0-9]+"
jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1
        with:
          fetch-depth: 1
      - name: Setup Go
        uses: actions/setup-go@v1
        with:
          go-version: 1.14
      - name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v1
        with:
          version: latest
          args: release --rm-dist
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

どうやってメモリを読み込んでいるか

Linux系OSにおいて/proc/以下には、プロセスの情報にアクセスするための疑似ファイルが置かれています。 /proc/$pid/maps/proc/$pid/memを用いて、特定のプロセスのメモリマッピングを取得し、メモリを読み出す事が可能です。 /proc/$pid/mapsには以下のようなフォーマットでメモリマッピング情報が載っています。 ここには、pidで指定したプロセスがメモリのどの部分に書き込み権限、読み込み権限を持っているのかという情報が記載されています。

sargo:/data/data/jp.aktsk.tap1000000 $ cat /proc/11283/maps
12c00000-12d40000 rw-p 00000000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
12d40000-133c0000 ---p 00140000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
133c0000-13700000 ---p 007c0000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
13700000-13780000 rw-p 00b00000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
13780000-14140000 ---p 00b80000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
14140000-2ac00000 rw-p 01540000 00:05 23292          /dev/ashmem/dalvik-main space (region space) (deleted)
6f181000-6f3a6000 rw-p 00000000 fd:01 221            /data/dalvik-cache/arm/system@framework@boot.art
6f3a6000-6f3bc000 r--p 00225000 fd:01 221            /data/dalvik-cache/arm/system@framework@boot.art
6f3bc000-6f4b3000 rw-p 00000000 fd:01 229            /data/dalvik-cache/arm/system@framework@boot-core-libart.art
6f4b3000-6f4c5000 r--p 000f7000 fd:01 229            /data/dalvik-cache/arm/system@framework@boot-core-libart.art
6f4c5000-6f4f6000 rw-p 00000000 fd:01 232            /data/dalvik-cache/arm/system@framework@boot-conscrypt.art
6f4f6000-6f4f9000 r--p 00031000 fd:01 232            /data/dalvik-cache/arm/system@framework@boot-conscrypt.art
6f4f9000-6f526000 rw-p 00000000 fd:01 235            /data/dalvik-cache/arm/system@framework@boot-okhttp.art
6f526000-6f529000 r--p 0002d000 fd:01 235            /data/dalvik-cache/arm/system@framework@boot-okhttp.art
6f529000-6f57f000 rw-p 00000000 fd:01 240            /data/dalvik-cache/arm/system@framework@boot-bouncycastle.art
...

/proc/$pid/memを使って、pidで指定したプロセスが持つメモリを読むことができます。 よくある誤解として、ptraceシステムコールを使ってターゲットのプロセスにアタッチ(PTRACE_ATTACH)し、 プロセスを止めないとメモリを読めないというのがありますが、 最近のLinuxカーネルでは、アタッチしなくとも、システムコールのopen()、read()、lseek() を使ってメモリ読み出すことが可能です。 apk-meditでは、open()、read()、lseek()を直接は使っていませんが、 内部でそれぞれのシステムコールを使用しているio.NewSectionReaderFile.WriteAtを使って、読み込み、書き込みを行っています。 メモリマッピング情報から読み込み、書き込みが共にできる部分がどこなのかを得て、/proc/$pid/memを使ってメモリを読み出し、ターゲットの値を検索しています。

おわりに

apk-meditが脆弱性診断に従事するエンジニアに広く使われるよう育てていきたいと思っています。 ぜひ、気づいたことがあればフィードバックしてもらえるとうれしいです。みなさまからのIssueやプルリクエストをお待ちしております。

RSGT2020へのスポンサーをしました

f:id:yusi:20200131145917p:plain

アカツキとRSGT2020

アカツキでエンジニアリングマネージャをしている島村です。

去る2020年1月8−10日に「Regional Scrum Gathering Tokyo 2020」(以下 RSGT2020)が開催されましたが、昨年に引き続きスポンサーをさせていただきました!

Regional Scrum Gathering Tokyoとは

  • スクラムを実践する人が集い垣根を超えて語り合う場を提供するという目的によりコミットしています。

参加した方はわかると思いますが、通常のカンファレンスとは違い、Gatheringの名を示すように寄り合い所のような雰囲気が強くあり、セッションも深く考えさせられるようなものが多いです。

またセッション中に隣の人と語りあう時間をあえて用意するスピーカーもおり、そのような空気を一体となって作ってくれていました。
廊下やロビーのソファーなどで活発に意見交換がされているのも印象的でした。
まさに垣根を超えて語りあう場が形成されていたのです。

f:id:yusi:20200110121939j:plain
私達アカツキはこの理念に共感し2年連続でRSGT2020にスポンサーしています。*1

スポンサーをすることによりこのような素敵な場が毎年継続されればと思いますが、副次的にはRSGT2020に訪れる方々と出会い、さらに一緒に仕事ができるよう機会を得られればという面もあります。

参加してみて

筆者の私はというと1日目は丸々仕事で出れず、2日目も午前中は参加できませんでした。調整能力の低さを露呈してしまいお恥ずかしい限りです。

直接の参加はできなかったもののSNS上での盛り上がりは見ていました。

基調講演でのJames Coplien氏の「The Ten Bulls of the Scrum Patterns」の話は興味深く、スクラムと十牛図の語りには強く興味をもっています。
スクラムの本質を改めて考えさせられる場だったようで、参加できた同僚から改めて聞きたいと思います。

また二日目の基調講演のSahotaさんの「Lost in Translation: The Manager’s Role in Agile」も二日目の流れの源流になったとのことでSNS上で盛り上がっていました。
気になったワードは「ヒエラルキーをひっくり返す」「XY理論」「No One Gets Left Behind
一つ一つのキーワードが深く考えさせられるものです。

私は午後から参加したのですが、Sahotaさんからの流れのから組織変革とリーダーシップ、自立したチームとその価値観、マネージャの関わり方などのセッションが多くあり、一つ一つのセッションだけでなく、連続で聞いたときにより効果がでるようなセッションプログラムでした。
*2

いくつか印象的だったセッションの感想を。

キャッチーなタイトルなので興味本位で参加させてもらったが、会社単位でこの改革をしたことに脱帽です。

たしかにマトリクス組織よりチーム主体にしたときの方が小さく最適化はしやすいのは経験上あります。が、ここまで権限委譲をしたことはなく、チームがクリエイティブなところに集中できるようにマネージャ(部長)に権限と役割をもたせていました。「人員配置」や「予算」までも委譲することは考えたことがなかったです。

デメリットに1on1の実施が減っているということが記されていたので、やはり管理周りが弱くなる課題はあるようです。

また人材もチームや個人に裁量があり、体験入部制度で社内の流動性が高まる方向にあったようだが「メンバーの固定化」が弱くなることへの影響も気になりました。異動する個人を見ればモチベートにはなるので一長一短なのでしょう。

さらにマネージャ(部長)のチーム化した組織運営チームの例はとても興味深かく。職能の部長が本部全体を見るようになるので視座もあがりキャリア形成には良いかとおもいますが、「チームをまたがるところ」に課題があったようで、この組織運営チームがどこまで関与できるのか、上記の課題にどこまで関与できるのかポイントになってくるのでしょうか。

 チームで転職した及部さん(@TAKAKING22)の話しは興味があったので楽しみに参加しました。
冒頭から「チームの死とは」という疑問を会場に投げかけ、プロダクトに依存しない「Team-Based TEAM」を提唱していました。
ずっと会社員で働いてきた自分としては「会社・組織」「作るべきもの」が大前提で、それに最適化したチームやメンバー、作り方を考えることがあたり前という概念があり、プロジェクトが終われば「チームの解散(死)」は当たり前にくるものと思っていいて考えたことがなかったです。

タックマンモデルが、その通りに状態遷移するチームは2%であることが、改めてチームの継続は難しいこと考えさせられました。ただそれ以上にプロダクトが終わってもチームを死なせなかったこのチームの想いの強さには尊敬します。

また安定したチームにするには人材の固定ではなく、学習できるチームであることと説明があり、本質は「生物における新陳代謝をチームに実装する」入れていくとのこと。
チームで学習するというのはとても難しく様々な前提条件が必要になることもあるが、改めて自分のチームの一つの方向性を知ることができたのは大きいことでした。

 

他にも刺激的なセッションは多く、全体的には自分たちの組織とマネージャ、チームのあり方、またその中でどうやってチームで価値を創出していくかを考えさせられた1日でした。

最後に

f:id:yusi:20200203103505j:plain

アカツキでは、アカツキらしいプロジェクトマネジメント(≒チーム開発)を探求するメンバーの集まるコミュニティ four *3 があります。

今回のRSGT2020にはfourメンバーが多く参加し、現場に各々が持ち帰ってきており今後が楽しみです。
今年の開催中に発表された、来年のRSGT2021のチケットも既に多くのメンバーが購入済みの状態です。

ぜひ一緒にハートドリブンな世界を実現するエンジニアリングマネージャ、組織の成長、課題解決に取り組んでくれる仲間を募集しています。興味のある方はぜひ連絡をください。

hrmos.co

*1:2019年はシルバースポンサー、2020年はロゴスポンサーとなっています

*2:きっと運営の意図した流れだったのでしょう。熟練した運営はここまで考慮できることに驚きます。

*3:名前の由来は
1. 価値を出すために
2. 開発メンバーのために
3. アカツキのために
4. 自分たちのマネージメント力の強化のために
この4つの価値観を大切にするということからです。

モブプログラミングワークショップを社内向けに開催しました

f:id:yusi:20200121000011p:plain
アカツキでエンジニアリングマネージャをしている島村です。
普段はソーシャルゲームアプリの開発やエンジニア組織への取り組みなどをしています。

さて今回は自分のチームのエンジニアを対象にモブプログラミング(以下モブプロ)のワークショップを開催したのでその取り組みについて紹介させていただきます。

モブプログラミングワークショップ開催について

今回の講師として、日本のモブプロの先導者として著名な及部さん(@TAKAKING22)にお願いしました。

モブプロを知らない方に端的に説明すると、モブプロとは「チーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピュータですること」とのことです。

今回、及部さんにお願いした経緯としては、ゆのん(@yunon_phys)との1on1時にチームのスキルトランスファーがうまく進まないと相談していた時に、「及部さんにモブプロのワークショップでもやってもらう?」と案をもらったのでお願いすることに。
早速Messengerで連絡をとり快諾をいただき、1回の顔合わせとリモートのMTGを得て開催の運びとなりました。

みなさんも気軽に相談してみてはいかがでしょうか。

モブプログラミングの準備

当日までに準備したこと
  • メンバーの対象者選定とチーム分け
  • ワークショップの課題選定(自販機)
  • スプリントプランニングに「モブプロ研修 4時間」を組み込む。

対象者はC++エンジニア10名とRubyエンジニア3名の13名。
これを3チームに分けました。

  • C++エンジニア 5名 * 2
  • Rubyエンジニア 3名

課題は、言語が違うチームになるので共通で「自販機」としました。

当日の準備
  • 机3つと人数分の椅子
  • モニター3台
  • ホワイトボード3枚
  • 人数分の付箋とペン
  • お菓子

スケジュールとしては以下の流れで全行程4時間。

  • 15:00-15:30 Head Firstモブプログラミング
  • 15:30-15:40 ワークショップ準備
  • 15:40-16:40 モブプログラミングワークショップ 1
  • 16:40-16:50 中間ふりかえり&質疑応答&休憩
  • 16:50-17:50 モブプログラミングワークショップ 2
  • 17:50-18:20 成果共有&ふりかえり
  • 18:20-19:00 現場でのモブプログラミング

及部さんから事前に「初めてモブやると疲れるから研修おわったらそのまま帰れるようにしたほうがいいですよ」とのことで定時の19時に終わるように設定しました。

ワークショップの内容について

及部さんよりモブプロの歴史や事例を交えつつ注意点など説明いただき、その後、課題やワークショップのルールなど進行の説明があり、ワークショップの実施という流れです。

進めるにあたった以下を強く意識して実施してもらいました。

f:id:yusi:20200118020128p:plain
「HRTの原則」はアカツキでも大事にしていることです。

ルールは「テストすること」だけ。
RubyチームもC++チームも普段から単体テストは書いていたのでここは特に抵抗なく進めることができました。

ワークショップのスライドは公開の許可を頂いているのでぜひスライドを参照していただければです。

drive.google.com

モブプロ実施

f:id:yusi:20200114155635j:plain

モブプロ中は真剣に話す場面や笑顔で意見を交わす場面など見られました。時折「やったー」という声が聞こえてきます。
普段一緒に仕事しているメンバーなのでチームビルディングが必要のない分スムーズに始められた印象です。

一つのモニターを一人がタイピングして、周りに立ちながらアドバイスする姿は、障害対応しているときの姿に近いですね。一つのタスクを複数人数で取り組むときは自然とこの形になるのですね。

休憩を挟んだ2回のモブプロの時間を終え、お互いのチームの成果を報告し振り返りを実施しました。

以下はあるチームのふりかえり結果です。どのチームも「疲れた」は出ていましね(笑
f:id:yusi:20200114182827j:plain

その後、ふりかえりででた参加者からの疑問や疑念に対するクエスチョン(を、最後の及部さんからのまとめプレゼンでアンサー*1 する形となりました。
 

開催場所が社内のカフェのあるラウンジで開催したこともあり、他チームのエンジニアがフラッと見に来て興味深そうに見学していきました。そういう所から波及もしてくれるとうれしいですね。

感想

気になったことは「モビングの重要なポイント」として話された以下のところ。

f:id:yusi:20200118023948p:plain

リソース効率とフロー効率に関しては@i2keyさんの以下の資料がわかりやすいですね。

自分たちのプロジェクトを見返すとリソース効率に傾倒しているので改めてチームで話し合ってみるのもおもしろいと思いました。

またOutcomeについては最近よく話されるようになりました。
スクラムで進めているのであればPOとユーザストーリーにより担保されている部分もあるのでしょうけど、スクラムでないチームでも成果物(Output)とそれに関するOutcomeを話すのはとても有効と感じます。先日のRSGT2020でもギルドワークスの中村洋さん(@yohhatu)がその観点からの話もされていました。
speakerdeck.com

暗黙知のくだりもSECIモデルをベースに話されており、価値観としてはスクラムと通じるところがあることがわかります。

今回の悩みであったスキルトランスファーの課題にも効果があることが伺えますし、メンバーからもその点は感触を掴めたという感想がありました。

まとめ

今回、実施前はメンバーからはモブによるワークが非効率に感じていると声がありましたが、最終的には全員ポジティブな結果が返ってきました。
実施した2日後にはモブを試すチームも出てきており、小さな変化は起きている感じがします。

及部さんの資料にもありましたが「モブプログラミングを現場に導入するか どうかは正直どうでもいいことです。 」で「(分担作業とモビングを)仕事の質やチームの状況に合わせて 使い分けられる方がチームとして強い」ということが大事に思います。

分担開発(リソース効率)とモビング(フロー効率)の使い分けを柔軟に選択できるチームは強そう。

本質は、チームが生み出す価値を最大化するために何ができるか、何をすべきかをチームで考える。そのためにシンプルなコミュニケーションの機会を増やし、チームで判断し続けることが重要であることを知ることができました!

最後に

アカツキでは 一緒にハートドリブンな世界を実現するエンジニアや、組織の成長、課題解決に取り組んでくれる仲間を募集しています!

aktsk.jp

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

 

はじめまして!

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つの方法として以下の記述がありました。

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

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

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

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

最後に

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

インターン同窓会を初開催しました!

こんにちは、エンジニア採用担当の宮田です。

 

#インターン同窓会とは?


突然ですが、みなさんは「インターン同窓会」という言葉を聞いたことはありますか?
おそらく初めて聞かれる方が多いのではないでしょうか。実際に、今回の参加者からも「インターン同窓会ってなんですか?」「初めて聞きました、意味わからないっすよ笑」といった声がありました(笑)。


そもそもインターン参加目的の多くは、就職先を探すため、企業をより深く理解するため、自分の力試しのためといったようなものだと思います。しかし今回私たちが着目したのは、インターンの時間を共にした同期とのつながりです。
インターンでは濃密な時間を過ごしたとしても、全国から参加されている学生同士ではなかなか再会の機会を作ることができず、関係が希薄になってしまうことがあるのではないでしょうか。アカツキにも学生時代のインターン同期とのつながりが今にも活きているメンバーがいます。付加的な要素ではあるものの、こういったつながりをもっと世の中に増やしたい、そしてアカツキが2019年のインターンテーマとして掲げていた「成長」と「つながり」を形にできる場になることを願いながら、このイベントを開催しました。

今回はその「インターン同窓会」の様子をお届けします!

 

#サマーインターンの概要

この夏アカツキでは、エンジニアを目指す学生さん向けに就業型インターンとGAME JAMという2種類のインターンを実施しました。そして今回はそのインターンに参加した約30名のうち19名が集まってくれました。

 

▼インターンの詳細はこちら

https://aktsk.jp/recruit/intern/

▼Akatsuki GAME JAM2019開催レポートはこちら

https://hackerslab.aktsk.jp/2019/09/19/204913

  

#当日の様子

 

当日のコンテンツは下記の三部構成。

・ゲーム大会

・アカツキメンバーによる技術プレゼン

・懇親会

 

手作りで準備した同窓会をみんなが楽しんでくれるか、ドキドキしながらのスタートです!

 

<第一部:チーム対抗ゲーム大会>

Akatsuki GAME JAMの2日間で参加者が作ったゲームのうち、優勝・準優勝チームの作品と、アカツキの新卒メンバーが企画からリリースまで担当したカジュアルゲーム3種類で対戦。各ゲームでハイスコアを目指します(もちろん自分が開発したゲームはチートになってしまうので、プレイ禁止でした笑)。

 

▼チームメンバーの挑戦を見守る仲間たち

f:id:kayomiyata:20191219183849j:plain

 

▼コツを掴みながらハイスコアがどんどん更新されました

f:id:kayomiyata:20191227162131j:plain



さすがゲーム好きのみなさん、集中しているメンバーの様子を静かに見守りながらも、ハイスコア更新の際には歓声が生まれていました!

久々にあったメンバーも第一部のゲーム大会ですぐに打ち解けている様子を嬉しい気持ちで眺めていました。

 

<第二部:技術プレゼン>

 第二部はアカツキのエンジニアメンバーによる、技術プレゼンです。

エンジニアからの企画提案で見事チャンスを生み出した事例や、新規事業を軌道に乗せたメンバーによる、プロとして「やりたいことをやる」ための心得の話、VPoEによる「アカツキのエンジニア組織が大切にしていること」などをじっくり話してもらいました。

みんな、ゲーム大会の時とは打って変わって真剣な表情で聞き入っている姿が印象的でした。

▼VPoEによる技術プレゼン

f:id:kayomiyata:20191219190529j:plain

 

<第三部:懇親会>

最後はみんなで懇親会です。

インターンにメンターとして関わったメンバーや学校OBにあたるメンバーも参加し、インターン時の思い出話やその後の開発の話など、久々の再開に華を咲かせていました。

 

▼近況報告などで大いに盛り上がっていました!

f:id:kayomiyata:20191219190852j:plain

 

解散の前に学生さん同士で連絡先を交換していたりと、新たなつながりが生まれている瞬間に立ち会えたことは、運営としてとても嬉しい光景でした。

今日では多くの企業が開催しているインターンシップですが、単なる「通過点」ではなく、その後も学生さん同士つながっていける立ち位置になっていけたら、学生さんにとって就職活動がより一層濃密で楽しい時間として捉えてもらえるかもしれない。こういった機会をどんどんこれからも作っていきたいなと改めて思いました。

 

参加してくださったみなさん、本当にありがとうございました!

みんなと楽しい時間が過ごせて、とても嬉しかったです!そしてみんなのこれからの活躍が今からとても楽しみです!また必ず会いましょう!

f:id:kayomiyata:20191219191745j:plain