ID:67192さん

スーパーマーケットの惣菜部門

利益率を維持した状態で、売り上げを昨年度比100%以上にすること

【前提】 * 愛知県三河地方に５店舗構えるスーパーマーケット * 部門の売り上げは平日65万前後、休日100万前後 * 自社のPBを多く持つ * 創業から100年以上経つ老舗でファンが多い * 商品の入れ替え、値決めなどの権限は基本的に現場に移譲されている 【問題】 * 主力メンバーが3人退職した。（それによって私が部門責任者に繰り上がりました） * 人員が昨年度と比べて2人少ない 【その状態を作るために必要だと考えたこと】 * 自社の強みと顧客の要望を掛け合わせた新しい主力商品の開発 * 作業の効率化 * 商品の見直し * 人員の配置の再検討 【工夫したこと】 * Aランク商品、Bランク商品に注力し、売り上げ比率の低い商品は廃止するか削減 * 日配部門など他部門の商品と被りのある商品の洗い出し、廃止 * これによって商品の管理、発注業務の削減を行いました * 手作業が発生するかつ売り上げ比率の低い商品の既製品化 * 作業量の削減と、手作業をすることで得られるメリットの多い商品のクオリティを上げる方向性への切り替え * 顧客アンケートの実施、東京などに出張し唐揚げの有名店をチェック * 当時流行っていた唐揚げに注目。自社のブランド鶏 + 無添加の調味料などを使用して完全オリジナル商品の作成をすることで売り上げの向上を図った * 結果的に、家族向け、単身向けのニーズに合わせた二種類の唐揚げを作成。唐揚げ単体の売り上げは前年比180%達成。 * 同時に唐揚げを使用した弁当などの新商品を開発 * その他無添加商品の仕入れ先確保など 【結果】 * 売り上げは前年度比103%を達成 * 利益率は前年度比率112%達成

Webエンジニア開発チーム

納期までに開発を完了できる状態

**注意) こちらの内容は年収評価シートの施工業者管理アプリケーション開発 の項目と内容が重複しています。既にそちらを読んでいただいた担当者様であれば読み飛ばしていただいた方が良いかもしれません** ### 前提 * 構成：PM 1人、PL1人、エンジニア2人 * 経験： * PL→ 未経験、開発経験2年 * エンジニア1人→ 未経験、開発経験1年 ### プロジェクトについて * 顧客は施工業者を仲介するビジネスを営む * 業者の管理方法が電話やメールなどによる対応の後、手作業でヒアリングした情報などを別システムに入力していた * その入力ミスや入力のコストなどの削減を行えるようにすること ### 取り組み * 課題1 * メンバーの経験が浅い * 考え * 開発領域を限定し、個々人が得意としている領域で開発を行うことで生産性を上げたい。 * アクション * 各メンバーの技術スタックを入念にヒアリングして、経験のある技術をできるだけ使用できるようにタスクの切り分け・調整を行いました。 * メンバーの得意とする分野がバックエンドとフロントエンドに分離していたこと、仕様の検討がバックエンドとフロントエンド別れていたため、開発チームをバックエンドとフロントエンドに分割しました。 * 結果 * 開発を進めることができました。が、フロントエンドとバックエンドの結合の部分で調整や手戻りなどが発生し、最終的に生産性が向上したかは微妙な結果になってしまいました。 --- * 課題2 * DBをFileMakerというローコードツールに置き換えるという特殊な要件がありました。そのため、予期せぬ不具合などが多発し、スケジュールの調整や仕様の再検討などが必要な場面が多々あった。 * 考え * 調整や仕様の再検討が発生する可能性があることは前提に置く必要がある。PM・顧客に事前共有した上で、いかに素早くそこをクリアしていくかが重要。 * アクション * 工数見積もり時点で、PMに懸念点を調査・共有し、同意した上でバッファを多めに積む。 * メンバーのタスクで問題や困りごとが発生した場合は即共有するよう周知し、発生した場合に同期作業を行い共有認識を迅速に構築できるようにした。 * PMや顧客に情報を連携する際には「現状」・「原因」・「代案」の三点を持って話すことを心がけた。また、先方がエンジニアではなかったため、図式化するなどして仕様の提案・調整を同期的に行った。 * 結果 * 先方から一定以上の評価をいただき、システム開発後の保守対応などの継続的な開発のご依頼をいただくことができました。 ### プロジェクトでの学び * フロントエンド開発とバックエンド開発を分離するのは慎重に行うべき * フロントチームとバックエンドチームの密な連携または緻密な設計が必要だと感じました。これができていないと、フロントエンドとバックエンドの繋ぎ込みで不具合が多発したり、認識の相違で手戻りが発生するなどの事象が発生した。 * 前提 * 仕様が流動的で設計の不備や変更が発生しやすい状況だった * 副業ということもありメンバーの稼働タイミングがバラバラで密な連携が取りづらかった * 反省点 * メンバー間で同期的にコミュニケーションが取りづらく、仕様が流動的で設計がブレていたことから、この開発のスタイルは向いていなかった * 改善策 * メンバーの技術スタックから開発スタイルは変更できませんでしたが、仕様変更があった場合にフロントチームとバックエンドチームで設計・実装を見直すなどのアクションを取れていれば、ある程度防げたのではと感じます。 * タスク管理の難しさ * 仕様が定まっておらず、タスクが流動的だったため、仕様の変更にキャッチアップしつつ、スケジュールを都度調整する必要がありました。また、FileMakerを使用するという特殊な要件があったため、想定外のエラーが多発しました。結果的に当初想定していた以上に開発期間が伸びてしまいました。 * 前提 * 仕様が固まらない点についてはPMに要望を出しつつも、PMの方針として変えることができなかった。 * 反省点 * 作業に着手しはじめて、仕様の検討が必要な点や懸念点が出てくることが多く、後手に回った対応が多かった。 * 改善策 * FileMakerを使用するにあたって、仕様検討の段階で、懸念点や確認すべき点を事前に洗い出すべきでした。 * 仕様検討の段階でMTGに参加できていなかったため、MTGに参加し、事前に検討事項・懸念点を把握しておくべきだった。 * 仕様の変更などが発生した場合に、チームメンバーに自動で周知される仕組みを構築しておくべきだった。 * スプリントごとにプロダクトレビューを実施すべきだった - なぜそう思うのか？ - テストが充実した状態でリリースできないケースが多かったため、デグレが発生しやすい状態だったこと。 - 仕様が流動的だったため、プロダクトレビューの中で仕様の共有が全体向けにできたと感じた。 - プロダクトの状態とチーム全体で認識した上でタスクの分配や調整をかけた方が納得感が高まったのではと感じた。