ID:44330さん

# 前職のチーム内状況と私の役割(時系列順) 入社後１ヶ月は新人研修に参加し、チームに配属されたのは５月からでした。私が配属したチームは同年の８月にリリースが予定されていたので、開発と本番環境の基盤はすでにある程度できている状態でした。 結局、リリースは１２月に延長されたこともあり、11月ごろまではOJTの一環でjenkins,docker周りの仕事を担当していました。 リリース間近になると、全体的に若いチームだったということもあり、先輩方は新人への指示に手が回らない状況になっていました。その時期の私は、c++で先方の会社に送るgrafanaのグラフのスクリーンショットを自動で撮影するプログラムを作成したり、jenkinsの容量を監視するスクリプトを書いたりと、自分で仕事を探しチームに貢献してきました。 ゲームのリリース後は、半数以上のエンジニアが退職した為、一人でインフラ業務を担当するようになりました。勿論一人でインフラ業務を全て行うには力不足だった為、チーム外の先輩方にも相談・確認しながらなんとか大きな問題無く、業務を遂行しました。 # サービス終了時のGKE本番環境の縮小オペレーション サービス終了に伴い、ゲームのサーバー構成を返金対応が行える最低限の構成まで縮小する必要がありました。また、そのオペレーションはメンテナンス中に行うのですが、実装の都合上メンテナンス中もAPIサーバーのダウンタイム０で行う必要がありました。 私はこの作業をメインで行わせて頂き、具体的にはKubernetesのマニフェスト作成とメンテナンス中に走らせる各種スクリプトの作成を担当しました。 私が設定した手順は、 1. 必要最低限のスペックで新規ノードプールを作成 2. 旧ノードプールに最小構成のマニフェストで各種podを再デプロイ 3. 旧ノードプールの全ノードに対してcordonを打つスクリプトを使い、新規podのデプロイを行わないようにする 4. 旧ノードプールの全ノードに対してdrainを打つスクリプトを使い、kube-systemのpodも含めてダウンタイム無しで新ノードプールへ移行する 5. 不要なリソースを削除するスクリプトを使い、マニフェストで定義されずに残り続けているリソースの削除 です。 上記の手順でメンテナンスを行う事を想定し、各種スクリプトやマニフェストを構築しました。 ダウンタイムを発生させない為の工夫として、マニフェストでmaxsurgeを設定する事で、少なくとも一台はpodが建った状態でローリングアップデートを行うようにしました。また、新ノードプールにpodを移行させる際もdrainを使い、リクエストを捌ききってからpodの移行を行えるように意識しました。 結果として、ステージング環境でのテスト、本番環境でのサーバー縮小メンテナンスも大きな問題なく実施できました。 # アップデート前の最終確認会の提案と実施 私のチームでは、プロジェクトが運用フェーズに入ったタイミングで多くのエンジニアが退職し、gitのブランチ管理を行う人が居なくなっていました。チームメンバーはどのブランチにどのバージョンのデータを入れれば良いか分からない状況が続いており、アップデート内容の設定を入れ忘れるといった初歩的なミスで緊急メンテナンスを行う回数も少なくは有りませんでした。チームとしてもこういったミスは、データワーカーの個人的なミスという扱いがされており、チームの問題としては見られていない状態でした。 私は、データワーカーに注意を促すだけではなくアップデートまでの確認フローを改善しない限り、初歩的なミスは無くならないと感じていました。そこで私が指揮を取り、ホワイトボード等を使ってどのバージョンのデータはどのブランチに入れるかの共有や、データの不備が無いかをチームメンバー全員で確認する会を実施しました。結果として緊急メンテの回数は多い時期の半分程度まで減り、先方のスケジュール変更に関しても柔軟に対応できるチームになりました。 # スキルセットについて | スキル名 | 自分のレベル感 | | ---- | ---- | | Jenkins | 基本的、及び構造的なjob作成。スレーブ作成・保守・監視。スレーブの負荷分散対応の経験。 | | Linux | Linuxへの基本的な理解。調べながらであればマシントラブルが起きた際も、どこに原因が有るか調査可能です。 | | kubernetes | マニフェストを読み理解する力は有り、既存マニフェストへの変更を加えた経験があります。要件に合わせたサーバー構成を１から構築した経験はありません。 | | Docker | 小さなアプリケーションをDockerに載せ替えた経験が幾度かあります。一からアプリケーションを作る場合もDockerコンテナを使用します。 | | Shellコマンド | 基本的なコマンドライン操作、３０行程の簡単なスクリプトの作成等が行えます。前職ではコマンドラインを使って、毎日作業を行っていました。 | | C++ | 独学ではありますが、簡単なコード作成は可能です。 | | GCE | 用途の違う複数のインスタンスの作成経験。インスタンスのトラブル対応や運用経験。 | | GKE | 簡単なトラブル対応。メンテナンス時のnodeの増減見積もり等。 | | その他GCP | 携わっていたプロジェクトがGCPヘビィだったので幾つかのサービスには簡単に触れた事があります。Dataflow, BigQuery, GCCB, GCS, FWルール等。 |

こちらの項目に関しては、技術的な内容では有りません。 ただ、私の行動原理や将来的な目標に直結する内容なので、記載しています。 # ゲーム製作部の状況と実施した事（時系列順） ## 当時のゲーム制作部について（一年生の頃） 私が所属していたゲーム制作部は入部当時30人規模のゲーム制作団体でした。 部の大きな活動目的はゲームを制作し、コンテスト等の入賞を目指すといったものでした。 活動内容は半期に一度、くじ引きで決まった５人規模のチームを６チーム作り、ゲーム製作を行うといったものでした。 最初に所属したチームはくじ引きで決めたチームだったこともあり、四ヶ月間はリーダーも決まらず、特に何も活動していないという状況でした。私が想像していたゲーム製作部とは大きくかけ離れていた活動内容だったため、この頃に組織の改革を決意しました。 ## 副部長に就任。活動方針の変更を行う（二年生の頃） 二年生では副部長に就任し、徐々に組織や活動方針についても意見ができるようになりました。 当時の部長と協力し、部内にコーディング、グラフィック、シナリオ（企画）、DTMの４つの課を設定し、部員はいずれかの課に所属してもらう形式に変更しました。 また、チーム形成に関しても、部内で数名に作りたいゲームを提案してもらい、提案者以外の部員は好きなチームに所属してもらう形にしました。 ## 部長に就任。新入生の活動方針の変更（三年生の頃） 三年生で部長に就任した私は、まず新入生獲得を意識し、一年生の活動方針を変更しました。 具体的には、一年目の前半で先輩による技術による講義を受けてもらい、後半で一年生だけのチームで簡単なゲーム製作を行なってもらうといった内容です。 ゲーム製作は面白そうだけれど、自信がないといった新入生が多いと推察し、このような方針に変更しました。 私の所属するゲーム製作部は、学部の新入生の前で部活紹介のプレエンテーションを行う機会が与えられていた為、この活動内容と組織体制について説明し、その結果、その日のうちに100名程の入部希望者を獲得しました。 ## 200人規模の団体になってから（三年生の頃） １週間で200人規模の団体になってからは、当時の役職である部長、副部長、会計だけでは様々な事務作業が全く追いつかなくなりました。そこで、運営課というゲーム製作ではなく組織づくりに注力する課を設定し、部としての知名度の拡大や様々なイベント事に対応してもらう事にしました。この運営課の設定は、私が引退した後も大規模団体としての活動を維持してもらうように取り組んだのですが、結果として部長の任期を終了してから６年後の今も100人以上の大規模団体を維持することができています。 また、TOKYO GAME SHOWやBitSummitなどに出展、他にも株式会社きんでん、Unity社、河合塾、Project -GIER-との共同プロジェクトの実施など、多くの活動の実施も致しました。 # 組織づくりで意識した事 ## 権力と役割の分割 200人規模の団体になり、運営課を作るに当たって意識した事です。 私が設定した運営課は具体的には５つの課に別れており、それぞれにリーダー・副リーダーを設定しました。 それぞれの課には活動目的を設定し、月に１度各課のリーダー、副リーダー、部長、副部長による10数名規模の会議を実施していました。 * ***総務課*** : 部員に関する管理、部内の書籍や部室の環境管理 * ***システム課*** : 外部向けのHP管理、部内サーバー、イベントで使う作品紹介ランチャーの製作・管理 * ***渉外課*** : 主に外部会社との連携プロジェクトの担当 * ***渉内課*** : 主に部内イベントの担当 * ***広報課*** : 外部向けHPやブログのページ製作、公式Twitterの管理 このように役割を分割することにより、部として行うべき事を誰が行うべきかということを明確にしました。 また、部活の活動方針を部長だけでなく、この５課のリーダーを含めた会議で決める事により、部内の権力（発言力）が分散され、部長一人の意見で全体の方針が決まってしまう事を防ぎました。 自分が引退した後、６年間もの間大規模団体としての活動を継続できたのはこの仕組みがうまく機能している結果だと考えています。 ## 部員を巻き込んだ組織づくり 組織改革を行うに当たって、最初の各課のリーダーの選定はとても難しいものでした。 初めは公平性を意識し、公募で各課のリーダーを募ったのですが全く手が挙がりませんでした。 勿論、全員が興味が無かった訳ではなく、「興味はあるが、自信がない」と言った意見が多数でした。 そこで、各課のリーダーを指名性に変更し、私が一人一人交渉する形にしました。 私は、日頃から部員一人一人と話す事を意識しており、誰がどの役割に適しているかに関しては選定できていました。ただ、彼らには無理矢理決められたリーダーとしてではなく、前向きにリーダーとしての仕事に取り組んで欲しいと考えていた為、一人一人交渉する上で「何故あなたを選んだのか」「運営としての仕事のやりがいやメリット」「私が考えるゲーム部の将来像と行って欲しい役割」について真剣に話し合いました。 結果としてほとんどのメンバーが交渉に応じてくれ、リーダーになった後も組織づくりに積極的に貢献してくれました。 ## コミュニティ形成を意識した組織づくり 新入生歓迎で100人以上の新入生を獲得した後、如何にその新入生を部に定着させるかという事を第一に考えました。私は、学生が所属したい組織の条件として楽しく学生生活を送れるコミュニティが存在する事だと考えていた為、コミュニティ形成を重要視した組織づくりを目指しました。 具体的に行った取り組みとして、当時私の学校ではTwitterの利用者が多かった為、部内でもTwitterを流行らせ、活動日以外も学生生活を一緒に行う仲間として交流してもらうように図りました。 また、新入生歓迎イベントとして、学内の宿泊施設をほとんど貸し切って泊まり込みで交流するイベントを実施し、そこでも積極的にTwitterアカウントの交換などを促しました。 結果として、１年間所属してくれた新入生は約160名中90人程となりました。50人は離脱してしまったものの、大規模団体として今後も活動を行っていく上で十分な人数だったので良い結果だと受け止めています。 私が部長の代の後輩達は大学を卒業後それぞれの道を歩むことになりましたが、今でもTwitterを通じて繋がっている為、彼らの人生に少なからず良い影響を残せたのではないかと考えています。