"組織/チーム体制"投稿一覧

とある大きな会社さんの開発方法で聞いたネタです。その組織は、プロダクトチームにQAエンジニアがいて、横断QA組織もあります。

プロダクトチームのQAエンジニアの仕事は、チームに貢献してチームの目標を達成するです。比較的チームに閉じた活動がメインになります。

横断QA組織は、複数のプロダクトチームを横断した視点でQAを行います。大抵の問題は結合時に起きるの... 続きを見る

アジャイルコーチとしてさまざまな現場に入って活動しているものです。

- プロダクトディスカバリーに課題を感じているか

はい。ほとんどの現場がこの課題を感じているように思います。

- 感じている場合、どんな流れで開発プロセスを回しているか

プロダクト側の組織や人を育てるしかありませんが、これには時間がかかります。... 続きを見る

依存性の管理方法やコーディングルール、CI/CD の仕組みなど、ビジネスロジックに関わらないような部分についてはなるべく統一するようにしています。

Web、UIをメインに活動するデザイナー10年目の佐藤です。

単発案件も長期契約案件もリモートワークになり数年が経ちましたが仕事自体は特に不満なく働けています（むしろ快適）

ただ、人と直接会わない寂しさみたいなものは有り、個人的なは
月に1.2回程度の出社があると良いかなと感じています。

自宅の設備が充実している点から出社での業務効率が著しく落ちる

同感です! いつも使っているものを使えないのは色々面倒なのですよね

弊社は「出社したければする」という制度なのですが、自宅からオフィスがそれなりに遠いこともあり普段は全く出社しないですね。
結果2~3ヶ月に1回くらい? になっている気がしますが...

よく知らんうちに誰かが決めた何かに情熱を燃やせる人は少ないと思うのと、そもそもそれって楽しいのか？という観点から、一方的な共有は不適切だと思っています。

一方で一定の視野や視座があって触れることができる領域でもあり、方向性を定めるドラフトと、具体化や磨き込みを行うフェーズと参加者を分けて作り込んでいくことが必要だと感じています。

- 集中して意思決定と推進を行なっていくのに適切な分割か
- 想定されるコンフリクトや優先順位の決定が必要となった際にコスト低く意思決定が可能か
を重視して、都度最適な体制を考えています！

デイリーのmtgと定期的な振り返りの効果(というよりは行わない時の損失)はとても大きいなと感じています。コミュニケーションの機会がフレームとしてセットされてることで複数人での情報が埋まったり、課題や機会の定期的な言語化と棚卸し、上位目的の共有機会などは定期的なイベントとしてセットされないとなかなかワークしないなと。

前後では、明確にコミュニケーション量が増加したことで、チーム... 続きを見る

最近スクラムを導入しはじめました！現在はチームで試行錯誤している状況ですが、スクラムマスター経験のある方にスクラムマスターの役割をお願いしています。

理由としては導入プロセスだから、というのが大きいですが、いる/いないでは大きく生産性に関わっていると感じています。

職種を超えたチームワークであるプロダクトづくり、さらに不確実性の高いスタートアップ事業とな... 続きを見る

一般的な考え方と個人的な意見の両方についてお話しします。

一般的な考え方では、スタッフエンジニアという言葉がLT中でも登場したように、基本的に海外ではキャリアラダーにおいて、ICだろうがEMだろうがラダーを登っていくにつれて、組織成果への貢献が重要視されるとされています。
海外と日本では環境や考え方が異なることは確かですが、スタッフエンジニアの書籍が日本語に翻訳され... 続きを見る

プロダクト開発のサイクルを一つのチームで回すことができたことは良かったと思います。

以前は、振り返りがエンジニアだけで行われていました。
しかし、スクラムのような開発プロセスに移行し、レトロスペクティブという名称になってからは、プロダクトマネージャーやデザイナーも参加するようになり、バリューストリーム全体にチームが関与しやすくなりました。
これが前提となり... 続きを見る

振り返りはアジャイルに動いていくには非常に重要な要素だと私も考えています。
もし別の観点を挙げるとすれば、組織の規模についてです。

LTで話したリソース効率期とフロー効率期の境目において、エンジニア組織の規模は15人程度でした。
私の組織ではこのタイミングから生産性の可視化やベロシティの管理に重点を置いてきましたが、このような規模の開発チーム（当時は3つの... 続きを見る

事業の成長を促進するという大きな方向性のもと、生産性の可視化を進めてきました。
これによって、理想の方向性と現状のギャップを可視化し、課題を見つけて解決にチームで取り組むことができる状況を作り出せたと思います。

もちろん、課題の発見や解決の練度には個人やチームによる違いがありますが、可視化の取り組みによって、課題を自ら見つけて動くことが容易になったという傾向は感じて... 続きを見る

前提、Four Keysなどはある程度共通の基準を持つ指標だと考えていますので、チームの状況が似ていればチーム間で共有して活用することは問題ないと思います。
何か特定のSaaSの指標の場合は、例えばリードタイムやPRクローズまでの時間など、非常に細かい数字が多数存在するかもしれません。
各チームがそれらの指標にどのような課題感を持ち、どの指標を改善したいと考えるかは、チームごと... 続きを見る

組織成果の最大化に動けることが市場価値の向上に繋がること、チームや組織の成果を作っていくことの重要性に気づいてもらう、もしくはメンバーが意識する、ということが定性的なポイントとしては重要だと考えます。
もちろん、各個人の生産性が高ければ全体のパフォーマンスもある程度は向上するというのは事実で、個人の成果を最大化することは前提となるとも考えます。

例えば、ベロシティは... 続きを見る

ここでいう「観測する内容」にあたるメトリクスの存在は、当日のLTで話した3つの原則のうちの1つであり、重要なポイントの1つです。
メトリクスを利用する際に最も注意すべきなのは、それらを人事評価に直接使用しないことです。

また、エンジニアリングマネージャーの視点から言えば、課題の発見と解決をサポートすることを意識し、EMとしての役割を果たすことが重要です。
... 続きを見る

※本投稿は、2023年6月27日に開催されたイベント「エンジニアのプロダクトロードマップとの向き合い方（https://offers.connpass.com/event/286019/... 続きを見る

組織全体に関与する権限や、課題解決へのチームとしての取り組みが評価されることが重要だと思います。

さらに言えば、より上位のレベルで、会社の価値観や文化がしっかりと確立され、エンジニア全員が認識していることも重要だと思っています。
例えば、私たちの会社ではフリマのサービスを提供しているので、サービス内での総取引金額であるGMVが最も重要なKPIとされています。 続きを見る

※本投稿は、2023年6月27日に開催されたイベント「エンジニアのプロダクトロードマップとの向き合い方（https://offers.connpass.com/event/286019/... 続きを見る

※本投稿は、2023年6月13日に開催されたイベント「開発生産性を高める〜SmartHR、SODAによるチーム起点の取り組み〜（https://offers.connpass.com/event... 続きを見る