| 年 | 月 | 職歴 |
|---|---|---|
| _ | _ | 現在 |
| 2020 | 12 | 株式会社チアドライブ 業務委託として参画（副業） |
| 2020 | 11 | 株式会社ドワンゴ マネージャー |
| 2019 | 11 | 株式会社ドワンゴ リーダー |
| 2016 | 4 | 株式会社ドワンゴ 入社 |
大学受験やプログラミングなど様々なコンテンツで学習できるアプリケーションを開発。 プロジェクト内で 3 つのポジションを経験している。
- 2020 年 - 現在 フロントエンドセクションマネージャー
- 2019 年 - 2020 年 スマートフォンアプリグループリーダー
- 2016 年 - 2019 年 Android アプリエンジニア
大きく、以下の 2 つをマネジメントする役職。
- PC Web アプリ開発チーム, iOS アプリ開発チーム, Android アプリ開発チームの 3 つのチームのピープルマネジメント
- チームが取り組む案件のプロジェクトマネジメント
組織改編など様々な事情によりマネジメントレイヤーの人員が半分以上入れ替わった。 そのような組織が不安定な状態でマネージャーになった。
自分が潰れないように上長との 2on1 やマネージャーレイヤーでのコミュニケーションパスの拡充により相談窓口を確保した。 メンバー向けには当初は各チームのデイリーミーティングに参加したり 1on1 を設定することで、組織体制が変わっても自分または誰かに相談できる体制を作った。 組織が安定化してからはミーティングを整理してチームに任せ、時間運用の効率化を図った。
それまで開発者が手弁当でテストを行っていた。 しかし、担当者によってテスト実施方法やクオリティがまちまちになってしまう問題があった。
アプリケーションの機能の増加や責任の大きさを考えると、品質に関して専門に考えるチームが必要と考えられた。 QA チームの新設によって横串で品質を保証できる組織体制を作っている。 チームの採用や運営にも関わった。 結果、権限移譲して他メンバーにチームを任せられる程度にチームを拡大・安定化できた。
事業の成長に合わせて正社員の採用が組織課題となった。 現在の事業を支え、将来の組織拡大にも耐えられるように組織の拡大が重要となる。
当初、事業・組織としての明文化されたミッションがなく、メンバー・求職者に訴求できる組織活動・採用活動の軸がなかった。 この明文化にあたって、もともとチーム内での意識統一のために掲げていたミッションを事業・組織のミッションとして提案し、議論の末に正式に決定した。 現在では「未来の当たり前の教育をつくる」というミッションは組織内に浸透している。 また、このミッションを軸にロードマップへの落とし込んだり、直近の業務との整合性をチームに定期的に伝えたりすることで、陳腐化しないように努めている。
新卒・中途の面接やカジュアル面談を担当している。 面接ノウハウの文書化や共有、構造化面接の導入によって、選考プロセスを標準化している。
結果、実施コストを削減するとともに、他のメンバーでも対応しやすくなった。 また、チーム文化としても面接・面談に参加するよう奨励している。
採用活動をチーム全体の課題とするため、採用定例を週次で開催するようにした。 解決策1 での選考プロセス標準化に際してチームで話し合ったり、課題について話し合う場として機能している。
解決策2 の採用定例の中での提案の1つを発端として、サービスのプレゼンス向上を目的とした開発者ブログの定期的な更新をチームの目標とした。 自身も開発者ブログの運用に関わり、記事も執筆している（例）。 月2回更新、1年以上の技術ブログの継続している。 結果、直接的にエンジニア採用に繋がって結果を残せた他、直接的に技術ブログから応募しないまでも、技術ブログが内定承諾の判断材料の1つになるなど、成果を残すことができた。
代表的な記事は次の通り。
- 2023/06 「 ZEN大学 (仮称) (設置構想中) 」 開学に向けエンジニア募集中！
- 2022/01 技術ブログを（だいたい）1年続けた背景と成果
- 2021/06 ドワンゴ教育事業 エンジニア採用中です！
他の開発者ブログの記事は Wantedly を参照のこと。
採用活動と並行して、社内の評価指針を具体化した目標指針マトリクスを作成、部内での共通指針として策定した。 エンジニア採用ができたとしても、中長期的に継続してモチベーションを保つことができなければ、離職してしまう。 モチベーションをもって日々の業務にあたれるように、目標設定の際の目安となるマトリクスを作成した。
結果、メンバーとの目標設定の際のコミュニケーションが円滑になり、新しく入ったメンバーからも目標を設定しやすいという感想をもらった。 メンバーを評価する際にも、よりノイズが少なく説明しやすい評価をできるようになり、負担の大きかった評価業務の作業量を削減できた。
2021年秋のマネージャー就任時点で社員5名程度だった組織を、2023年夏時点で社員20名程度に拡大しても運用することが可能となった。
採用活動の成果もあり、組織が拡大したため、それに伴って業務も増えた。 マネージャーとして、円滑に組織を運営していくための改善に取り組んだ。
組織が拡大し、様々なプロジェクトが並行するようになった。 組織規模が小さいときは私が主なプロジェクトのプロジェクトマネジメントを担当できたが、プロジェクトが増えるとそれも難しくなった。
プロジェクトマネジメントを委譲できるように、次のことに取組んだ。
- この組織におけるプロジェクトマネジメントの定型化（資料の雛形の作成、組織内における合意形成）
- プロジェクトマネジメントの概要・ハウツーを書いた資料を作成
- プロジェクトマネジメントの希望者を募集
- プロジェクトマネジメント希望者に対してオンボーディングを実施、力量に応じて適度にサポート
結果、より多くのプロジェクトに対してプロジェクトマネージャーをアサインできるようになった。
Android アプリ開発チームと iOS アプリ開発チーム、2 つのチームを束ねるリーダー。
Apple の審査ガイドライン変更対応のため、 iOS ネイティブと Android の WeView での Sign in with Apple 実装が必要となった。
OIDC 仕様を読んだり自分で Sign in with Apple の試験実装アプリを作ったりして理解を深めながら開発した。
iOS アプリ未経験だったため、開発のためにキャッチアップが必要となった。
業務に加えてプライベートでも iOS アプリを試作し、iOS アプリ作成の大まかな概要を掴んだ。 iOS は RxSwift を用いて開発していたため、Android の Rx 経験を活かしてレビューできた。
ビルドやリリース作業などの工程を経験し、iOS に関してもサポート程度であれば可能なスキルを身に着けた。
アプリ立ち上げ後に参画。
最初は Android 初心者から始まる。 経験を積むにつれて、徐々にコアメンバー・唯一のフルコミット開発者となる。
「挙手イベント」とは、授業における「先生の指名 → 生徒の挙手 → 生徒の回答」という一連の流れをアプリ上で再現する機能。
「挙手イベント」の実現のために 1 台の REST API サーバーと 2 台の WebSocket サーバー計 3 台のサーバーと非同期に通信しながらイベントを進行する必要があった。
机上で処理の流れを整理した後に、 Rx ストリームとして実装した。
国語科目において縦書きで文章や問題を表示する機能。
画面回転や、横画面での縦スワイプ ViewPager を実装した。
当初アプリは Java で記述されていたが、次のような課題があった。
- Optional を導入していたがプロジェクト全体で一貫できておらず、 Null Pointer Exception に悩まされていた。また、どちらにしても Java の言語的な限界で Optional 自体の null 安全性を考慮できなかった。
- Rx をヘビーに利用していたが、ラムダ式の利用には Retrolamda の利用が必要だった。
プライベートで利用してとても快適だったことから、 Android 公式言語になる以前の 2017 年 に Kotlin を導入した。 null 安全性や、 RxJava をはじめとするラムダ式の記述の簡潔さ、data class によるモデル記述といった多くのメリットを得ることができた。 Kotlin のコード規約の和訳 などを通して、Kotlin の利用方法をチームに周知した。 今となっては Kotlin は Android 公式言語となり、 Android 開発のデファクトスタンダードとなったためよい選択だった。 導入後は、開発で着手したところを改修する方針で少しずつ移行を進めた。 私がメインのコミッターであるときには完遂できなかったが、他メンバーが引き継いでくれたことで完了した。
もともとのアーキテクチャは MVP ながらも Presenter に全てのロジックが集中する Fat Presenter になってしまっていた。 Fat Presenter の中では Rx ストリームが絡み合っており、全体の見通しが悪く変更容易性を損なっていた。
既存のアーキテクチャからの移行のしやすさも勘案した RxJava を利用した MVVM 風の独自アーキテクチャに更新した。 （当時はまだ Android Architecture Component がなかった）。 このアーキテクチャによって、Fat Presenter に集中していたロジックを個別のテスタブルなファイルに切り出すことが可能となった。 テストがついていない 1000 行を超えるファイルを解体し、テスト付きのロジックとして切り出した。 見積もりの際にもロジック=作業単位=PR 単位として切り出すことが可能となり、見積もりもしやすくなった。 導入後は、開発で着手したところを改修する方針で少しずつ移行を進めた。 こちらも私がメインのコミッターであるときには完遂できなかったが、他メンバーが引き継いでくれたことで完了した。
車の運転を支援するアプリの開発。 React Native を利用したクロスプラットフォームアプリである。 リリース前のタイミングで Android 固有の問題を主に担当するエンジニアとして参画。
月ごとの作業が約 20 時間、作業時間帯は不定期である。 この環境を鑑みて、以下を意識して立ち回っている。
- レバレッジの効く作業
- 他の人をブロックしない作業
限られた時間では、どうしても各機能実装のような作業でバリューを出すのは難しい。 それよりも、チーム全体の作業効率を高めるようなレバレッジの効く作業に意識して取り組んでいる。
また、作業時間もバラバラのため、自分が作業のブロック要因になると全体が止まってしまう。 Android 固有の問題でリリースできないなどあれば優先的に対応している。
プロジェクト参画当初は、そもそも Android でビルドできないという状況になってしまっていた。 それを修正するのは当たり前として、再発防止策として Bitrise と fastlane を用いた CI 環境を整え、PR の段階で検知するようにした。
個人的にも不慣れな JavaScript で書かれているため、コードの妥当性を担保するために lint/format を整備した。 husky を使って ESLint/Prettier をコミット時に自動で走らせるようにした。 また、Danger で ESLint のエラーを PR にコメントする設定を追加した。
| 種別 | 詳細 |
|---|---|
| 言語 | Kotlin, Java |
| ライブラリ | Jetpack, RxJava, OkHttp, Glide, Mockito |
| アーキテクチャ | クリーンアーキテクチャと MVVM をベースにした独自アーキテクチャ |
| CI/CD | Bitrise, Jenkins, DeployGate |
| 種別 | 詳細 |
|---|---|
| バージョン管理 | Git, GitHub |
| タスク管理 | Jira |
| ドキュメンテーション | Confluence, Google Docs, Google スプレッドシート |
| コミュニケーション | Slack ( Slack Bot の作成と運用による業務効率化を含む）, Google Meet |
- 基本情報技術者資格
- 応用情報技術者資格