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

Offers(オファーズ) 公式

※本投稿は、2023年5月30日に開催されたイベント「開発生産性を高める 〜ソウゾウ、Voicyの挑戦と苦労〜（https://offers.connpass.com/event/283434/... 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年5月30日に開催されたイベント「開発生産性を高める 〜ソウゾウ、Voicyの挑戦と苦労〜（https://offers.connpass.com/event/283434/... 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年5月30日に開催されたイベント「開発生産性を高める 〜ソウゾウ、Voicyの挑戦と苦労〜（https://offers.connpass.com/event/283434/... 続きを見る

kentaro haneda（jumbo）

エンジニア

そうだとも思いつつ、その中でどういう結果に対して貢献をしていて、それがどこまでが自分の考え・意思が入っていたかが大事だと思います。チームごと転籍・転職することはなかなかないと思うので、どんなチームや状況でも自身が再現性を持って価値を出せるかが大事だと思います。

kentaro haneda（jumbo）

エンジニア

分断がどういう状況を指しているかわからないですが、関係者での目標や目線合わせ・顧客課題に対して同じ方を向けている状況でしょうか？各々の職責で向き合うべき課題がどうしてもズレてしまうことは往々にしてあるし、それぞれが責任を持つことでもありますが、より抽象度が高いレベルでは同じ方を向いているべきだと思います。

なので基本的なアクションは複雑な手法などではなく、分断があるのであれば... 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年7月20日に開催されたイベント「実践から学ぶ チームトポロジーを活用したチーム分割（https://offers.connpass.com/event/288731/ 続きを見る

Offers(オファーズ) 公式

※この投稿は、2023年7月20日に開催されたイベント「実践から学ぶ チームトポロジーを活用したチーム分割（https://offers.connpass.com/event/288731/ 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年7月20日に開催されたイベント「実践から学ぶ チームトポロジーを活用したチーム分割（https://offers.connpass.com/event/288731/ 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年7月20日に開催されたイベント「実践から学ぶ チームトポロジーを活用したチーム分割（https://offers.connpass.com/event/288731/ 続きを見る

熊谷 貴之

エンジニア

リモートワークでは、最初の印象が重要です。新しい職場で良好な関係を築くために、以下の方法を実践していました。

最初の1週間で、チームメンバー全員と個別に30分の打ち合わせを設定し、自己紹介や役職などを知るよう心掛けます。これにより、1人ずつ行うことで覚えやすく、仕事の詳細を聞く時間も確保できる点が良いです。

また、1対1のコミュニケーションではプライベー... 続きを見る

嶋田印刷

デザイナー

この質問はよくあり今も昔も多くの人がかかえる、悩みかもしれません。そして中々解決できる問題ではないので、自分の特性と照らし合わせて考えた方が良いです。

シビアですが、状況が変わったら儲かる方に自分を変化させないと、人生は厳しいので成功できないと思います。過去の成功法則というのは、ヒットした好きな事をすると多くの人が既にやっているので在庫損します。

価値観... 続きを見る

pospome

エンジニア

"保障はないです。外れるからには全部あなたたちでやってくださいという形にしています。例えば、特定のアプリケーションをAWSで動かしたい、ECSを使うぞ、となったときはAWSアカウントの払い出しからやってもらうことになるので、滅茶苦茶厳しいです。

デファクトスタンダードから外れることというのは極端なケースでないとあり得ないので、基本はずれる必要がないというのが前提となります。<... 続きを見る

pospome

エンジニア

特に決まりはないです。

pospome

エンジニア

"抵抗の声の想定については、各チームから出るかなと思っていました。今まで自チームで責任をもって選定してきたテクノロジースタックだったり、やり方だったりを統一するとなると良い気持ちはしないはずなので、ある程度の抵抗は覚悟していました。

しかし、結果的にほとんど声は出なかったので、まあ良いかという形でスルーしたので出なかった理由について深掘りをしたということはありませんでした。"

pospome

エンジニア

"型があって、スピンナップが早いという二つの特徴をもつ言語が欲しかったというのが軸です。型があるという部分は比較的たくさんの言語が当てはまるのですが、スピンナップを考えると、Goはバイナリを置くだけでスピンナップが保障されるので、自分が利用してきた経験もあって、すんなり決まりました。加えてですが、自分が入社したときの新卒研修で用いていたのがGoだったのもあり、社内でマイナーな感じでなかったのもあっ... 続きを見る

pospome

エンジニア

"基本的に、共通して提供できるような技術を社内のスタンダードとして定めています。例えばKubernetesは比較的どんなアプリケーションでも載せられるので、メンバー全員の要件を満たせるようなものなので採用しています。
みんなの要件を満たせるような技術かどうか、というのをラインにしています。"

北野勝久

エンジニア

ここでいうリードタイムを、開発着手〜顧客環境へのデプロイまでのリードタイムと捉えて回答します。（お客様のビジネスゴール達成までのリードタイムとは議論を切り分けます。）

次のようなチェックポイントがあるのではないかと考えています。

・変更しやすいコードを維持する（ために、遠回りにみえてもリファクタリングを継続的に行う）
・Pull Request... 続きを見る

北野勝久

エンジニア

多少、単純化しすぎているような気が自分でもしますが、大まかには以下の理解でいると良いのではないかと思います。
Stream-aligned Team ... いわゆるプロダクト開発チーム
Enabling Team ... Stream-aligned Teamの技術的な支援を行う
Platform Team ... Stream-aligned Teamが開発するに... 続きを見る

和田健太郎

エンジニア

立場は２部署の統括マネージャーですが、自分も完全に試行錯誤です。
個人的には概念を浸透させるというよりは、具体的な施策を実行した上で「実はこういった概念に基づいて取り組みをしてました」というネタバラシの順番でやるように心がけています。
どうしても概念の説明から入ると、「で、何するの？」→「うん、やってみたらいいじゃん」とこうなってくるので、まずは自部署の良い施策、として成功させ... 続きを見る

kentaro haneda（jumbo）

エンジニア

ケースバイケース過ぎて明確に言語化ができないのですが、そういったもの含めた相談・意思決定の場だけ作っています。開発関係の役職者以上で意思決定してます。