あべ

自社のメイン商材である特定業界向けの会員、売り上げ分析パッケージの保守開発フェーズのマネジメントを担当しています(現在進行形)。 各営業担当が個別に持ち込むカスタマイズ案件のスケジュール整理、希望納期に対する調整など、開発と他チームのやり取りを整理してチームが取り組むことを明確にしました。また、やり取り先のチームで部門内の案件を把握していないことが発覚したので、こちらが受け付けている案件のリストとつき合わせて定期的に情報共有する場を設けるようにして、開発チームが要求するインプットの品質に関する依頼を展開してもらえるようにもしました。 また、パッケージの専門性が高いこともあり、チームは開発と受け入れ・リリースがある程度分業化せざるを得ない状況ですが、このスピードがアンバランス(開発が圧倒的に早く、受け入れに時間がかかる)となっているため、このアンバランスを解消することに力を入れています。具体的には、開発チームで担保できることを増やすためのナレッジ整理などです。 チームのマネジメントとしては、情報がなるべくオープンに、可視化されるように気を配り、redmineのチケットフローやカスタムフィールドを利用した可視化のサポート、VSTSのカンバン導入とルール整備などに取り組んでいます。また、会議体や目的別チャットルーム整備を行い、チームのコミュニケーションが円滑になるよう配慮しました。 あわせて、派生プロダクトの開発プロジェクトも立ち上がっており、そのマネジメントと並行して保守開発への影響が内容なロードマップの策定と調整を行なっています。

別プロジェクトで蓄積したデータベースを使って会社の新たなビジネスモデルを構築するためにBtoCサービスを展開するプロジェクトです。プロダクトの企画から開発チームの立ち上げ、要件のロードマップ作成、開発プロセスのサポート、コードレビュー、営業企画との営業プランの検討に携わっています。企画面では、Analyticsなどを使い、ペルソナを充実させた上でUXデザイナとユーザストーリーについて考えたり、ユーザストーリーをマッピングして要件を書いています。要件のロードマップでは、BtoCサービスに会社として初めて関わることもあって、スピード感の違いやユーザ動向及びリリースに関する考え方の違いなどで調整が難しくなることもありますが、丁寧に説明をして理解を得た上で、リスクと責任を取る姿勢を見せることで推進してきました。 会社として初めてのBtoCサービス展開なので、ペルソナの構築やサービスのあるべき姿など私自身を含めて戸惑うことがありましたが、企画段階から着実な学習を繰り返し、リリースを経るごとに学習サイクルが早くなっています。MVPとしてのリリース後に得た新たな発見を生かすためのリニューアルも動き始めており、同じ役割で参加しています。 また、アーキテクチャの選定についてアーキテクトと一緒に行っています。webアプリケーション、バッチアプリケーションに求められる可用性の違いを考慮してそれぞれdockerにデプロイしてElasticBeanstalkでアプリケーションを構築しました。リリースにおける安全性を考慮して、ElasticBeanstalkの最小インスタンス数を調整してブルーグリーンデプロイメントを手順に組み込むなど、アプリケーション構築については開発と運用を考慮して積極的に関わっています。 開発プロセスはカンバンを採用し、開発リリースと計画は2週間に一度というサイクルにしました。これにより、見積もりの精度や状況などを可視化して開発のプロジェクト進行をコントロールしています。

POSなどのシステムを構築しているT社のOEMアプリケーション開発チームのマネジメントを行いました。私が参加するまでは炎上していたプロジェクトで、社内メンバーの疲弊が激しく、上司への信頼感がない状態からのスタートでした。しかし、メンバーの自力はあり、またメンバーどうしの結束は炎上状態を経て硬くなっていることを感じたので、自律した強いチームを目指すことができる、という確信はありました。 まず、権限を委譲してもらい、社外メンバーで態度などの悪さから炎上状態をひどくしていたチームの契約を解除し、社内メンバーのみで開発を行う方針を決定。それから、一人ひとり面談をした上で方針について説明をしました。トップダウンで押し付けるよりは、自分たちで決定し、プロセスを作っていくことをサポートすることに専念し、ふりかえりの徹底のみトップダウンで行いました。わからない部分については、サンプルを作ってサポートするなど、チームの学習を止めないことを最も重要視しました。 その結果、自動化されたテストがなかったチームが、テストを書くようになっています。また、開発プロセスについても受託でありながらカンバンのようなプロセスを運用することができるようになりました。そして、その成果をチーム外に伝えて、会社として効果を出すことを目的としたアプローチが自分たちの意思でできるようになりました。 現状のチームは炎上することもなくなり、メンバーも成長しながら受託でも良い仕事ができていると思っています。

教育系サービス会社の各種データ基盤の連携を行うための基盤構築プロジェクトです。アーキテクトチームのメンバーとして参加しました。基盤としてDatastageを利用するため、各データ連携先プロジェクトにおける利用が促進されるようにツール類やルールの整備などを行うのが主なミッションです。 飛び入りタスクがよく発生するチームで、チーム外も含めたプロジェクトの総参加人数が膨大になるため、チーム内のタスク整理と改善サイクルを回すことを目的にリーダーと相談してふりかえりを導入しました。ふりかえりのファシリテーションは私が行って、チーム内の改善は進めることができましたが、外にまで波及させることができませんでした。 また、テストの自動化をするためのツールベースなどをs2unitなどを作って提供しましたが、ツールの出来が十分ではなかったことと、自動化そのもののメリットを感じてもらえなかったこともあって、広めることができませんでした。テストの自動化を広めることについてのアプローチを考えてから取り組むべきでした。