"コミュニケーション/チームビルディング"投稿一覧

和田健太郎

エンジニア

ヘルスケアについては、帰ってもらう・寝てもらう・くらいしか思いつきません。
先々を考えてどんなに忙しくても休んでもらうタイミングは作っています。

メンタルケアについては、意外と負荷のポイントが遅延や作業量以上に「裁量権」「意思決定の風通し」などが関わってくるので、そこを非常に重要視しています。

・高頻度でコミュニケーションの場（２日に１回ランチ... 続きを見る

Dai Fujihara

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

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

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

北野勝久

エンジニア

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

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

北山 淳也

エンジニア

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

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

北山 淳也

エンジニア

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

kentaro haneda（jumbo）

エンジニア

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

大橋桃太郎

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

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

Haruka Ishii

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

個人的なやり方になりますが、より上位概念を握ることを意識しています。

・全てのプロジェクトは経営戦略に何かしらの寄与する
・プロジェクトが複数人で数ヶ月単位で実行されるもの
・業務はある個人が数時間〜数日で実行されるもの

と定義するとき、プロジェクトの遂行は以下の①から進めていき、②と③を繰り返し続けると考えています。
①プ... 続きを見る

kentaro haneda（jumbo）

エンジニア

顧客や経営陣との信頼関係や体制にもよりますが、自分が大事にしていることとしてはリスクをしっかり伝えておくべきことです。もちろん約束事を実現するために最大限努力することも大事ですが、計画は精緻にしようとするほどコストがかかる割に精度には限界があるので、起きうる問題やそれへの備えなどを伝えておきます。
また計画を進行していく中でも、マイルストーンを決めつつ、進捗やリスクを共有し、一緒に進める... 続きを見る

Dai Fujihara

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

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

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

北野勝久

エンジニア

3年以上、フルリモートワークをしている者です。

テレワークによって制限された業務は特にありませんが、これは社内のバックオフィス部門メンバーの過去の努力の賜物であり、とくにソフトウェアエンジニアとして工夫をしているという感じではありません。もちろん秘密保持というか、オンライン会議中の音声が家族に聞こえないように・・・といった工夫は各自が行っていくべきだと思います。
<... 続きを見る

北野勝久

エンジニア

メリット・デメリットをテーブルの上に出し尽くして議論できた前提なのであれば、メインで物事をリードする関係者の覚悟次第だと思いますね。
もちろん課題に対して最適で、お客さんへの価値提供を念頭に置いた技術選定をすべきという話はありますが、結局は開発に関わる誰がどれくらいのコミットなのかで最終判断は変わってくるのではないかと。
仮に課題に対して最適で、お客さんへの価値提供を念頭に置い... 続きを見る

石垣雅人

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

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

石垣雅人

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

一番の課題は、見積もりをしないと言いつつも、チーム外に出たときには変換コストがかかるので、そこを上手く何か繋げるようにしたいことです。
結局そこで工数を見積もったらかなり時間がかかることは変わらないので「スクラムチームの外に出たときには、どうするべきなんだっけ？」というのは考えていきたいなと思っております。

norami

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

一人でやるなら技術合理性だけで良いと思いますが、組織で仕事するなら組織戦略を考えないといけないわけで、技術合理性と組織維持と両方考えないといけないのが普通だと思います。

この２つで悩む典型的な状況は以下のようなものではないでしょうか？

1. 学習コストを考えると短期的に古い技術が効率が良いが、長期的には新しい技術を使ったほうが良い
2. 現在の... 続きを見る

Kono Naoko

デザイナー

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

HIU Naoki

エンジニア

まず前提に、「課題に対して適切な技術である」事が必要だと思います。

その中でいくつかの選択肢がある場合に、判断が必要になるかと思います。

・強いエンジニアを採用してスゴイプロダクトをスピーディに展開したいのであれば、そのようなエンジニアが興味を持ちそうな技術を採用
・普通のエンジニアでを採用して枯れたプロダクトを長く運用していくような場合であれ... 続きを見る

和田健太郎

エンジニア

個人的には、おっしゃるとおり「技術選定は開発者のモチベーションを高めるためではなく、顧客や自社のビジネス課題を解決するために最適なものを選ぶべき」で間違いないですし、頭の中では多くのエンジニアが理解できているかと思います。

一方で、「早く」「安全に」「高度に」を実現するために技術が日進月歩で進んでいることもまた事実ですので、結果的にビジネスで成功することを広く長い視野でみてい... 続きを見る

Takashi Nagashima

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

顔色を伺うのではなく、リアクションを理解するのに、顔が写っていることは重要です。情報量が違います。
もちろん準備が服装がお化粧が云々はあると思います。ただ仕事をしている以上、最低限の準備はしておくべきだと思います。そのあたりは理由にして欲しくないです。

いま言ったこと伝わった？何を聞きたいの？困ってるの？ただの確認なの？そういったニュアンスは音声だけでは十分には伝わ... 続きを見る

Takashi Nagashima

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

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

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

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