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

北野勝久

エンジニア

スクラムにおけるプロダクトオーナーだと理解して回答をしますが、プロダクトオーナーの役割は「プロダクトの価値を最⼤化」することで、スクラムにおけるイベントは、スクラムが重視する「検査」「適応」「透明性」の3つの価値観を体現する場です。
この2つの視点から考えていくと、私なら、以下のようにプロダクトマネージャーに提案すると思います。

## スプリント内で実施するもので必... 続きを見る

Dai Fujihara

プロジェクトマネジメント

過去、Javaプロジェクトのリーダーを経験したときに、コーディング規約の定義とかをしていました。その経験を踏まえての回答になります。

Javaのプロジェクトを進める際、コーディング規約を制定しているのですが、これに違反した場合プロジェクトやコードの品質にどのような悪影響を及ぼす可能性があるのでしょうか？

Shinichi Kogiso

デザイナー

スクラムでの例ですが、雑談が少ないとなったときに同期で「雑談時間」というMTGを開催する例がありました。ただ、基本的にオンラインではあまり良質なコミュニケーションが取りにくいので、数ヶ月に1回ぐらい同期的に飲み会などのイベントを設けることでコミュニケーションを活性化しています。

Shun

エンジニア

チームメンバーとの人間関係構築の状態問わず、まずは「なぜ導入するのか、導入することでどういった嬉しいことが起きるのか」をまず共有し納得してもらうことだと思っています。現状のプロジェクト進行やスループットに対する課題も添えるとメンバーも課題感を持ってくれると思います。

納得されたのであれば、「ではどんなことに気をつけ、どう動くべきなのか？」と言うフェーズになるのでそこでアジャイ... 続きを見る

横江 亮佑

エンジニア

たしかに Git を学びたてだと、
GitHub や GitLab が Git の派生バージョンなのかと感じてしまいますよね。

GitHub や GitLab は Git の派生というわけではなく、
Git を使ったチーム開発をよりおこないやすくするための Web サービスのお名前ですね！

Git のようなバージョン管理システムは、手... 続きを見る

Dai Fujihara

プロジェクトマネジメント

スクラムガイドに目安の時間が書かれているので、ご自身の状況に合わせてみてはどうでしょうか？

スクラムガイド
続きを見る

北野勝久

エンジニア

SRE NEXT という日本初のSREに関するカンファレンスを主催している者です。

SREは「サイト信頼性エンジニア」ではなく、「サイト信頼性エンジニアリング」としてまずは捉えたほうがしっくりくるのではないかと思います。実際には職種としてのSREを運用している会社も多いですが。
ですので「SREという組織をつくることのメリデメ」というよりは、「自組織に合う考えを取り... 続きを見る

北山 淳也

エンジニア

フレックス制度に限らず使わない風習があるところでは使われませんし使われる風習がある組織では使われています。

北山 淳也

エンジニア

スクラムマスターが必要な組織と
その組織で行われるスクラム開発ではスクラムマスターが必要であり
スクラムマスターが不要だと思う組織と
その組織で行われるスクラム開発ではスクラムマスターが不要です。

インフラエンジニアが必要な組織と
その組織で行われる開発にインフラエンジニアが必要であり
インフラエンジニアが不要な組織と

北山 淳也

エンジニア

どんな本でも調べたいことを役立てられるか自分のケースにあてはまるかどうかは読んだ人次第ですから
ここに質問を書いて回答を待つ時間で買って読み始めるのがいいと思います

kentaro haneda（jumbo）

エンジニア

PdMも会社やプロジェクトで持っている役割や職責が違うので、一概には言えませんが一般的には参加してもらったほうが意思決定や連携・関係性は良くなるように思います。
スクラムイベント全ては大変だと思うので、まずはプランニングから出てもらうなどが良いと思います。
またその場をうまく活用してもらい、PdMが持つタスクをバックログアイテムとして分担するというやり方もあると思います。

大橋桃太郎

プロジェクトマネジメント

非常に忙しいのは同感なんですが、deliveryと高い共通認識をもつことの優先度は高く(実際にクオリティやスピード、インパクトにも影響が)、またそれがdeliveryを主に担う人がdiscoveryの解像度を高めることにも繋がるので、率先して時間を使うべきテーマだと思います。うまくワークすれば、忙しさの幾分かを解消するものでもあり、「チームでいいものづくりをしよう」なテーマの話し合いからまずはして... 続きを見る

大橋桃太郎

プロジェクトマネジメント

「扱えるイシューの抽象度合い」 × 「イシューを解くことができるか」が重要だと認識しています。そのため、画一的に分かりやすい定量的な指標で測定することは不可能に近いと考えます。

一方で、具体的な目標はあるべきで、千差万別の状況/状態にあわせ「どうやって到達度を共通の尺度で判断できるように落とし込むか？」を本人とマネジメントが共に考えるプロセスが欠かせません。
続きを見る

北野勝久

エンジニア

育休と同じく、実際の権利があるか以上に文化の問題が大きいですよね。
メンバーはリーダーの普段の様子をみて行動するものでもあるので、周囲のリーダーにそういう姿勢があるとメンバーも制度を利用しやすいと思うのですが。

周囲のメンバーやリーダーと気軽に「そういえばフレックスってうちは利用するのって実際どうなんですかね」と会話してみるところから始めるのも良いかもしれませんね。

hiroaki

プロジェクトマネジメント

会社の就業規則に記載されているなら周りに遠慮はせずに利用しましょう。私の現在勤務している会社は労働基準法上の深夜労働にあたるPM10:00～AM：5:00以外は勤務可能なフルフレックスを導入しています。そのおかげで平日の役所に行く用事がスムーズにいって気分が良いです。

Dai Fujihara

プロジェクトマネジメント

アジャイルコーチとして、これからの開発にマッチする品質保証の支援をさせてもらっています。あくまで経験に基づいた一般論になるので、状況に応じてですが参考になればです。

まず、今までやってなかったことをいれると「遅く」なります。品質保証のプロセスもそうだし、スクラムの導入、自動テストなども同等です。よって、チームの出力量という意味での生産性は落ちると思います。
続きを見る

Shoichi Namba

エンジニア

テストを書いたりレビューのやり方を明確にしたりなど、デプロイしてOKになるための基準を明確に定めておくことが必要かと思います。
決めるだけだとなあなあになる可能性もありますので、CIでリントエラーやテストエラーになった場合はマージできないようにするなど、やらないとデプロイできない仕組みにもしておく必要があります。管理する側も「あー仕組み的にリリースできないから、ごめん、修正して」と言える... 続きを見る

石垣雅人

プロジェクトマネジメント

初期はやっぱり不毛な感じがするのですが「これが合ってしまえば、あとは勝ち」みたいなところがありまして、初期はちょっと我慢するか、一旦は時間の見積もりでやってみましょうとか、そういった形でいいのではないかと思っています。

Kono Naoko

デザイナー

Helpfeelはやめたほうがいいです。

Takashi Nagashima

プロジェクトマネジメント

以前の会社が東京の会社で、エンジニアは北陸や関西にもいました。
四半期に一回くらいは来てもらおうかな、くらいの運用でした。

職種や業務内容にも因ると思いますが、それよりも大事なのは家庭などプライベートと職務が両立できるか、だと考えています。なので会社が出勤日を設けたり、月イチ出社というルールを決めるのは反対です。

ただエンジニアであっても、集ま... 続きを見る