プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
属人化問題と、プロジェクトの「加速時期」/「速度を落とさない時期」 - 圧倒亭グランパのブログ
社内の方と雑談する中で、「属人化」に対する一つの考えがまとまったので書きます。「属人化排除のやり方」ではなく、「属人化排除を考える時期」についてです。 「属人化排除」というアプローチで感じたこと 「属人化排除」は大事だと思います。人的SPOFをなくすのは強いチームを作る上で重要です。しかし最近、複数のプロジェクトに関わっていく中で、「プロジェクトの時期によって属人化排除の優先度は変わる」ということを感じました。 あるプロジェクトXがAさんとBさんを中心に回っていました。そこは結構な属人化が起きていて、ほぼAさんとBさんしか仕様がわからず、他の人がコードを触るのは難易度が高くなっていました。当初は「このままで大丈夫かな」と思っていたのですが、よくよく考えると「あぁ、今はそういう時期だ」と感じました。この感覚を今回は言語化しようと思います。 プロジェクトの「加速時期」と「速度を落とさない時期」
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？：プロジェクトマジック：オルタナティブ・ブログ
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？ 2015年12月に「会社のITはエンジニアに任せるな」という本を出した。 「経営にとって、ITとは？」がテーマの本なので、「ITを担わせる人材をどう育てるべきか？」という章をもうけたのだが、意外だったのは、「プロジェクトリーダーとプロジェクトマネージャーの違い」という短いコラムへの反応が多かったことだ。 実は用語の混乱を避けるために書いただけなのだが、結構本質的な問いかけも混ざっている。この記事で、少し掘り下げてみたい。 ※以下、プロジェクトマネージャー⇒PM、プロジェクトリーダー⇒PLと表記する ★何が混乱の元なのか？ 大きめのプロジェクトだと、たいてい体制図が作られ、色んなカタカナの役職の人が登場する。ただ、この手の役職名は会社ごとに定義がマチマチなので、毎回関係者間で「これって結局
「PoC」の進め方──メンバー選定、環境構築、データ収集と活用、評価まで
「PoC」の進め方──メンバー選定、環境構築、データ収集と活用、評価まで：「ビッグデータプロジェクト」の進め方（2）（1/4 ページ） 本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくためのナレッジアーカイブです。今回は、導入前検証である「PoCの進め方」全8工程を解説します。 「ビッグデータプロジェクトを始めることになった」ら、何をすればいいのか──。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくための導入指南です。 前回は、ビッグデータおよびビッグデータ基盤の概要について、そしてその第一歩として「小さくても、確実な成功を収めることが重要である」と説明しました。今回はこの第一歩を踏み出すに当たって必要となる、「PoC」（Proof of Concept：導入前
「要するにこういうこと」と言う人こそがリーダーである、あるいはアイディアを蒔く土壌について：プロジェクトマジック：オルタナティブ・ブログ
僕は三枝匡さんの「変革三部作」の大ファンだ。 企業経営や変革プロジェクトのロジックとパッションの両方がぎっしり詰まっているので、今でもたまに読み返す。 ちなみにこの三部作を担当している日経新聞のの編集者に、僕の1冊目2冊目の編集もお願いした。特に1冊目は実際の企業変革を当事者が物語形式で振り返る本なので、「三部作の中間管理職版」だと思って書いた。三枝さんと違って、僕らの本はすべて実名だけれども。 その三枝匡さんがCEOとしてミスミの改革を振り返った本が出たので、早速読んでいる。 まだ途中だが今の時点で一番ぐっときたのが、 ・ビジネスの混沌を読み解き、「この課題って、要するにこういうことでしょ」と言え ・これは、企画書の1枚目（変革の出発点）として、極めて重要 ・これを言う人こそがリーダー（未来を示し、導く人）である という箇所。 似た話は工業デザイナーの山中俊治さんも書いていた。 自分の言
続・アジャイルで人はどう育てるんだろうか - novtanの日常
色々ブコメ頂いたので、紹介がてらいろいろ考えたいです。 予めテーマを絞っておくと、教育にコストがかかる前提において世の中のプロジェクトが全部アジャイルになっちゃったら教育コストをどこから捻出していくイメージなのか、ということと、プログラミング以外のところがどういうプロセスで身についていくのか、というのが僕の関心の主眼です。 id:greencoffeemaker アジャイルをやるには、ある程度のレベルでシステムを修正できなくてはならないのがキツイ。場当たり的なコードで埋めたり、ガチガチに組まれたFWで業務処理だけ書けるというスキルではなかなか難しいのは実感ある。 やっぱり感覚としてはこういうところはあるんですよね。そこに到達するまではお荷物な部分を誰かがフォローするのか、余剰工数でやるのかってところですよね。 id:wwolf アプレンティスシップ・パターンを読もう（要するに徒弟制度） 読
進捗管理は下っ端がやる仕事、あるいはファシリテーターとしてのPMO：プロジェクトマジック：オルタナティブ・ブログ
プロジェクト内に「PMO」という部署を設けるケースがある。 大規模プロジェクトではPM（プロジェクトマネージャー）のタスクがあまりにたくさんあり、とうてい1人PMではやりきれない。だから何人かで分業するためのチームを作る。それをPMO（プロジェクトマネジメントオフィス）と呼ぶ。 で、もちろんプロジェクトの成功にとって大事なのは、PMOを作ることではなく、PMOが何をやるかだ。 他社の人とこの話をしていて、全然咬み合わないことが多い。僕らの考えるPMOの仕事よりも、彼らの考えるPMOタスクはかなり狭いのだ。 もっとはっきり言うと、普通の人が考えるPMOのタスクって、僕らが考えるPMOタスクのうち、一番簡単で、普通は下っ端（PMOチーム内で一番経験が浅い人）にやってもらう仕事だけのことが多い。 「いや、違うんです。プロジェクトの成否を分けるのは、その先なんです」と言いたくなる。 僕らは、この狭
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
