【ゴールデンウィーク営業のお知らせ】
2025年4月29日(火)～2025年5月6日（火）の期間を休業とさせていただきます。
※4月30日（水）、5月1日(木)、2日(金)は通常営業いたします。
※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。
10万人以上が恒常的に利用するサービスを1から作り上げたい
自分の手で世の中を面白く変化させたいから
各人が個別に割り振られたタスクを実施するスクラムっぽいウォーターフォール開発から、チームでタスクに取り組むスクラム開発へ移行。
インフラコスト、保守コストが高くなっていたAzure上で構築された既存システムを、システム構成を見直してAWSに移行するプロジェクト。
自社プロダクトの持つ各種データを集め、データドリブンな意思決定ができる会社にするための基盤となる、Data Management Platform（DMP）を作成するプロジェクト。
直近の目標は以下のデータを収集し、アナリストが分析可能な状態にすること。
プロジェクト要員は11名で、メンバーの役割は分析と開発で半々ほど。
サーバサイドエンジニアの1メンバーとしてプロジェクトに入り、以下を担当してきた。
私がプロジェクトに参画したタイミングでは、DMPをなんのために作成するのかが定まっていない状態であり、リーダ含め、各人の頭の中にのみやりたいことがある状況で、私がやるべきことすらない状態だった。
そこで、スクラム開発で利用するインセプションデッキの説明をチームに行い、チームでインセプションデッキを作成していくアクションを取ることで、定まっていなかった目標の明文化と、チームでの認識合わせを同時に行った。
その後、プロダクトバックログのテンプレートを作成し、チームに説明、運用サポートを行って、直近のやるべき作業を見える化した。
リーダがメンバーをサポートできておらず、各人が思い思いの作業をしており、チームの体をなしていない状態だったため、ここでもスクラムの手法を借りつつ、以下のように改善していった。
各メンバーの状況共有のため、デイリースクラムを実施した。
これによりタスクの抱え込みや、作業で詰まっているところが発見しやすくなった。
また、デイリースクラムのファシリテータをメンバーでローテーションすることで、チームへの参加意識を持って貰えるように工夫した。
そして、良くも悪くもチームが何の目標に向かって作業しているのかが不明確であることに気付くメンバーが出てくるようになった。
DMPプロジェクトのメンバーは、以下のような様々なバックグラウンドを持つ集まりで構成されたチームだったため、プロダクトバックログを利用したスクラムのやり方だと、作業の進め方・優先度を統一するのが難しかった。
また、同じ作業チームとして動くと意思決定が遅く、プロジェクトが前進しなかったため、分析と開発でチームを分け、それぞれで適した業務実施方法を行うようにした。
各チームはリーダ間で連携し、互いの進捗はスプリントレビューという形で週末にメンバーで共有し合うことで、互いの作業内容に認識齟齬が出ないようにした。
報告を聞いているとコードレビューが行われていなかったので、
GitHubのプルリクエストの仕組みを説明しつつ、開発からデプロイまでの開発フローを作成・説明し、コードをチームのものにできるように取り組んだ。
また、データレイク開発中に採用したエンジニアが、開発業務にスムーズに入れるように、毎週1on1を実施し、業務中ではフォローがおざなりになりがちな、気になることや業務上の不安点、キャリアプランへのサポートを行った。
開発チームのリーダが兼務の業務で忙しく、プロジェクトの作業がほぼできない状態となっており、プロジェクトが進まなかったため、開発済みのシステムを保守するチームと、データレイクを基礎としたデータプラットフォームを作っていくチームに更に分け、私とディレクターでデータレイクから作っていくことにした。
当初GCPを想定してDMPのシステムが作られていたが、データを集める場合はAWSのS3が都合が良かったため、収集元データのあるオンプレミスとAWS、分析基盤を予定しているGCPを考慮して、データレイク、DWH、データマートのシステム構成を作成した。
極力開発工数と管理費を抑えたデータレイクの管理システムをAWSに用意するため、以下の工夫を行った。
数百GBのデータをOracleからデイリーで収集するため、Embulkを利用したシステムをPythonで構築した。
作成後、試しにEC2のt2.mediumで70Gほどのデータ処理を実施したところ、1日では処理が終わらない試算が出た。
そこで、AWS Batchが利用できるよう、システムをコンテナ化し、更にジョブを並列で実施できるようシステムを書き換え、上記処理が2,3分で終わる状態を作った。
旧年来運用されてきた外注開発によるECモールのリプレイスと内製化を行うプロジェクトで、実働メンバー6名によるスクラム開発を行った。
サーバサイドの開発メンバーとして参加し、以下を担当した。
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
チームが開発するプロダクト
プロダクトが常に体験可能で、プロダクトの提供する価値について細かくレビュー可能になっており、
プロダクトに対して必要なものが作られている状態。
まずは「他者がレビュー可能なものを、細かい粒度で作る」という意識を、メンバーに持ってもらう必要があると考えた。
そこでタスクを上げる際は、これは誰が求めていて、タスクが完了するとどういうことができるようになるのか、何ができていたらこのタスクは完了なのかを合わせて書くように指示し、記載の仕方をフォローしながら、全員でタスク出しを行った。
タスクを上げていると、1週間のような単位では開発が終わらないものが出てきたが、同時に上げていた完了の条件で分解して確認できるものがあれば、その粒度でタスクを分割し、短い期間で開発が行えるように工夫した。
こうしたことで、たとえ考慮していなかった問題が発生しても、それが判明するタイミングも早く、作業の大幅な手戻りや、問題の抱え込みによる作業進捗の深刻化は起きなかった。
そして、細かい粒度で作る意識を持ち、それを実行していったことで、開発メンバーはプロダクトが着実にできていく体験を得ることができ、チームとして高いモチベーションで作業することができた。
一方で、プロダクトが実現する価値に直接は関係しない、CI/CD環境の整備や開発ルールの制定も、同じタスクとして行い、プロダクトがレビュー可能であるために持つべき品質が保持されるようにアクションを起こした。
エンジニア社員とその個人目標
エンジニア社員が日々の業務の中で、自分が取り組むべき目標を持ち、そのための行動をし続けることで、
結果として会社にとって価値のある人材になっている状態。
まずは型にはめる必要があると考え、個人目標設定という制度を作り、以下のようなアクションを実施することにした。
今後、1ヶ月 or 3ヶ月・1年・3年・5年で、仕事、プライベートにおいて、どうなっていたいか、どういうことをしたいか、何をしなければいけないかを書き出してもらう。
以下の各要素で、私から提示した内容について、今自分がどの程度到達できているかを項目ごとに振り返り、どういった状態なのかを記載してもらう。
事前に各自が実施したキャリアプランも合わせ、今必要な目標を設定してもらう。
設定する際は以下に注意してもらった。
1回30分の1on1を隔週で実施し、自らの目標に対して、自らがすべきアクションをメンバー自身で決めれるようにコーチングする。
1on1では私から報連相を望むようなことはしないようにした。
1on1ではフィードバックを返さないので、別途私からメンバーの行動についてフィードバックを行う時間を四半期に一回用意し、それを元に次の四半期でどういった行動を取るかを再計画してもらう。
現状、評価制度がないため、人事担当にメンバーの状況を報告し、人事担当が期待しているパフォーマンスとのギャップについて話し合う時間も作った。
ここでの内容を必要に応じてメンバーの次の目標設定に内容を反映させることにしている。
達成できたゴール、出来なかったゴールについて振り返ってもらい、自分の目指すキャリア・エンジニア像に、どこまで近づけたかを考えてもらう。
そして、次の半期の個人目標を立ててもらう。
1on1ではコーチングを中心としてメンバーに向き合っていたが、メンバーによっては、自分の考えを話すことに怯えがあったり、自分の問題に向き合えていない場合があったので、やり方には固執しないようにした。
例えば、怯えがある場合は、一度個人の考えが入らない、業務的な内容を話してもらい、そこから話せるところはどこなのかを探っていき、段々と話せる内容を増やしてもらうなどし、
向き合えていないメンバーの場合は、話題の事象に対して、自分がどう行動すると客観的に見て良く捉えられるかを話してもらうなどして、それぞれに目標を立ててもらった。
そうするとやはりメンバーごとに向き合い方を変えなければいけないため、
1on1のスケジュールは、連続的にはせず、日に多くても3人までとするように工夫をした。
こうすると、私も事前に考えを整理したり、1on1後には内容を整理し、落ち着いて次のメンバーに向き合えた。
TypeScriptでNext.jsとNest.jsを使ったアプリケーションの構築技術と、それらを低コストで運用するシステム構築の方法。
プログラミングで達成したい目的に対する回答を持つメンバーが、気軽に話せるポジションにいて、目的を達成するまでの指定の期間があり、インフラ関連のシステム構築が自分の手で行なえ、一日を自分でスケジューリングでき、割り込みが入らず、HHKBが使える環境。