義升 @kimura6933 正直、「めっちゃシゴデキだが性格がキツくて威圧感強い人」より「仕事の能力はそこそこだけど柔和で協調性があって楽しい人」のほうが一緒に働きやすい。 足並みをそろえて働ける人とのほうがチームとして動きやすいから。 2025-05-30 19:31:42

義升 @kimura6933 正直、「めっちゃシゴデキだが性格がキツくて威圧感強い人」より「仕事の能力はそこそこだけど柔和で協調性があって楽しい人」のほうが一緒に働きやすい。 足並みをそろえて働ける人とのほうがチームとして動きやすいから。 2025-05-30 19:31:42
アジャイルにおいて開発の過程や成果を振り返ることは、チームの改善につながる大切な行動です。とくにスクラムにおいては、スプリントごとにレトロスペクティブ(retrospective、ふりかえり)のイベントを実施します。ふりかえりのフレームワークといえば「KPT」がまず思い浮かびますが、実際にはチームの状況やふりかえりの目的に合わせて、さまざまなレトロスペクティブの手法をチョイスするのが望ましいでしょう。 それでは具体的にKPT以外ではどんなフレームワークがあり、それぞれチームがどのような状態のときに用いると効果的なのでしょうか。ブログに「自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由」という記事を執筆したソフトウェアエンジニアの大金慧(@bayashimura、ばやし)さんと、その記事で引用された講演資料の発表者で長年エンジニアリングマネージャーを務める小田中育生(
視覚的階層の作り方 情報の重要度を視覚的に表現するテクニック: サイズによる強調:重要な要素ほど大きく 色による区別:カテゴリーごとに色分け(最大5色程度に抑える) 配置による関係性表現:中心・周辺、上下左右の位置関係で重要度を表現 線の太さと種類:実線/破線/点線で関係性の強さや種類を区別 シンプル化のコツ 図解は複雑さを減らすためのものであるため、シンプルさが重要: 抽象化レベルの統一:同じ図の中で詳細度を揃える 情報の取捨選択:本質的な要素だけを残し、ノイズを削除 チャンク化:7±2の法則を意識し、一度に表示する要素数を制限 反復パターンの活用:類似構造は同じ表現方法で統一 認識のギャップを埋める図解テクニック チームメンバー間の知識や理解の差を埋めるための図解テクニック: 前提条件の可視化 仮定リスト:図の隅に、前提としている条件を明示的にリスト化 知識マップ:議論に必要な知識領域
この記事では、NeWork の開発チームがフルリモート環境でアジャイル開発するにあたり個人的に重要だと感じた部分を紹介します。 目次 目次 はじめに 背景 NeWork のチーム構成と動き方 コミュニケーションの工夫 オンラインの人を取り残さない各種ツールの利用 各種打合せ アイデア出し・情報共有・レトロスペクティブ 開発作業 話しやすいチームの文化づくり オープンな打合せ 話しかけやすく・呼び出しやすい環境 常に会話できることで雑談 データでみるコミュニケーション量 まとめ おわりに はじめに こんにちは、NeWork 開発チームの加藤です。私は普段、オンラインワークスペースサービス NeWork の開発エンジニアをしています。 NeWork は、手軽に話しかけることを重視したオンラインワークスペースサービスです。従来の Web 会議ツールとは異なり、話したいメンバーとすぐに話すことがで
人には、どの人にもある「思考のクセ」が存在しています。 そうしたクセは、普段あまり意識されることはありませんが、「知っている」人は、それを良くも悪くも「実態を隠す技術」や「他人を操作する技術」として使うことがあります。 例えば、「アンカー効果」として知られている思考のクセがあります。 これは「予測を立てる直前に見た数字をアンカー(よりどころ)にしやすい」という傾向です。 当然これは、金儲けにも利用できます。 数年前、アイオワ州スーシティーのスーパーマーケットがキャンベル・スープのセールを行い、定価から約一〇%引きで販売した。数日間は「お一人様12個まで」の張り紙が出され、残り数日間は「お一人何個でもどうぞ」の張り紙に変わった。 すると、制限されていた日の平均購入数は七缶で、制限なしの日の二倍に達したのである。 このように、心理に関する知識は、成果を大きく左右することもあります。 では、この
誇り高き「マネージャー」を全うするために。“理想のEM”小田中氏を支えた珠玉の5冊 2024年6月20日 株式会社カケハシ EM 小田中 育生 筑波大学大学院修了後、外資系半導体企業を経て、2009年に株式会社ナビタイムジャパンに入社。2019年からはVPoEを務める。2023年10月に、EMとして株式会社カケハシに入社。薬局DXを支えるVertical SaaS「Musubi」をコアプロダクトに位置づけ、「しなやかな医療体験」を実現するべく新規事業のプロダクト開発にコミットしている。著書に『いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法』(2020年、インプレス、共著)がある。 X note エンジニアがマネジメントに踏み出すとき、今まで向き合ってきた「技術やシステム」と、マネージャーとして向き合うべき「組織や人」の特性の違いに戸惑う人も少なくありません。 エ
チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に
株式会社北の達人コーポレーション代表取締役社長 1968年、神戸生まれ。株式会社リクルート勤務後、2000年に北海道特産品販売サイト「北海道・しーおー・じぇいぴー」を立ち上げる。 2002年、株式会社北海道・シー・オー・ジェイピーを設立(2009年に株式会社北の達人コーポレーションに商号変更)。 2012年札幌証券取引所新興市場「アンビシャス」、2013年札幌証券取引所本則市場(通常市場)、2014年東京証券取引所の市場第二部(東証二部)、2015年東証一部と史上初の4年連続上場。2017年、時価総額1000億円。2019年、「市場が評価した経営者ランキング」第1位(東洋経済オンライン)。日本政府より紺綬褒章7回受章。 「びっくりするほどよい商品ができたときにしか発売しない」という高品質の健康食品・化粧品で絶対に利益が出る通販モデルを確立。「北の快適工房」ブランドで、機能性表示食品「カイテ
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるw」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍
この日に関してはリリースの開発工数日に含まないように事前スケジュールし、 普段の仕事中にやれていない対応、作業の整理やコミュニケーションを行なう日としています。 社内イベントは、Gather.Townを使用して運用しています。 メリット / デメリット メリット エンジニアチーム全体に情報を共有するの提供 仕事以外の会話の場が増えた デメリット 運用コスト 特に組織にマッチさせて、継続的に実施できるフォーマットが決まるまでのコストがかかる ある程度繰り返し実施するとフォーマットが確定するのでコストは下がっていく ☕ Coffee Chat 内容 社内イベントで大人数で集まるコミュニケーションの場を設けることはできたが、 リモートで大人数集まっても同時に喋れるのは3〜4人程度ということも、何回か実施して分かってきました。 そこで以下のスライドで紹介されていた、Coffee Chatを取り入れ
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog 2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY21 +Interview」では、登壇者たちに発表内容をさらに深堀り、発表では触れられなかった関連の内容や裏話などについてインタビューします。今回の対象セッションは「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」です。 LINEアプリのスタンプに関する機能を担当している、LINE Fukuokaのクライアント開発チームでは、年々増加する機能に応じてチームのサイズも拡大していました。一方でコミュニケーションをボトルネックとする開発
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状
ビジネス・ブレークスルー大学(BBT大学)は、オンラインのみで経営の学士資格を取得できる、日本唯一の大学です。今回はBBT大学主催で行われた、経営学部教授・斉藤徹氏の 『だから僕たちは、組織を変えていける やる気に満ちた「やさしい組織」のつくりかた』刊行記念講演の模様をお届けします。社員のエンゲージメントが高い「やさしい組織」をつくるために一人ひとりにできることは何か、今まで斉藤氏の30年近い起業家経験から得られたエッセンスが1冊にまとめられています。本記事では、建設的な議論を行うための「推論のはしご」の考え方について、組織に「安心感の醸成」をもたらすためのポイントについて語られました。 建設的な議論を妨げる最大の要因は、感情的になってしまうこと 斉藤徹氏:続いて、(チームメンバーの意識が)外に向いたらどうすればいいのか。これはみんなが意見を出し合うことが大切です。でもこの建設的に第3案を
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く