Miro時差や場所に関係なく、いつでも、どこでも オンラインホワイトボードでのコラボレーションを実現しましょう。
「問題解決メソッド」とは？──会社の問題を解決する議論のフレームワーク | サイボウズチームワーク総研
会社では、さまざまな「問題」が起こります。問題を解決するために、あなたの会社ではどのように解決していますか？一般的には、原因や責任の追及をし、問題を解決しようとするのではないでしょうか。 原因や責任の追及も大切かもしれません。けれども、「なぜ？」「どうして？」と追求しすぎると職場の雰囲気が悪くなったり、担当者に責任を負わせたものの、問題は遅々として解決しなかったりすることも多いもの。 関係者で前向きに議論し、チームで解決できるといいですね。 問題解決の議論をするために、サイボウズで用いているのが「問題解決メソッド」です。問題解決メソッドは、共通の言語を使って話し合いを円滑に進め、前向きな討議を生むための「議論のフレームワーク」です。 この記事では、問題解決メソッドについて解説します。 そもそも「問題」とは何か―ネガティブな前提を変える ところで、何かしらのトラブルが起こったとき、私たちは「
【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
Product Managerはプロダクトチームにおいて「クイズ番組の司会者」であるべき｜Yuji Inagaki
この記事はユアマイスターアドベントカレンダー2022の22日目の記事です。 はじめまして。ユアマイスターでプロダクトマネージャー（以下PdM）をしております、稲垣と申します。 この記事では、私がPdMとして約10年程働いてきた中で、プロダクトチームにおいてPdMとエンジニア、デザイナーの関係性において、考えていること、大切にしていることを書きたいと思います。私は経験がBtoB向けのプロダクトが中心なので、そっち寄りの内容になっています。 まず自己紹介私は2022年10月にユアマイスターに入社しました。まだ新人です。あと、初めてnoteを書くので緊張しています。よろしくお願いします。 これまでのキャリアでは最初4年ほどエンジニアをやっていたのですが、その後は約10年ほどPdMをやっています。領域としては、ずっとBtoBの、主にSaaSをやってきました。 ユアマイスターには約5年ほど前に「大人
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
NTT Com チームビルディングハンドブック
チームビルディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したチームビルディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/teambuilding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『チームビルディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したハンドブックであるリモートワークハンドブック、オンボーディングに関する情報をまとめたオンボーディングハンドブックも参照ください。 読み始める #以下のボタンから本編に進めます
エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita
Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー（以下、EM）としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。 ある時、先輩との1on1で、「（メンバーとの1on1やメンバーの育成を）どうしてそれをやるのか」と問われ
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
Deportare Partners｜デポルターレパートナーズ
Creating the possibilities of humans and society, Like sports. CEO Dai Tamesue 人間と社会の可能性を拓く、 スポーツのように。 タイムというはっきりとした結果が出る競技を追求しながら、人間の限界はどこにあるのだろうかと考え続けてきました。伸び悩んだり、重圧に苦しんだりする中で、限界は自分自身の思い込みが作っているのではないかと、そう思うようになりました。 社会を見渡せばそんな出来事が溢れています。思い込みによって制約がかかり可能性が狭まっている。自分がスポーツと向き合ってきた方法が、人間と社会の可能性を拓く上で活かせるのではないかと思い、会社を始めました。 私は「スポーツとは身体と環境の間で遊ぶこと」だと定義しています。遊びには計画も、義務もありません。面白いから行われる自由な活動です。そんな「遊ぶ」という感覚が
【Team & Project】LINE全社のデータ基盤のミドルウェアやData ingestion pipelineの開発・運用を担当しているチームを紹介します
―― 今のチーム課題と課題解決に向けた取り組みを教えてください。 Wang：私たちのチームでは、主に3つの課題について取り組みを進めています。 まずは1つ目の課題は「マルチテナントのクラスターの運用」についてです。 Hadoopは一般的に、有数のユーザと予測可能なワークロードで運用されていますが、LINEのData OpenによってDAUが700人弱であり、且つワークロードも10万+/日となっています。Isolationがまだ完備されていないので、ユーザ間にリソースの競合が発生している状況です。 2つ目は「Data catalog」についてです。ユーザが自由にデータを生成したり利用したりする環境においては、データのカタログがとても重要です。そのため、Data Lineageを自動的に生成する仕組みが必要となってきます。 そして「大規模のインフラを効率よく運用すること」も私たちの課題です。私
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
テレワークで始めたドキュメント駆動業務｜Dentsu Digital Tech Blog
こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様
視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
1人で成し遂げるということについて｜Keisuke69
先日、とある内容についてツイートしたのですが、それが思ってたよりいろんな反応をいただいたので今日はそれに関して、ツイートでは伝えきれなかったことなども含めてもう少し詳しく記したいと思います。 まず、ツイート自体はこちらになります。 面接してると時折、『1人で全部やりました！』『できる人が他にいないんで自分だけでやりました！』みたいな話をしてくれる人がいるんだけど、正直なところ1人で全部やるのも大変とは思うけどチームで成し遂げるほうがよっぽど大変だと思うの. 人は思う通りには動かないわけで… なので評価しづらい — Keisuke Nishitani (@Keisuke69) January 31, 2020 これは採用に関する話でして、面接などをしていく中でよく感じることについてぽろっと呟いただけです。そんな感じだったこともあって140字では詳細に文脈など伝えることは当然無理です。したがっ
チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマスターをやっていることも影響しています。ともすると「仕事 = コードを書く」という意識に傾きがちな自分への
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
心理的安全性を 0から80ぐらいに上げた話
