タグ

managementに関するshin0Oのブックマーク (76)

  • なぜなぜ分析は、危険だ | タイム・コンサルタントの日誌から

    「なぜなぜ分析」は、品質管理や労働安全管理などの分野で、よく用いられる手法だ。発生した問題事象の根原因を探るために、「なぜ?」「なぜ?」とくりかえして掘り下げていく。この問いかけを“5回はくりかえせ”と、よく指導しているため、別名「なぜなぜ5回」とも呼ばれる。元々、トヨタが発祥の地であり、トヨタ生産方式の普及とともに、他の業界や分野でも使われるようになった。 図は、トヨタ生産方式の生みの親である大野耐一氏の著書から一例をとって、図示したものだ。工場内のある生産機械が故障してとまったとき、「なぜ機械は止まったか?」の問いに、「オーバーロードがかかって、ヒューズが切れたからだ」と答えただけでは、じゃあヒューズを交換して再起動すればいい、という答えしか出てこない。 しかし、なぜオーバーロードがかかったのか?→ (2)軸受部の潤滑が十分でないからだ、とほりさげ、 さらに (3)潤滑ポンプが十分組

    なぜなぜ分析は、危険だ | タイム・コンサルタントの日誌から
  • 上司が信用できない会社の内部統制 - slideshare

    第32回WebSig会議「便利さと、怖さと、心強さと〜戦う会社のための社内セキュリティ 2013年のスタンダードとは?!」2013年3月9日 http://websig247.jp/meeting/32/ チームラボ佐伯さん,高須さんの発表資料です。Read less

    上司が信用できない会社の内部統制 - slideshare
  • SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ

    ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から

    SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
    shin0O
    shin0O 2017/04/12
    レビューという名前ついてるけどいわゆるコードレビューを指すのではない と気がつくまでちょっとかかる
  • 誤解していたポモドーロテクニックと本当の威力 | RickyNews

    ポモドーロ法は割と有名なテクニックかなと思います。 時間を作業25分 + 休憩5分=1セットとして、繰り返していきます。 こうすることにより「時間を分割して、集中力を上がる」という訳です。 昔に実際に使ってみて、「まぁ・・・無いよりはあったらいいのかな」くらいの感覚ではあった。 Macにはポモドーロタイマーは入っているものの、気休め程度に入っている程度だった。 実践者の日語のブログの記事をみても ポモドーロがあると集中出来る 勉強がたくさん出来るようになった 必ず休憩が入るので、集中が長続きする くらいの浅い記述しかない。実際に自分もこのテクニックについて深く掘り下げようと思ってもいなかった。 実際の活用方法は全然違った。 きっかけはSoft Skills きっかけは最近、日語翻訳が出た「SOFT SKILLS ソフトウェア開発者の人生マニュアル」というでの記述。ここの記載で考え方が

    shin0O
    shin0O 2017/03/09
    規定数やったら今日はおしまい か
  • プロダクトマネージャーについて - naoyaのはてなダイアリー

    Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの・・・い

    プロダクトマネージャーについて - naoyaのはてなダイアリー
  • プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう

    両方ともPMと略されるため混同する人が多いが、プロダクトマネージャーとプロジェクトマネージャーは明確に役割が異なる。 Quoraに素晴らしく簡潔な回答があったので引用して紹介する。 Product managers own "What" and "Why". Project managers own "How" and "When". (a simplification, but generally holds true) Ian McAllister's answer to What's the difference between a Project Manager and a Product Manager? - Quora プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持ち、プロジェクトマネージャーは、「いつまでに作るか」「どうやって作るか」に責任を持つ。 別の言

    プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう
  • プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう

    KAIZEN platform Inc. 技術顧問 伊藤直也さんの、プロダクトマネージャーに関するツイートがとても示唆に富んでいるのでまとめさせていただく。 ソフトウェアエンジニアのひとがなにかと口うるさいの、組織的な怠慢のツケをはらう羽目になるのがだいたい自分たちだから、というのはあるだろうね。ごまかしがきかない仕事だし — Naoya Ito (@naoya_ito) 2015, 10月 21 良く見る典型例は、企画とか品質を保証する仕事までエンジニアに丸投げして、エンジニア側にはその期待値がなくてお互いの思惑がずれる、みたいなケースだな。この場合にエンジニアがしょぼいものを作るから、と指を指されてるけど、問題は製品企画開発の責務を組織の中で曖昧にしてるところにある — Naoya Ito (@naoya_ito) 2015, 10月 21 たまたまエンジニアの中にそこまで含めて上手な

    プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう
  • スキルマップ作成のすすめ

    チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★:エース、◎:得意、○:一人でできる、△:助けがあればできる、空欄:できない、・:今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果:スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます

    スキルマップ作成のすすめ
    shin0O
    shin0O 2016/01/28
    人事評価と絡めない・全社共通のスキルマップにしない(プロジェクト単位)
  • 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013

    2013年の DevLOVE 甲子園で発表したスライドを発掘したのでアップロード。当時は某 SIer に所属。当時の上司、先輩、同僚、後輩に感謝しています。

    凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013
  • アジャイル界隈研修の感想まとめ

    自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと

  • 残業は悪か?あるいは日本人の生産性が低い最大の理由

    最近、残業をするのは社員が悪いというような記事を見たので、一言言っておこうと思う。 残業常習者が会社を壊す|トンデモ人事部が会社を壊す|ダイヤモンド・オンライン なぜ残業が常習化するか 最初に結論を言ってしまうと、経営が悪いからだ。経営と言っても事業戦略ではなく、組織運営という意味での経営だ。残業が常態化しているということは、組織運営ができていないことの証拠だと言っていいだろう。 なぜ残業の常態化が経営の失敗だと言えるのか。残業が常態化しているということは、組織がこなすべき仕事に対して人員が足りないことが原因として上げられる。人材の確保に失敗しているのは、経営側の失敗だ。 もし社員がダラダラと残って働いているのだとしたら、社員が何をすべきかということがトップダウンで明確に指示されていない兆候かも知れない。何をもってその日の業務が終わりだ判断とすれば良いのか。それは上司からの指示、つまり担当

    残業は悪か?あるいは日本人の生産性が低い最大の理由
  • 採用プロセスを真剣に考えろという話

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

    採用プロセスを真剣に考えろという話
  • プロジェクトが失敗する10の兆候

    今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

    プロジェクトが失敗する10の兆候
  • 列管理と、群衆管理の違い

    最初に言っておくと、この問題に正解は無い。 なぜなら、管理する側は明確でも、管理される側(つまり並ぶ人)は素人さんだから。 並ぶのを管理する方と、並ぶ方の、双方が訓練を経て、初めて管理が成功するようになる。 これは、切符の購入から店の限定販売、施設への入場に至るまで全て同じ。 まずは列管理からルール違反者を弾けるかどうかがキモ。 例えば徹夜はしないでね、に対して、徹夜組200名です、だと、これを弾くのは難しい。 店側にボディーガードが100名詰めてます、とかなら行けるだろうけど。 なので、「ルール違反者を極小数にする」のがポイントになる。 例えばコンビニの列に横入りする人、みたいなのは店員が1人で注意してもなんとかなる。1対1だから。 これが、例えばプレステ5を買う列に20人が大量横入りする、だとシステムで対応しないと個別じゃ弾けない。 色んなお店が頭を悩ませて、整理券だとか抽選だとか事前

    列管理と、群衆管理の違い
    shin0O
    shin0O 2015/08/07
    (行ったこと無いので伝え聞く限りでは)コミケは参考にしちゃイカんと思う。 なので "並ぶのを管理する方と、並ぶ方の、双方が訓練を経て、初めて管理が成功するようになる。" は確かにそう思った
  • 列管理の難しさとコツ

    毎月1000人程度の行列を従業員4~5人で捌いてたコツを書くよ。 職業:パチ屋(嫌いな人ごめんね) 行列の理由:新台のオープンと、あとはなんでかしらないけど毎月ある特定の日に行列ができた。(諸般の事情により理由は答えられません。) パチンコ屋さんが整理券を配る理由は、開店時間前後に行列をつくると隣接店舗の入り口を塞いでしまうという問題を回避したいとう目的が一番にあります。 そのため、隣接店舗がオープンする前に整理券を配布して、行列を捌いてしまおうとしているのです。 はじめのうちは早朝から並び始める程度だった行列は、加熱していくことで徹夜組を生み出します。 なかには前日の21時、お店が閉店する前から並び始める人もいました。 話題性目的で容認していたものの、ある日おまわりさんからお叱りを受けます。 ピンとくると人も多いと思うのだけど、数年前に突然行列の深夜組に対する指導が厳しくなった時期があり

    列管理の難しさとコツ
  • 残業しない会社のつくりかた - ゆとりずむ

    こんにちは。 以前、とりあげた記事が、気がついたら1000ブックマークをこえていてびっくりしました( ゚д゚) 色んな人に共有されて良かったなあ(∩´∀`)∩とのんきに考えていたところ、ある方から連絡を頂きました。 おいこら、勝手に何しとんねん(^^) 昔ネトゲで仲良くなった、この会社の役員様からでした((((;゚Д゚))) あ、すんません消しときます(´・ω・`) まさかここまでシェアされるとは思わず・・・。企業秘密だったりしました?と言ったところ いやー、別にかまへんよ。親父がみんなに愛されてて面白かったわ。 と、あっさりOKを頂きました。わたしと同い年でも、二十歳で役員に任じられた男は懐の深さが違いますね。(ちなみに、社長さんの息子ではありません) ただうちは、『世の中の人がまだ見つけていない、技術の新しい活用法を発見する』ことに軸足をおいてきた会社。いい仕事をするために、働きやすい

    残業しない会社のつくりかた - ゆとりずむ
  • あるシステム屋さんが平均残業時間一桁を実現した方法 - ゆとりずむ

    こんにちは。 ここしばらく、システムトラブルの対応で午前帰りが続き、疲れてきてしまいました・・・。直接、トラブルの原因になった訳では有りませんが、エンジニアさんも巻き込んでしまい、もう少し上手く回す方法はなかったのかと、自分の未熟さを反省中です。 さて残業といえば、先生は大変そうですね。ただでさえ、ひとりで何十人もの生徒をみないといけない上、ほぼ無償ボランティアの部活顧問まで行い、その上で親に押しかけられたら溜まったもんじゃ有りませんよね。横浜市で、先制の『ノー残業デー』を設定するそうですが、多少なりとも状況が改善することを期待してやみません。 ただ、個人的にはこの『ノー残業デー』という制度がしっくり来ません。だって、『ノー残業デー』って、その日以外は残業することが前提なワケですよね?更に、こんなニュースも有ります。 正社員と同じ等級制度や人事制度を用いるため、基給も同じ水準だ。賞与は正

    あるシステム屋さんが平均残業時間一桁を実現した方法 - ゆとりずむ
  • 今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy

    主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニア仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最

    今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
    shin0O
    shin0O 2015/06/23
    "意思決定者が近くにいて、利害の一致度合いが高い状況" ってあんまり聞いたことない あとprjってすげえ目につく
  • Kaizen Platform における UI ライブラリのワークフロー

    関西フロントエンドUG 主催の「フロントエンドで考えるWebデザイン/UI勉強会 (http://kfug.connpass.com/event/15244/ )」で発表した内容です。

    Kaizen Platform における UI ライブラリのワークフロー
  • 『なぜエラーが医療事故を減らすのか』はスゴ本

    「バグを排除しようと圧力をかけると、バグが報告されないプロジェクトになる」 この寸言は、よく忘れられる。シックス・シグマや日経ナントカに染まった管理者が、バグを目の敵にし、バグゼロの号令をかける。不具合が表面化すると、たまたまそこに詳しいだけの担当を犯人扱いし、なぜなぜ分析を強要し、ccメールや全体会議で晒し者にする。 なぜなぜ分析とは、「なぜそれが起きたのか?」「その原因の原因は?」と、原因を幾重にも掘り下げる手法のこと。5段階も遡及すると、たいてい「私の不注意でした」となり、対策は「意識を入れ替える」という小学校の学級目標になる。反面、もっと深刻な「仕様変更が電話口で伝えられていた」とか「アジャイルの名のもとにテストが省略されていた」などは放置される(なぜなら、「人」を原因にしたいから)。 こんな冗談みたいな施策を続けていくと、スケープゴートになった人はどんどん心をすり減らし、不具合の

    『なぜエラーが医療事故を減らすのか』はスゴ本
    shin0O
    shin0O 2015/06/19
    でもエラーが起こったら誰かに責任とらせるんならなあ