タグ

ブックマーク / www.ryuzee.com (6)

  • 組織やチームづくりに役立つ20冊

    こんにちは。@ryuzeeです。最近、組織やチームのことを考えるヒントになるを紹介してほしい、と言われることが多いのでダンプしておきます。あくまで自分で読んだ私見で選んだものなので、この定番がないのは何故だとかはあると思います。 定番 ピープルウエア 第3版著者/訳者:トム デマルコ;ティモシー リスター、松原 友夫;山浦 恒央;長尾 高弘出版社:日経BP社発売日:2013-12-24Kindle版:158ページISBN-13:ASIN:B00I96CJWO 「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」とあるように、ソフトウェア開発における問題点を人間の観点で整理している名著。第IV部では生産性の高いチームを育てるというテーマで機能するチームの特徴やチームの壊し方(守りのマネジメント・官僚主義・作業場所の分散・時間の分断・品質の削減・はったりの

    組織やチームづくりに役立つ20冊
  • 【資料公開】強いチームの作り方 | Ryuzee.com

    2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

    【資料公開】強いチームの作り方 | Ryuzee.com
  • 採用プロセスを真剣に考えろという話

    人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか?」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか?」期待値を明文化している

    採用プロセスを真剣に考えろという話
    miya-jan
    miya-jan 2015/12/25
    よくまとまっている
  • 【我流】プレゼンテーション資料の作り方

    全国100万人のブリよりワラサ好きのみなさんこんにちは。先日強いチームの作り方を公開したのですが、何人かの知り合いからこういうスライドの作り方教えてほしい、というリクエストを受けたので以下にダンプしておきます。 参考書籍以下にあげるは一度読んでおいて損はないです。プレゼンテーションZenは、ピアソンが技術書の取り扱いやめてしまい絶版かと思ったけど第二版が出て何より。 ガー・レイノルズ シンプルプレゼンプレゼンテーションZEN 第2版プレゼンテーションZENデザインこれらのの中でも出てきますが、「プレゼンテーション」と「ドキュメント」は明確に分けた方がいい。 よく会社で経営方針とか数字とかをパワーポイントで作って配りますが、単にデータや説明を見せるならそれこそワードでやった方が読みやすいしコンパクトです。 トヨタがA3用紙1枚でまとめる(最近そうでもないらしいですが)と聞きますが、それと

    【我流】プレゼンテーション資料の作り方
  • 目標ベロシティとベロシティのインフレ | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめしません。 それは以下の理由からです。 そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまうもちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはありますが、それはあくまで結果としての指標データです目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多々ありますいくつかのスプリントをこなせばチームとしての生産力は見えてくるので、数字をコ

    目標ベロシティとベロシティのインフレ | Ryuzee.com
    miya-jan
    miya-jan 2014/08/29
    ベロシティを目標にするのは危険という話。
  • なぜWIPの制限が重要なのか

    みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2. タスクの切り替えが減る一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬

    なぜWIPの制限が重要なのか
    miya-jan
    miya-jan 2013/12/01
    サイクルタイムが短くなる利点とか
  • 1