ID:3382さん

少数のAndroidチーム

- メンバーの開発のモチベーションを上げる. - メンバーの技術力の底上げ.

開発以外の業務に時間を取られていることがヒアリングや,業務を見ていてわかった. 開発業務以外の仕事を取り取り除き,メンバーが開発に集中できる環境づくりを行った. 得に以下の項目で無駄が多かった. - 定期リリース作業 - クラッシュ率の確認 - 仕様ドキュメントづくりにので 解決策は特に工夫はなく - 必要な作業のみに洗い出して,最低限にする. - できる限り作業は自動化する. 実行後は,チームメンバーのモチベーションが上がったかどうかはわからないが, 定期リリース作業などは半日かかっていた作業を1時間で終わるようになった. 定期リリース作業が小さくなったので,週2のリリースが週1のリリースに対応ができるようになった. 定期リリース作業が増えたので本末転倒かと思ったが,リリース間隔が詰まったおかげで, 今回のリリースに間に合わなくても,来週リリースしようなどの心の余裕は生まれた. (今までは,今回を逃すと次は2週間後になるのでなり,無理やりリリースに間に合わせることがあった.) --- 技術力の底上げは,メンバー間で定期的に勉強会を行った. メンバーに現像のヒアリングをしたところ. 新卒で入っているメンバーが多いため,以下の声が多かった. - 何を勉強したらいいかわからない メンバー以外の書いたコードやアーキテクチャに触れることは良い刺激になることを 自分の過去の経験からわかっていたので,自分たちのサービスをもっと知りながら いろいろなコードを読める以下の議題について定期的に勉強会を行った. - プロダクションで使っているライブラリについて - モダン環境と担当サービスとの乖離状況について 勉強会以外にも自走して調べるメンバーができたりしたので,好評だったと思う. あとは,メンバー間で自分たちのサービスのアーキテクチャをもっとこうしたいという意見が出るようになった.

スタートアップでの開発チームマネージメント

- クライアントワークを行う会社で、複数のデプロイチームの作成を考えた開発組織の構成 - メンバーのピープルマネージメント - メンバーの評価管理 - 開発組織の効率化のためのドキュメントワークの文化の作成

開発組織の構成を考えるために、会社のKPIからブレイクダウンしてデプロイチームをどれだけ作る必要があるか考えて目標を決めました。 その次に1デプロイチームを構成するためにどの技術スキルを持つポジションが何人必要か洗い出しを行い、自分のチームでは足りないJobDescriptionを作成してHRチームと連携をしてスカウトや面談、面接を行った。 メンバーとのピープルマネージメントでは、1on1を週1で行い PJ の状況や問題点、メンバーの興味・関心事をキャッチアップして働く環境を整えていました。 担当 PJ 以外の状況のキャッチアップ方法や技術状況を気になるメンバーが多かったので、ドキュメントワークや口頭で補足した理を行った。 ドキュメントにすることで管理コストがかかるようになったが、自分が各 PJ の状況把握にもなるため行っていた。

エンジニアチームの部長職

新規事業の立ち上げ

人とモノのリソース管理からアウトプットを明確にする予実管理を行うために、メンバー1人あたりの単価を定め初期開発額と、投資回収計画を明確にして上長とすり合わせをして開発ロードマップを作成をしました。 また、何年で投資額を回収できるかを考えると、サービスの契約単価も明確になり、サービスの品質の目線も明確になりメンバーと目標を合わせることができモチベーションを上げることもできました。 ただ予実管理に囚われすぎると、プロダクトの価値を最大化させることはできないので柔軟に現状を捉えて方向を変えられるようにしました。そのためには上長やステークホルダー、メンバーと良好な関係を気づいてプロジェクトの状況を細かくアップデートさせていくことを意識しました。