「ついカッとなって……」取り組んだ"開発者のための開発"で業務効率を改善させた話 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ついカッとなって……」取り組んだ 開発者のための開発 で業務効率を改善させた話 ソフトウェアエンジニアの醍醐味は、華々しい働き方のみにあるものではありません。開発者のための開発など、地味かもしれないけど楽しくやりがいのある仕事について紹介します。 アプリケーションエンジニアの id:aereal です。はてなで働いています。 昨今は機械学習などが半ばバズワードと化し、「トレンドを追いかけなければソフトウェアエンジニアとして生き残れないのではないか」という漠然とした不安に襲われることはないでしょうか。 これという専門分野の技術を活かし、所属する企業やひいては社会へ貢献するというあり方は、技術職として華があり憧れを誘うものです。 しかしソフトウェアエンジニアの醍醐味はそういった華々しい働き方のみにあるものではなく、むしろその他の様々な分野にたくさん散りばめられていると筆者は考えます。 この記
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。
伊藤直也さんの一人CTO Nightに一人で行ってきた - comix
巷で話題？のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。 イベント詳細： https://doda.jp/event/seminar/20160830.html オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。 もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。 では、早速。 第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは？ 【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。 前提として、、、 50〜300人くらいの規模の組織が対象 CTOのマネジ
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
書評: Site Reliability Engineering
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
組織やチームづくりに役立つ20冊
こんにちは。@ryuzeeです。最近、組織やチームのことを考えるヒントになる本を紹介してほしい、と言われることが多いのでダンプしておきます。あくまで自分で読んだ私見で選んだものなので、この定番がないのは何故だとかはあると思います。 定番 ピープルウエア 第3版著者／訳者：トム デマルコ；ティモシー リスター、松原 友夫；山浦 恒央；長尾 高弘出版社：日経BP社発売日：2013-12-24Kindle版：158ページISBN-13：ASIN：B00I96CJWO 「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」とあるように、ソフトウェア開発における問題点を人間の観点で整理している名著。第IV部では生産性の高いチームを育てるというテーマで機能するチームの特徴やチームの壊し方(守りのマネジメント・官僚主義・作業場所の分散・時間の分断・品質の削減・はったりの
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏（Ryuzee.com）。 吉羽と申します。いままで野村総
Aiming小林俊仁氏が、よりよいチームを作るために参考にしている本【連載:エンジニアとして錆びないために読む本】 - グノシー
お探しのページはみつかりません一時的にアクセスできないか、移動、削除された可能性があります。
チーム開発で感じた大事にしたい要素8つ | DevelopersIO
はじめに 普段はスマホアプリのチーム開発をメインでやってます。正直昔はチーム開発とかいう言葉自体好きじゃなかった‥はずの中2です（今は好きですよ）。そんな僕ですが、チーム開発でこれ大事にしないと回ないよな、と思った事を紹介します。今回はチーム開発を助けるツールの話しではなく、ふわっとした話しです。 大事にしたい要素８つ 1.現実を受け入れる 例えば期限に間に合わない → 頑張れば少しはマシになるはず。 少しマシになるかもしれないけど、遅れる可能性があるなら先にアラートを上げてる。特に開発者やステークホルダーが多い場合に自分(達)だけが頑張って解決する問題じゃなくなる。各ステークホルダーに予め連絡してその場合の準備をしてもらう必要がある。現実を見て落下地点を計測する。 2.情報はできるかぎり公開する ≒ 開かれたコミュニケーション 現実を受け入れるとも関連。良い悪いにかかわらずこまめに情報を
「ペルソナ」を捨てて、JTBD（Jobs-To-Be-Done）モデルでターゲット顧客を定義せよ - 小さなごちそう
まずはこんな逸話から。 あるファストフード企業がミルクシェイクの売上を改善したいと思った。 ミルクシェイクの購入者属性を整理し、同一の属性を持つ人を対象に、重めがいいか軽めがいいか、フルーツ味かチョコレート味か、など、どんなミルクシェイクが理想的か尋ねた。調査はうまく進み、特定したターゲットの好みをもとに製品を改善したが、売上は全く改善しなかった。 そこで別のチームが再び調査を行った。調査チームは店舗で来客を一日中観察した。すると早朝にミルクシェイクを買う客が多いことに気がついた。早朝の購入者になぜミルクシェイクを買ったかを尋ねると、 長い車通勤の間に片手で手間なく飲める 一気に飲めないので暇つぶしになる 腹持ちが良い といった理由だとわかった。 この調査結果をもとに製品開発を再度行ったところ売上を改善することができた。 最初の従来型のマーケティングリサーチではWhat（どんなミルクシェイ
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
iOSアプリ開発にチームで取組むチャレンジ - ワザノバ | wazanova
http://vimeo.com/109624121 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Michele Titoloについて取り上げるのは、 「モバイルAPIデザインのまとめ」 「Ruby RoguesメンバとiOSエンジニアのAPI議論」 に続いて三回目ですが、今回はiOSアプリづくりにおけるチーム内の連携がテーマ。 彼女は現在、redditのiOSチームのリーダーをしながら、Objective-Cプロジェクトの依存関係の管理をしてくれるCocoaPodsの開発と、非営利団体 Women Who CodeのCEOを兼務しています。 redditはwebで大量のトラフィックとユーザを抱えてますが、スマホのアプリに注力しはじめ、切り口を変えた複数のreddit閲覧アプリづくりにチームで取組
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
PM（プロジェクトマネージャー）が読むべき５冊の本 | SEKAI LAB TIMES（セカイラボタイムス）
Posted on August 27, 2014 by KENTARO FURUKAWA /TAG: PM プロジェクトの価値を再確認するなら「クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」 言わずと知れた「ゴール」シリーズのエリヤフ・ゴールドラットがプロジェクトマネジメントに挑んだ著作です。この作品で提唱された「クリティカルチェーン」によるプロジェクト管理法は実際のプロジェクト管理システムなどでも採用され、有名になりました。 「ゴール」でも指摘されていることですが、ビジネスプロセスの中で最も弱いチェーン、ボトルネックを「解消」するのではなく、そのボトルネックを使い倒した上で、その制約に合わせて全体を進行させるという基本的な考え方は一緒です。プロジェクトではそれがクリティカルチェーンとされ、その上にあるリソースやスケジュールは余裕をもって保護されるべきという考え方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google：マネージャはやはり重要な存在である
OKR (目標と主な結果)
開発組織マネジメントのコツ - Speaker Deck
【資料公開】強いチームの作り方(デブサミ2016版)
