TISが実践する、価値創造に向けたチームの作り方──ドキュメント化とリーダーシップの醸成で自走する組織へ
2023年2月開催のDevelopers Summit 2023での講演で反響を呼んだ、TISの「SIerな会社が新規事業開発へ取り組む中での失敗と、それを踏まえた取り組み」。半年後の今、チームの意識変化がビジネス価値の向上にどのような影響があったのか、実践の過程でどのような課題が見えたのか、テクノロジー＆イノベーション本部 デザイン＆エンジニアリング部 チーフ 髙谷 拓来氏がチームメンバーの視点から捉えた「チームの変化」について紹介した。 講演資料：チームがビジネス価値作りに向かい自走するために ビジネスの価値創造にむけて自走する組織が持つ三要素 SIerとして、多くの企業のシステムインテグレーションやアウトソーシングなどを手掛けるTIS。髙谷氏が所属する新規事業開発チームでは、名前の通り「TISで新規事業を成功させる」ことをミッションとし、社内で生まれてきた新しいビジネス・事業に対し、
「設計からリリースまで、開発チーム全員で取りかかる」 PdM+デザイナー+エンジニア+QA+UXライターで進めるプロダクト機能改善
開発の企画からリリースまでの流れ futaba：現在みなさんがどんな体制でプロダクト開発をやっているか、今に至るまでどの様に体制が変遷してきたかというところはわかりましたが、実際にどうやって活動をしているのか、どうやって開発を一緒にやっているのかのがまだイメージが湧かないんですけれど、具体例を含めて教えてもらえたりしますか？ keroyama：ここからは私中心に話そうと思っています。 futaba：ありがとうございます！ keroyama：（スライドの）下に、開発の企画からリリースまでを具体的にどうやってやっているのかみたいなキャプチャをワーっと貼っています。今回は源泉徴収票機能の開発に沿いながらお話できればと思っています。 まず一言で言っちゃうと、設計からリリースまで本当に開発チームの中でみんなで協力して進めているよね……みんな？ って思っているんですけど（笑）。 futaba：そうです
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
Machine Learning 共通基盤構築の振り返り〜チーム立ち上げからクローズまで〜 | メルカリエンジニアリング
この記事は、Merpay Advent Calendar 2022 の17日目の記事です。 こんにちは。メルペイ 機械学習チームでエンジニアリングマネージャーをしているshuukです。 本日は、Machine Learning Platformチーム（以下：ML Platformチーム）をクローズした話をしていこうと思います。 MLの共通基盤という魅力的なアイディア もしあなたが、複数のMLチーム（またはMLシステム）が並行稼働している組織にいる場合、それらの共通部分を括り出した基盤を作り、MLエンジニアはその基盤の上で作業したほうが効率的だと考えたことはないでしょうか。 実際、MLの構成要素は、おおまかには特徴量計算、学習、予測、サービングといったパーツに分解することができ、共通部分も多いです。 新しいMLシステムをスクラッチで開発する苦労を知っているMLエンジニアにとって、社内共通のM
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
すごい開発チーム育成ハンドブック · すごい開発チーム育成ガイド
すごい開発チーム育成ハンドブック プロダクト開発の｢やること｣リストはTrelloで順序立てておくとうまくいく ビジネス上の要求が変化しやすいときは、タスクの優先順位を2週間変えないようにする ビデオ会議で遠方チームに「伝わらない」と思ったら、一度「顔合わせ会」を開催する 「これは使えない」と言われたら、機能の意思決定を「担当者」に委ねる エンジニアに期間が「わからない」と言われたらタスクを細分化して具体的に 仕様を考えるときはエンジニアと対話する 開発チームの開発速度がわからないときは、短い期間で速度を計測する 開発状況を把握できないときはスクラムで開発する 「Scrum for Trello」でストーリーポイントをチームで共有する やってみないと分からないタスクは調査する スクラムが定着しないときは、2日のスプリントで慣らす ストーリーポイントの見積もりは「比べる」が基本 ストーリーポ
SREチームがスクラムを導入し1年でタスクの可視化と脱属人化を実現した話
ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。 ビズリーチ事業部のSREチームについて 「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。 なお、チームの構成は以下のようになっています。 開発者: SREチームのメンバー(5人) PO: SREチームのマネージャー スクラムマスター: 社内横断組織に所属している専任のスクラムマスター SREチームが抱えていた課題とスクラムの導入目的 まず、SREチームがスクラムを導入した背景を説明します。 PO
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
チームを育てるのに7つのレベルのデリゲーションを考えてみる - Mitsuyuki.Shiiba
この数年は色んな開発チームのサポートをしてるんだけど、最近、その中のひとつのチームに対するサポートの方法を切り替えた。「外からアドバイスをする」から「中に入って実際にやり方を見せる」に。 たまに「どうしてそこまでやる必要があるのか？それで成長できるのか？自分で考えて決断をしていくことで成長するべきではないか？」みたいに考える人もいるかもしれないけど、僕は単にそうした方がそのチームにとって良いなと思っただけ。 「このチームはダメだなー」とかは全く思ってなくて、むしろそのチームのことが好きなので「どうやるのが一番ストレスなく成長できるかなー？」というのを考えた結果の切り替え。 ただ、感覚で動いてしまってるので、自分の頭の中の整理のためと、そのチームも含めて周りの人に説明できるようにするために理由を考えてみたいと思う。たぶん、Management 3.0の7つのレベルのデリゲーション（権限委譲）
みてねのスクラム開発 / scrum development style in mitene - Speaker Deck
みてねのMeetup #3の発表資料です。
GitHub製フレームワークHubotの概要とインストール、チャットアプリと連携する基本的な使い方
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
モダンなチーム開発環境を整える | サーバントワークス株式会社
モダンなチーム開発環境 モダンなチーム開発環境の考慮ポイントの図解 ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、
チーム開発をスムーズにするために何ができるか
DevLOVEさんの「進め、現場のチーム開発 〜チーム開発実践入門〜」で講演した時の資料 http://devlove.doorkeeper.jp/events/12229Read less
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自然とそうなる開発チームをつくるいとなむ #toteka
チームのチームによるチームのためのアジャイル開発 -誰がやる！？じゃあ俺やるよ！- #devsumi #kansumi #kansumiA1