全員が“勉強マン”でなくていい--伊藤直也が説く「多様性ある組織の強さ」
2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏とソラコム・玉川憲氏による「お悩み相談室」が行われました。 「プロジェクト管理のための管理」は意味がない 質問者9：自社サービス開発に携わっています。チームの成長を開発速度で見られたらいいなと思っています。開発の速度を定量化できたらいいなと思いますが、何かいい指標はありますか？ もしくは同じことを考えたことありますか？ ベロシティはプロジェクト、チーム構成で定まらないので難しいなと。 玉川憲氏（以下、玉川）：チームの成長を開発……。 伊
効果的な 1 on 1 ミーティングのためにマネージャができること
2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日本語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
Teambox をCentOSの環境にインストール、構築する際の注意点まとめ | Mooty
Teamboxを自分のサーバーに入れて動かしている人はまだ少ないと思いますが、 いつかTeamboxが今より普及すると信じて備忘録を書いときます。 長くなりそうなので、今回はインストール、環境構築での詰まりどころだけまとめときます。 0.Teamboxって何なのさ？ 簡単に言うと、twitter ライクなプロジェクト管理ツールです。→公式サイト。｜ Moongiftの紹介 一般的なガントチャートなどをベースとしたプロジェクト管理ツールとは異なり、 コミュニケーション主体のプロジェクト管理ツールの元祖？であるBaseCampの影響を多分に受けてます。 本家より細かいところに手が届く感じがあるのと、インターフェースが洗練されてる感があるので、うちの会社ではこっちを使ってます。 大規模なプロジェクト管理やシステム開発には不向きですが、中小ベンチャーならこっちの方が気軽に参加できていいかもしれませ
LibrePlanの日本語化（チームで共有できるWebベースのプロジェクト管理ツール）
チームで共有できるWebベースのプロジェクト管理ツールを探してましたところ、 LibrePlanというツールを見つけました。 OnlineDemoをいじったところ、かなり使えそうな感じです。 問題は全部英語なところ。日本入力や表示は問題なさそうなので、日本語化を検討します。 LibrePlan 日本語化 でGoogleで検索をしても、１件Hitのみです。 http://libreplan-jp.skr.jp/blog/introduction/ Hideto Yoshidaさんのページに勝手にLinkさせていただきます。ゴメンナサイ。 日本語化のリソースもご用意いただいいますが、ビルド手順などが結構複雑なので、整理してみました。 大まかな手順は １）英語版をソースからビルドする手順の途中で日本語リソースを取り込んでビルドをする ２）ビルドが完了 ３）Jettyで動かす→ひとまずこれで動き
ガントチャートやWBSを備えたWebベースプロジェクト管理·LibrePlan MOONGIFT
LibrePlanは中〜大規模開発において有効なWebベースのプロジェクト管理です。 LibrePlanはまるでローカルアプリケーションのようなリッチなUIをもったWebベースのプロジェクト管理システムです。 ログインします。 ダッシュボードです。格好いいガントチャートが表示されています。 タスク同士の関連性も表現されています。 WBSです。 タスクの詳細です。 ワーカー一覧です。 どの機能もメニューから素早くアクセスできます。 ワーカーレポートです。他にも多様なレポートが揃っています。 主な機能としてはリソースマネジメント、WBS/ガントチャートを用いた計画表、各タスクのモニタリング、進捗度合いのトラッキング、APIを使ったデータ共有などとなっています。十数名くらいのプロジェクト規模であれば使いやすいのではないでしょうか。 LibrePlanはJava製のオープンソース・ソフトウェア（G
Tuleap·アジャイル/ウォーターフォールをサポートしたプロジェクト管理 MOONGIFT
プロジェクト管理もトレンドがあり、そのUIや機能が異なってきます。ここ数年はアジャイル、スクラム開発が主流でバックログやカンバンといった機能が実装されています。 Tuleapはアジャイル、ウォーターフォール双方に対応したプロジェクト管理で、エンタープライズ用途において活躍してくれそうです。 Tuleapの使い方 こちらがダッシュボードです。 プロジェクトのトップ。プロジェクト全体の様子が分かります。 レポートではガントチャートが表示されています。 タスク。関連するタスクと合わせて管理できます。 リポジトリブラウザ。Git/Subversionに対応しています。 こちらはSubversionの場合。 ドキュメント一覧。 Wiki。 メーリングリスト。 メッセージ。 フォーラム。 レポート。 Tuleapはかなり多機能で使いこなすのに時間がかかるかも知れません。しかし機能が豊富な分、使い始めて
オープンソースのかんばん式管理ツールを３つほど試してみた - Namiking.net
コンプライアンス1を重視する現場で、 アジャイルなプロジェクト管理ツールが現場で必要になったときに、 外部WebサービスなTrelloやPivotal Trackerを導入しづらいことがある。 そこで、OSSのかんばん式管理ツールをいくつか探して、 色々試して感じたことをまとめておきます。 今回試した ‘かんばん式’ プロジェクト管理ツール 以下に挙げる以外にも、OSSのかんばん式管理ツールは数多く存在するが、 機能面・とっつきやすさ・導入の容易さなどに基いて、３つだけピックアップさせていただいた。 TAIGA https://taiga.io/ Wekan (旧LibreBoard) http://newui.libreboard.com Restyaboard http://restya.com/board/ 個別のサーバーに実行環境を構築したい場合 各々デモ用のURLが用意されている
あなたのチームの「いい人」は機能していますか？
近年増え始めている xOps についてのスライドです。RevOps、DataOps、DesignOps、Customer Ops などが生まれてきている背景としてのサブスクリプション化と SaaS について、そして xOps を実現するうえで必要なフローの概念と目標設定について書いています。またこうした流れの中でエンジニアが貢献できる部分が多くなっているのでは、と考えています。
ドラクエ風スキルマップ - nemorineのブログ
あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！ まあ会社という組織ではよくありますよね（苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ～ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ！！ 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に
マネジメントとリーダーシップはどう違うか | タイム・コンサルタントの日誌から
大学でプロジェクト・マネジメントを週1回教えていることは前にも書いたが、授業は毎回必ず、前回の復習と、学生から出た質問への答えからはじめることにしている。出席シートに質問欄を設けて、そこに気になったことへの質問をかいてもらうのだ。むろん授業でも最後に「質問は？」ときくのだが、だいたいの学生はなぜかその場では質問せずに、紙に書いてくる。 いろいろ出た質問の中から、いつも「本日のBest Question」を選出し、その質問者の名前を明示してほめることにしている。良い質問を考えることは、単に回答を考えるよりも、ずっと価値があるからだ。一般に、マネジメントの問題には正解がない。正解がない中で、自分で考えて決めていかなくてはならない。これは、たくさんの正解を覚えてどれだけ早く答えるかを競ってきた東大みたいなところでは、とくに大切だ。 さて、「マネジメントとは何か」という授業をやった後で、面白い質問
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例 - Qiita
gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング
柔軟なウォーターフォールはアジャイルと見分けがつかない - arclamp
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。 講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。 資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。 確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはど
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System of Record と System of Engagement
普通の開発メンバーが リーダーになってやったこと
及川卓也からの伝言 「PMの心得3条」
