Created
May 23, 2021 7:40 AM
Tags
YOJOEngineeringManagement
マガジン
チーム戦略・目標
YOJOエンジニアチームで2021年度の目標を設定しました!!!
YOJOでは、マトリクス型の組織形態を取っているため、機能部門(開発部門、CS部門など)ごとに目標を立てることにしました。
エンジニアチーム(= エンジニアリング部門)としては、次のような年次の目標を立てました。
2021年度の目標は
「エンジニアリングで経営をドライブする」
です!(今決めた) これまでは、事業に引っ張られて、なんとかエンジニアリングしてきたなと。 創業期は全然それで問題なかったのですが、これからは引っ張られているだけではダメで。 エンジニアリング主導の企画提案・認知度向上・効率化・UX向上などで事業を引っ張って行こうよ!!ということです。
エンジニアリングドリブン / テックドリブンといっても、他社も全く使っていないような技術を使う(生み出す)のはまだ難しい。 でも、今ある技術をYOJO独自に組み合わせて、YOJO独自のポジショニングを築いて行くことはできるはずです。 そう、YOJOのエンジニアチームならね。 目標を5つの項目にブレークダウンして整理した図が以下のようになります。
頑張ってやっていきます! 経過もまた報告できればいいなと思います。
項目 | 目標 | 現状 | 理想の状態 | キラー戦略 | やるべきこと |
---|---|---|---|---|---|
認知度の向上 | toC医療サービスで独自の価値を築いているエンジニアリング組織として医療に興味があるほとんどのエンジニアに認知される | ・Twitter薬剤師界隈でちょっと有名になりつつある
・一般的にはまだまだ知られていない | ・toC医療サービスでエンジニアリングいえばYOJO
・薬剤師がリモートワークできる会社らしいヤヴャイ(医療界を変えられそうな感がある) | ・CS×エンジニアでブランディング
— エンジニアにもドメイン知識のある人たちと高度に協力し合いながら一緒に仕事したいと思っている人たちはいる | ・CS×エンジニアとしての外部発信の場(記事・登壇など)をふやす |
社内リレーションの強化 | 患者視点・他部門視点・プロジェクトマネジメント力の強いエンジニアリング組織として信頼される | ・社内から信頼されていない
・開発とそれ以外の部署で壁がある | ・社内から「うちのエンジニアチームならなんでも実現してくれるはず!」と思ってもらえる=他部署がやりたいことを考える際に、開発力が思考の妨げにならない
・開発チームから改善案・企画案がどんどん出てくるように | ・社内への「私たち最強」アピールを頻繁に行う
— 「実際うちのエンジニアチームどんなもんなの?」「なんでそういう意思決定になっているの?」が分からない
・開発チームと他部署の交流を増やす仕組みづくりを行う
・YOJO全体でエンジニアリングに理解のある人々を増やす | ・開発物の共有の場を増やす
・勉強会などコミュニケーションの場を増やす |
技術力×事業力の向上 | これはYOJOしかやってない×これがあるからYOJOはだけが勝てる・負けないといえる「技術」を持つ | ・個々人の技術力は高いが、YOJOとして特化した技術はまだない | ・「YOJOのエンジニアチームだからできたエンジニアリング」というのを持つ | ・「こんなことできたらいいな」の妄想を定期的に行える機会を作る | ・社内のハッカソンや企画会議でまずはアイディアの種を出し文化を作る |
品質保証×プロジェクトマネジメントの向上 | 高い品質のサービスを透明度性高く納期までにデリバリーする | ・バグも多く、納期は守れていない
・リリースする前に社内で動作検証サイクルが確立ができていない | ・プロジェクトの進行がきちんと可視化され、多くのメンバーの目に触れさせることで、品質を担保する
・開発の成果物を早めにオープンにすることで、より早い段階でのFBを可能にし、よりよりプロダクトを目指した修正を行う
= より正しいアジャイルに移行していくため、早めにリリースし、早めに検証→修正を行う | ・プロジェクトごとの反省・振り返りを行う
・オープンなリリースプロセスの構築 | ・自動テストの仕組み整備
・検証環境整備(誰でも触って検証できるように)
・進捗管理の仕組み整備(より透明で見えやすくなるように) |
組織文化×開発スタイルの改善・確立 | 全員がフルサイクルエンジニアになる仕組みを作り、企画〜運用まで責任を持てるチームになる | ・一応、開発から運用まで全員がタッチしてはいるが、企画部分と運用部分はまだ弱い
・特に会社全体としての目標や数字に対しての感度が全員高いとは言えない | ・全体のエンジニアレベル底上げ
・全員が運用を経験
・BIを全員がさわり、数字の意味を知った上で開発する / KPIの変動まで責任を持つ | ・読書会・勉強会を定期開催
・全メンバーがCHエンジニア対応に入る
・リリース前にKPIを設定→リリース後に確認→改善計画
(「この数値が落ちなければいい」という程度でもいいので) | ・3週間に一度の読書会開催
・CHエンジニアチームの安定運用・改善
・プロジェクトごとにKPIを設定し、モニタリングする習慣をつける |