1on1を上達するために
PMBOK Guideに欠けている、３つの重要事項 | タイム・コンサルタントの日誌から
春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。 PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにす
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
「事実」と「解釈」を明確に区別しない会議は、恐ろしく効率が悪い、という話。
今回は私が会議のファシリテーションを行う上で最も重視していることの1つ、「事実と解釈の区別」について、書いてみたいと思います。 最初に確認しておかなければならないのは 「事実」と「解釈」 のちがいについてです。 例えば、「スターバックスの店舗はあちこちにある。」 「これは事実でしょうか？ それとも、解釈でしょうか？」 と問われて、皆様はどのように答えるでしょう。 読者のあなたは、「もちろん解釈です」とお答えになると思います。「あちこちにある」という言葉は、人それぞれの解釈に委ねられているからです。 その通り、これは解釈です。 それでは「セブンイレブンは大手企業です」は事実でしょうか、解釈でしょうか？ …… こちらも読者諸兄の方にはすぐに分かってしまうかもしれませんが、もちろん、これも解釈です。「大手」という言葉が何を指すのか、人の主観が入っているからです。 「いやいや、それは屁理屈だろう。
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
マネジメントって何すればいいの〜？1年間マネジメントに向き合ったのでまとめを書きます - Qiita
はじめに こんにちは！Supershipの永田ゆにこです！「Supership株式会社 Advent Calendar 2016」の20日目を担当します（^o^）今年は会社のやつに参加するぞ〜！ これからマネジメントやらなきゃいけない人や、同じように困ってる人にぜひ読んでほしい！めちゃくちゃ長いです。 前置きと振り返り さて、これまでは二年連続でGitに関することを書いてきました。Gitが使えるデザイナーブランディングをしていたんですね〜。いまやデザイナーの人がGit使うのは普通になってきた印象です。便利すよねえ。 去年の書いたのはこれ Gitとわたしとデザイナーと 〜2015年Gitの思い出〜 その前書いたのはこれ デザイナーがこうやってGit覚えて大好きになったよ♡ てな感じで少し前はデザイナー&ディレクターをしていたのですが、最近はだんだんプロデューサー&マネージャーぽい感じに変わっ
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
見えない非効率 ー 今、動いているんだからいいじゃないか | タイム・コンサルタントの日誌から
新任の取締役が、あるとき担当する事業部の支社を見に行った。一通り見学し、支社長らと懇談した後、かえろうとしたら、ある部署だけ灯りがついているのを見つけた。現場仕事はもう終業しているのに、管理部門の1セクションだけ、忙しそうに机にむかって仕事している。 「何をしているの？」と彼がたずねたところ、「本社に送る書類を作成しているんですよ。毎月、数字をまとめて送らなけりゃいけないんで、残業になるんです。」との答えだ。資料を見て、さらにたずねる。「本社は、この統計資料を見てどう役立てるんだろう？」「・・存じません。本社にたずねてください。」 その取締役は本社に戻ると、早速、送付先の企画部門にいって、その書類のことをきいてみる。すると、「ああ、その書類ですか。工場が毎月送ってくるんでね、ファイルして保管しているだけです」という。「でも、なんで工場はその書類を送ってくるのかな？」「さあ・・。」 いろいろ
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
ボトムアップ組織のマネジメントとは何なのか
いま所属している会社は、ボトムアップな会社ということになっている。正確にはボトムアップとトップダウンが混在していてたまにミスリーディングなのだが、だいたいはボトムアップな会社といえるだろう。 それで、たまに、学生と会ってくれといわれて、うちの会社がボトムアップの会社なんですよ〜、と話すことがある。だがこのボトムアップというやつ、採用活動では『いかに若いうちから活躍できるか』をぐいぐいアピールするための文句ではあるのだが、実際、現場でどういうコミュニケーションになっているのか、あまり説明されない。どういう会社が「良い」ボトムアップの会社なのか、わりとみんな意識していない。 とりあえず適当に若いのに丸投げてみたら、いつの間にかイケてる提案を持ってきた、なんてことは、ありえない。それを実現するためには、上司側の見えない努力がたくさん必要なのだ。 こんなマニアックな話をしている人は多くないと思うの
プロダクトマネージャーに訊く #4：Kaizen Platform瀧野さん（後編） - 小さなごちそう
チーム開発を成功させるためのプロダクトマネジメント ― 最近、日本でもプロダクトマネジメントが注目されていますが、その理由はなんだと思いますか？ 小さいチームでも大きな影響力を持ちうることや、チームの力を最大化することで新たな価値を生み出せることに、皆んなが気づき始めているのでしょう。その手段の一つとしてプロダクトマネジメントが注目されているんじゃないかというのが個人的な見立てです。 チームの重要性はスタートアップであれ大きな会社であれ変わらない。少し前に「ビジョナリー・カンパニー」がトレンドになったことががありましたがビジョンやイノベーションの重要性が先行して注目されて、それを実現するチームを支える役割としてプロダクトマネージャーが必要とされるようになったのではないでしょうか。 ― もともと個人でビジネスをしていた瀧野さんがチームの重要性に気づいたのはどんなきっかけがあったのでしょうか。
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。 - Qiita
「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用（業務委託含む）する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マネジメントのテクノロジーを考える