もうりーにょ

## プロダクト概要 企業人事をターゲットにした学習管理システム。 研修運営に関わるデータを一元管理することで業務効率化を促進することと、教育事業を行っている会社のノウハウを活用したサクセス支援による社員の学びの促進を主なメッセージとしている。 プロダクトとしては「誰でも使える使いやすいUI/ UX」を強みにしている。 ## プロジェクトの特徴 - 正社員、業務委託、外部委託先企業など**多様な雇用形態のメンバーが全員正社員のような距離感で仕事を進めている** - 開発サイドにもプロダクトや事業への理解が求められ、**ビジネスサイドとのMTGにエンジニア全員が参画している** - 1スプリントを1週間とするアジャイル開発 - チームでのタスクの進め方の決定やチームMTGの運営などは**スクラムメンバーが主体となってやり方を模索し方針を決定している** ## チームでの役割 - スクラムチームにおいて、バックエンドおよびフロントエンドの開発 - 社内メンバーのオンボーディングおよび育成 - 社内営業サイドへの現場状況の共有による、アサインの適正化 - 具体的な業務としては以下の通り - 要件定義・設計関連 - POとの要件のすり合わせ - デザイナー・POとのデザインの相談 - 実装関連 - Ant Designを用いた画面開発 - React Hook Formを使ったフォームの開発 - nice-modal-reactを使ったモーダルの開発 - Apollo Client + GraphQL Rubyを使ったAPIの開発 - Sidekiqとruby-auth0を用いた非同期処理でのユーザー登録処理の開発 - スクラムチームのチームビルディング関連 - OKRを用いたチーム目標の決定と目標達成までの開発・ドキュメントの作成 - スクラムチームを跨いだ開発メンバー全体でのMTGのアジェンダ管理・ファシリテーション - 社内のチームビルディング関連 - 社内メンバーのオンボーディングナレッジの整備 - 社内メンバーとの1on1による課題の抽出とネクストアクションの決定 - 社内メンバーMTGでの方針の共有 - アサイン管理者への現場状況の共有 ## チームの課題と工夫したこと `課題1` 新メンバーのアサインにおいて、顧客のオーダーとのミスマッチが発生した。 ### 工夫したこと アサイン前のコミュニケーション不足がミスマッチの原因にあると判断し、**アサイン管理者とのコミュニケーション量を増やした。**具体的には以下の4つを行なった・ - 月一回以上アサイン管理者に案件状況の共有を行う - どんな開発体制で、どんな人がアサインに的確なのかが伝わるようにする - 上長に週次で案件状況を報告するMTGを行う - 現役メンバーと話し合い、どんな人がアサインに的確かやどういうオンボーディングをすれば案件にキャッチアップできるかの認識合わせとナレッジ整備を行う - アサイン管理者が顧客とコミュニケーションをとるタイミングで必ず自分にも話した内容を共有していただくようMTGを設定する ### 取り組みの成果 一度はメンバーのアサインに関して顧客から厳しいご意見をいただいたが、その後2名新メンバーのアサインの発注をいただくことができた。新メンバーの二人joinしてからも顧客からポジティブなFBをいただくことができた。 `課題2` 経験の浅いメンバーがキャッチアップに苦戦していた ### 工夫したこと - **モブプロ・ペアプロを積極的に活用した。具体的には以下の手順で段階的にメンバーが一人で業務をこなせるようにサポートした** 1. タスクに着手する前にメンバーがどこまで作業内容をイメージできているかを確認する 2. 何をどう進めていいかわからない場合、経験あるメンバーに画面共有しつつ思考手順・作業手順を説明しながら実装していただく 3. 2で対応したタスクと似たタスクが発生した際に、経験の浅いメンバーに対応していただく。その際経験あるメンバーと通話しながら作業を進め、困ったことがあればいつでも質問できるようにしていただく 4. 2, 3で学んだことを経験の浅いメンバーにドキュメントに整理していただき、内容を経験あるメンバーが確認する 5. 2~4を繰り返し、慣れてきたタイミングで一人でタスクを担当してもらうようにする - 実装内容をメンバー個々人で考えるのではなく、**タスクに着手する前にチーム全員でタスクごとに必要な修正や作るべきファイルについて議論を実施。**内容をコードコメントとして残し、PR上でいつでも確認できるようにした。 ### 取り組みの成果 - GraphQL未経験、React経験1年程度のメンバーがモーダルからmutationを実行するタスクを経験あるメンバーのサポートなしに対応できるようになった

## プロダクト概要 オフィスワークで「いつ・誰が・どこで・何をしているのか」を明確化することでオフィスでの快適で効率の良い働き方を実現するSaaS。 機能としては、映画館や新幹線のような座席管理ツールとGoogleカレンダーのようなカレンダーツールを組み合わせたようなもの。 ## プロジェクトの特徴 - 請負契約でウォーターフォールで開発 - 社内で初の大型請負案件 ## チームでの役割 - 画面設計・DB設計 - デザイナーとのデザイン調整 - 顧客との仕様調整 - バックエンドおよびフロントエンドの開発 - 下位エンジニアのサポート - インフラの保守、運用 - 具体的な業務としては以下の通り - 要件定義・設計関連 - 顧客との要件のすり合わせ - デザイナー・POとのデザインの相談 - DB設計 - 実装関連 - AWS Amplifyを用いた認証機能の開発 - 多要素認証を含む - MUIを用いた画面開発 - React Hook Formを使ったフォームの開発 - Axiosを使ったAPIの開発 - Chart.jsを用いたグラフの開発 - ZXingを用いたQRコードリーダーの開発 - Sidekiqとaws-sdk-railsを用いた非同期処理でのユーザー登録処理の開発 - インフラ関連 - RDS・ECSの費用削減 - fluentbitを用いたログルーティングの実装、ログ出力の改善 - デプロイ作業担当 - ドキュメント関連 - デプロイ手順書の整備、社内メンバーへのレクチャー - ディレクション関連 - リリースまでのタスク割り振りとスケジュール管理 - 顧客の要望の優先度付とタスク化 ## チームの課題と工夫したこと `課題1` チームのタスク管理を自分が担当していたが、プロジェクトが進むにつれて**顧客からの要望が増加した結果タスク管理業務の量に限界を感じた**。チームとしてはタスクの優先度判断やスケジュール管理がすべて自分に委ねられており、**自分がボールを持ったままの状態になってしまうことが多くチームのボトルネックになっていた。** ### 工夫した点 チーム内を3つの小機能チームに分割し、それぞれにタスク管理をする人を置いた ### 取組の成果 - 個人としては開発業務とタスク管理業務を両立できるようになった - チームとしては、チームを分割した状態でも大きな遅延なく機能を開発することができ納品期日に間に合わせることができた `課題2` プロジェクト内において、**デプロイ作業の理解が属人化していた** ### 工夫した点 - デプロイの手順書を整備し、チーム内でレクチャーを実施 - またインプットするだけよりもアウトプットした方が身に付くと考え、デプロイ手順書をレクチャーを受けてもらったメンバーに加筆・修正してもらった ### 取組の成果 1ヶ月以内にデプロイ作業のできるエンジニアを1名→4名に増やすことに成功

## プロダクト概要 プログラミングスクールへの入会および入会後の受講者の決済・受講情報等を管理するシステム ## プロジェクトの特徴 - PMを除いて全員が未経験層(~1ヶ月目) - 既存のシステムへの機能追加プロジェクト ## チームでの役割 - DB設計 - バックエンドの開発 - 総合試験項目書の作成 - 仕様書の作成 具体的な業務としては以下の通り - 実装関連 - ポリモーフィック関連を用いたDBへの登録・更新処理 - Rubyのcsvライブラリを用いた、csv出力 - RSpecを用いた単体テストの実装 - ドキュメント関連 - Confluenceでの開発した機能に関する仕様書の作成 ## チームの課題と工夫したこと `課題1` - 以下のような要因でエンジニアが業務を進める上で困っていることを解消するスピードが遅くなっていた - チームメンバーが未経験層ばかりであったこと - 全員リモートワークでの勤務であり、お互いの状況を把握しづらいこと - 仕様を理解しているPMが複数プロジェクトを兼任していたこと - PMに相談をしても回答が数時間返って来ないこともあった ### 工夫したこと エンジニアメンバーが参加するdiscordサーバーを用意した `課題2` - 以下のような要因でタスクの実装方針を考えるのに時間がかかっていた - 歴史の長いシステムで仕様が複雑化していたこと - 仕様書のページが入り組んでおり、自分が開発する機能に関連するものがあるのか調べるのも難しくなっていたこと - チームメンバーが未経験層ばかりであったこと - 技術への理解や、システムのキャッチアップ自体の経験が少なかったこと - 仕様を理解しているPMが複数プロジェクトを兼任していたこと ### 工夫したこと 未経験層のメンバーと毎日終業前30分ほど勉強会を行った。 勉強会の内容としては以下のようなものを取り扱った。 内容としては、課題となっていた仕様理解において難しいと感じる箇所に対する相談を中心に行った。 加えて、仕様理解のために必要な技術的な知見の共有も行った