Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
「人間より組織構造にフォーカスを」伊藤直也が解く、チームなのに“1人”になってしまう謎
チームなのに「1人」になってしまう構造 伊藤直也氏（以下、伊藤）：ちゃんと作っていくものやミッションと組織の構造をきちんと合わせていきましょうというのが、マネジメントの基本としてものすごく大事です。しかし、形を合わせただけでは、その通りに機能してくれないことがあります。 これはKaizen Platformにいたときにあったことですが。Kaizen Platformは内製組織らしく、さっきみたいにプロダクトマネジャーが真ん中にいて、エンジニアがいて……という構造になっていて、各ユニットごとにきちっと切ってありました。 しかし、よく見ると、各ユニットのなかではエンジニアが3人くらいずついますが、エンジニア同士があまり一緒に仕事をしていないんですよね。 そこで、エンジニアと1:1の面談をして「最近どう？」と聞くと、「う～ん、なんか最近1人で仕事している感じですね」とみんな言っていて、「あれ、な
「ブラタモリ」の裏側は現場力を持った最強チームが作っていた。 - 十三のいま昔を歩こう
「ブラタモリ」が大阪にやってきた。 【ご報告】 大変光栄な事に案内人の１人として出演しております。 最初に連絡をいただいたのは真夏の７月。はじめてお会いしたディレクターさんは女性の方で、炎天下の中を午前中から日が暮れるまで上町台地を中心に、空堀商店街や真田丸跡、通天閣などを2日間ご案内しました。歩数を確認すると25,000歩と30,000歩。よく歩きました。その後、８月後半にもう１人のディレクターさんが加わり、その方もご案内しました。その時は1日でなんと38,000歩。今回は私以外にも大阪の歴史をずっと研究されている方々も案内人として出演されます。ブラタモリの台本はこのディレクターさん達が自分の足で歩き、調べ、様々な方とお会いして話を聞き、作り上げています。プロデューサーの方々は、その台本をさらに良くするためにアドバイスをし、撮影から仕上げまでのすべての責任を持たれています。 この番組の特
運用の問い合わせチケットを10分の1に削減した話 - Qiita
Help us understand the problem. What is going on with this article? 会社で働いていると、運用チームからの問い合わせがあると思います。 問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。 Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。 常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。 問い合わせが多くて辛みを味わっている方の参考になれば。 概要 Web自社サービス タスク管理ツール Redmine 毎日、5枚ほどチケットが増える 運用と開発がそれぞれ20人ほど こんな環境です。 改善のきっかけ うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。 窓口の人がチケットを解決したり、有識者にチケットを委譲した
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
ミニマムリリースを意識していたらコードが肥大化していた話 - 弥生開発者ブログ
Misoca開発チームの黒曜です。 仙台へ温泉旅行に行ったついでに、アースキャンディが一時期話題になっていた仙台市天文台に足を伸ばしてみました。 常設展示やプラネタリウムも良かったのですが、なにより口径1.3mのひとみ反射望遠鏡が大迫力で素晴らしかったです。 夜は温泉宿へ行ったので観望会には参加できなかったのが残念でした。 Misocaならリモートワークができるので、いっそ仙台に長期滞在してみようか… 受発注機能とミニマムリリース さて、Misocaでは最近、受発注に関する機能を強化しています。 このブログを書いている時点で見積書をメールで送信すると、サイト上で見積に関するやりとりや発注を行えるようになっています。 しかし、受発注に関する一番最初のリリースは「通常の見積書受信画面に発注ボタンが出て、発注通知を送れる」というだけの大変シンプルなものでした。 受発注に関する機能はなるべくミニマ
他のチームに｢技術的支援｣をする時に気をつけていること - Masteries
自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります. 最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません. そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより
他人と自分を比べないこと - WETな備忘録
今にいたるまでずっと、他人と自分を比べて、そして自分が優れていたときの優越感と、自分が劣っていたときの劣等感を、そういう臆病な自尊心を、原動力に生きてきたように思う。 しかし今は、少しずつだが、他人と自分を比べない方法を見つけつつある気がする。 自分の原動力が自尊心であることに気づき始めたのは2年前の夏だったようだ。 まさにこの数日後、僕は当時所属していた会社から、今の会社に転職することになる。社員数は、1500人から、15人になり、エンジニアは5人に満たなかった。 win as a team, win as a result プログラミングに触れてからまだ3年経っていなかった僕は、スタートアップのエンジニアである彼らの高い技術力についていくのに必死だったし、居場所を自覚するために業務にいち早く貢献したかった。 そういうとき、自分の評価を気にするあまり能力を偽って（強がって？）大きく見せる
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
JJUG CCC 2015 Fall 2015-11-28T15:00-15:50 の発表資料です。 話せなかった分は切りましたが、言いたいことは言い切っています。
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
「だから言ったのに」と言う人の言葉を無視してはいけない | サイボウズ式
マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！ サイボウズ式編集部より：著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただく「ブロガーズ・コラム」。はせおやさいさんが考える「チーム運営で意見を1つの視点ととらえることの大切さ」。 こんにちは。はせおやさいです。 「失敗は成功の母」と言いますが、失敗から学ぶことは思った以上に多いものですね。「失敗しないこと」よりも「失敗したとしてもそこから有益な知見を得られた」というほうに注目していく
リモートチームのメンバーが気をつけている常識ではありえない４つの習慣 | Social Change!
リモートチームとは、物理的に離れた場所で働きつつもチームワークを発揮して、チームで助け合って成果を出していく働きかたです。私たちソニックガーデンでは、リモートチームを５年以上続けてきました。 この記事では、私たちが経験から学んできたリモートチームを実現するときにメンバーが気をつけておくと良いだろうと思う４つの習慣について書きました。 １）仕事に関する「雑談」をして連帯感を出す習慣 チームビルディングの第１歩は、チームを構成するメンバーをお互いに仲間だと認識することから始まります。それはたとえリモートチームであっても同じことです。 もしオフィスにいれば、飲み会や食事の機会があったりして、お互いのことをなんとなく認識することが出来るのかもしれませんが、リモートではそうはいきません。 そこでリモートチームでは、互いに認識しあう機会として、あえて仕事の合間に雑談をするよう気をつけています。雑談とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
ヒーローは高くつく - 火消しの文化を消滅させる
