コミュニケーションコストが大きいチームの問題と付随する課題を解決した話 - LIVESENSE ENGINEER BLOG
転職会議事業部でITエンジニアをしている@ishitan-livです。 早くも2024年が半年過ぎようとしていますね。 会社によっては上半期評価の時期だったりするので、何故かブログが乱立してるような気がしますがきっと気の所為ですね。 というわけで、前回はスクラムマスター研修で得た知見について書きましたが、今回は多くのチームが抱えていそうな問題を改善するためのヒントになればと思い、考えを共有します。 made.livesense.co.jp この記事にかかれていること3行まとめ 現在のチームの問題点 スクラムに関わる人数が多すぎた コミュニケーションコストが大幅に増えた 異なる性質のプロダクト領域を複数名が担当していた 全員が1つのプロダクトゴールに向かえていなかった 適切なスプリントゴールを決められていなかった PBIを詰め込みすぎた 差し込み対応が入るたびにスプリントゴールがずれていった
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
リスクの洗い出しと判断のコツ - やしお
会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく
リーンコーヒー（Lean Coffee）のすすめ - SMARTCAMP Engineer Blog
スマートキャンプのプロダクトマネージャーの郷田です。 皆さんは普段の業務で、以下のように感じる場面はありませんか？ - 「同じチームで働くあの人と、いつもなんだか認識がずれてるかもと感じる」 - 「一通り会議はやったものの、なんだかいまいち話しきれてないようなモヤモヤがある」 - 「あの人にはもっと注力してもらいたいことがあるのに、なかなかそこまでやってもらえない」 こういった場面に遭遇したときには、リーンコーヒーを実施されることをおすすめします！ この記事では、チームのMTGで活用してみていただきたい「リーンコーヒー」を紹介します。 リーンコーヒー（Lean Coffee）とは？ リーンコーヒーの進め方 準備するもの その１：トピック出しと優先順位の決定（5分~15分） その２：トピックのディスカッション（10分〜45分） 初めてのリーンコーヒーでのハマりどころ 継続するかの判断をせずに
顔色が見えない時代のチームワークとマネジメント
おひさしぶりです。元プログラマーの菌類にして採用担当、最近はエンジニアリングマネジャーという名のグラウンドキーパーをやっている、「きのこる先生」です。草むしりに球拾い、白線を引いてトンボをかけて……と、エンジニアリングチームがケガせず練習や試合に全力を尽くせるコンディションを整えています。 相変わらずテレワークの日々を過ごしています。何度目かの緊急事態宣言で飲みに行く頻度は激減し、キャンプやサウナにもなかなか行けず、全力で引きこもる日々が続いています。どこかの神様がそんな状況を見かねたのか、プレイステーション 5の抽選販売に当選してしまい、ますます引きこもりに拍車が掛かっています。さすが次世代機、グラフィックスの進化がハンパないぜ！……といってもまだPS4タイトルしか遊んでないのですが、ロードの速さは素晴らしいですね。 さて今回は、こんな引きこもってテレワークを続ける日々で仕事はどのように
エンジニアといい感じに連携したいデザイナーの取り組み｜taiga / 佐野大河
こんにちは、デザイナーの佐野大河 @sn_taiga です。今日はエンジニアといい感じに連携したいデザイナーの取り組みについて話します。 社内でC2Cというデザイナー同士で学びを共有し合う場があり、そこで話した内容を社外向けにまとめました。 👉 C2Cについて詳しく書かれている記事はこちら チームのエンジニアにヒアリングしてみた画面を設計するときや仕様を詰めるとき、伝えるとき、動作検証をするときなどなど、日々デザイン業務に取り組む上でエンジニアとコミュニケーションを取るシーンは多いと思います。 そんな中自分が「エンジニアが開発しやすいように」よかれと思ってやっていることを付箋に書き出し、チームのエンジニアにヒアリングをしてみました。 良いと思った付箋に印を付けてもらい、その理由等を聞きました💬 「エンジニアが開発しやすいように」というテーマで書き出してみたものの、むしろデザイナーがエン
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
Linuxビジネスの成功者Red Hatが組織運営で心がける「オープンな意思決定フレームワーク」とは？
Linuxディストリビューション「Red Hat Enterprise Linux」を販売・サポートするRed Hat(レッドハット)は、技術者が分散した状態で製品開発を行っています。Linuxビジネスの中でも世界有数の成功企業のRed Hatのジム・ホワイトハーストCEOは、たびたび「一体、どうやって分散した場所の技術者の意見をまとめて一つのプロジェクトとして昇華させているのか？」という質問をされるとのこと。そこで、Red Hatが大切にしている「Open Decision Framework(オープンな意思決定フレームワーク)」について、プレゼンテーション資料として公開。オープンな意思決定フレームワークが、「オープンな意見交換」「参加型」「実力主義」「コミュニティ」「迅速かつ頻繁なリリース」という5つの原則から成り立つことを明らかにしています。 Red Hat Releases the
技術がわからないデザイナーやディレクター、プロダクトオーナーとのコミュニケーション - 特別天然記念物
コミュニケーションのAdvent Calendar 16日目です。 みろなるさんがコミュニケーションのAdventCalendarやるから書いてって言われたので、つらつらと書いてみます。 今年春にSI屋さんをやめて、デザイン事務所のような会社で唯一の常駐エンジニアとして、アプリの技術なんかほとんど知らないWebデザイナーさんやディレクターさんとのコミュニケーションについて思ったことを書きます。 経緯 今年の春に2年務めたSIerをやめました(参考:退職しました)。 SIer時代には、基本的にどこの現場に行っても周りはSEかPG。 お客さんもSEかPG。 エンドユーザーがSEなんて仕事も。 多々ストレスは有りましたが、話す方も聞く方もエンジニア。ある程度の共通の認識や知識を持ってコミュニケーションを取れることが多かったです。 そんな会社をやめて、今いる会社はWebデザイナーやディレクターがメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
デザイナーとエンジニアの良い関係