タグ

マネジメントに関するatm_09_tdのブックマーク (179)

  • モダンPMへの誘い 〜 この質問の意味が分かりますか? | タイム・コンサルタントの日誌から

    あなたは、ある化学企業の経営者だ。自社の業容拡大をはかりたいが、日の国内市場はすでに飽和しているため、海外の新興国に権益を得て、新しく化学プラントを建設することにした。 そして、これはと思う部下をプロマネに任命し、現地に派遣する。しかし、プラントはなかなか完成しない。それどころか、現地のパートナー企業の不満の声も、あなたの元に届いてくる。そこでTV会議で現地のプロマネを呼び出し、話すことにした。では、あなたがまず質問すべき事は何だろうか? ・・これは、わたしが大学などでプロジェクト・マネジメントを教える際に、よく最初に出す問いかけだ。出席者に尋ねると、いろいろな答えが返ってくる。例えば「工事はどこまで進んでいるのか」「資材は十分に足りているのか」「労働者の質はどうか」などなど。

    モダンPMへの誘い 〜 この質問の意味が分かりますか? | タイム・コンサルタントの日誌から
  • マネジメントロールになって2年目にやったことn連発 | DevelopersIO

    前回の「EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発」から、早1年半が経とうとしています。 途中「EC/CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから」で取り組みかけていたことなどはご紹介しましたが、その内容を含め、何をやってきたかの紹介を、また連発形式でご紹介しようと思います。 やったこと(順不同) 1. 仲間集め より多くの価値提供に向けて仲間を増やしたかった 採用強化に向けていろいろやった 詳細は別途ブログ化予定 リード獲得のために色々 部署紹介ブログエントリ作ったり DevIOに登壇したり 部署の取り組みを紹介したり スカウト文面見直し カジュアル面談実施 面接課題見直し オファー資料見直し 結果的に 採用枠の充足できた オファーからの受諾率100%達成 2. 人事評価基準作成 クラスメ

    マネジメントロールになって2年目にやったことn連発 | DevelopersIO
  • サプライチェーン・マネジメントとは(本当は)何か | タイム・コンサルタントの日誌から

    先週の金曜日に、東京・浜松町で開催された「ストラテジックSCMコース」の終了発表会に参加してきた。これは日ロジスティクスシステム協会が主催する、社会人向け半年コースのセミナーで、今期からわたしも講師陣の一員としてお手伝いをしている。3月の卒業式シーズンにしては、雨が降る寒い天気だったが、3年ぶりにリアル発表会とのことで、発表する受講生の皆さんも熱がこもっていた。 このコースは今回で第26期になる。1期は半年制なので、13年前の2010年から開始したことになる。2010年と言えば、日経済はまだ、リーマンショックの落ち込みから脱出しようと、もがいていた時期だ。受講者数は毎回約30人。それが26期だから、SCMに理解と見識のあるOBOGを、合計で650人以上育てたことになる。これはなかなかの成果だと思う。 コースは全体で20回の講義と、課題研究発表会の集合研修からなる。社会人向けなので、講義

    サプライチェーン・マネジメントとは(本当は)何か | タイム・コンサルタントの日誌から
  • 書評:「そうか、君は課長になったのか」 佐々木常夫 | タイム・コンサルタントの日誌から

    好著である。まず、題名がうまい。「そうか、君は課長になったのか」というタイトルからは、課長というマネジメント職の仕事の心得を書いた、というメッセージが自然に伝わってくる。おまけに、この口ぶりは上から目線だから、書いた人は会社社長か、少なくとも経営層の一員であることが分かる。それも、大企業のだ。 なぜ、大企業か。それは、君(たぶんかつての部下)が課長になったことを、著者が知らずにいて、気付かされたことを示すからだ。それは大きな会社でないと起こり得ない。経営者が部課長の顔と名前まで、すべてそらんじているような会社は、(売上や上場にかかわらず)中小企業と呼ぶべきなのである。著者は、大企業の経営層にいる。これが、読者に無意識な信頼度を与える。 書は、「石田君」という架空の相手に向かって、アドバイスを送る形式になっている。文体は、「ですます調」だ。これも好ましい。ていねいな文体、漢字とかなの比率

    書評:「そうか、君は課長になったのか」 佐々木常夫 | タイム・コンサルタントの日誌から
  • プロジェクト・マネジメントを学ぶとは、どういうことか (+10/26・11/3 PM研修セミナーのお知らせ) | タイム・コンサルタントの日誌から

    「システム・インテグレーター(SIer)というビジネスは、当に今後も存続できると思いますか?」——この問いを、わたしはときどき、IT業界の人に聞いてみている。 ご存じとは思うが、SIer(エスアイヤーと読む)は、ITシステムを受託開発する企業のことだ。分野は業務系システムが多いが、ECサイトや組込系のこともある。運用もときには受託するが、Integration(=まとめあげる)の語が指すように、構築が主な仕事である。そういう点で、同じIT業界でも、パッケージソフトを販売したりSaaS提供したりするビジネスとは区別される。 SIer企業は、デジタルに関わる高度な知識や技術を有しているし、今のDXブーム時代に、ユーザ企業から受託してシステム開発を行う、花形的産業であるはずだ。そのビジネスの将来性を問うているのだが、誰に聞いても答えは今ひとつ、かんばしくない。理由は、なかなか儲からないからであ

    プロジェクト・マネジメントを学ぶとは、どういうことか (+10/26・11/3 PM研修セミナーのお知らせ) | タイム・コンサルタントの日誌から
  • BOMに関する新連載記事のお知らせ | タイム・コンサルタントの日誌から

    2004年の末に『BOM/部品表入門』を山崎誠氏と共著で上梓し、以来18年が過ぎました。おかげさまで同書は今年に入ってからも増刷が決まり、累計1万2千部を超えています。また中国語版も、正確な販売部数は不明ながら、着実に売れ続けています。それだけ、BOM/部品表のマネジメントに悩む製造業の方が、内外で多い証拠でしょう。 その後、何度か有償の一日セミナーも行ってきました。こちらもそれなりに継続し、ニーズの根強さを実感すると共に、BOMをめぐる課題の裾野の幅広さを感じました。ただし同書で十分カバーしきれなかった項目や、出版後に浮き彫りになった種類の問題もあります。また新たに確立普及してきた概念・ツールなどもあります。たとえば、以下のような事柄です:

    BOMに関する新連載記事のお知らせ | タイム・コンサルタントの日誌から
  • 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか

    *文字かすれ修正しました Developers summit 2022 発表資料です。 元ネタはこちらのnoteです。 https://note.com/miz_kushida/n/n103a7da460c5 Twitter https://twitter.com/miz_kushida

    「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
  • 1on1 ノウハウの共有 | DevelopersIO

    ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては

    1on1 ノウハウの共有 | DevelopersIO
  • マネジメントの極意は「自分のことは棚にあげる」こと, MacBook Pro M1 Max を 1 週間使ってみての感想 - HsbtDiary(2022-02-04)

    ■ マネジメントの極意は「自分のことは棚にあげる」こと タイトルは https://qiita.com/jnchito/items/0a0b46106681f41f2f0e のインスパイアです。 昔エンジニアなどをやっていた時に、マネージャや上司から何かコメントを受けると「とは言っても、このコードも書けないのにさあ」というような気持ちになった経験から、自分が実際にマネジメントをする立場になると、「は〜、React とかあまりわからんので方針とか出しにくいなあ」となって止まってしまうことがあります。 昨今のソフトウェアエンジニアリングは幅も深さも異次元のレベルまで広がっているので、全てのことをマネジメントが実践できるというのは正直無理な話です。自分ができることしかマネジメントできないなら、ソフトウェア開発の世界では何もできないのに等しいです。 そこで必要なことは「自分のことは棚にあげる」です

  • 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎

    ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」>「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ(解決策わからない) では詳細を書いていく。 勝手に学ぶ人:自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

    「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎
  • プロジェクトマネージャの意思決定プロセスや判断プロセス - プログラマの思索

  • 生産管理システムは生産を管理できるか | タイム・コンサルタントの日誌から

    今回は前回に引き続き、サイトにおけるPMと並ぶもう一つの重要なテーマ、SCMに関係する問題を考えてみよう。生産管理システムは生産を管理できるか、という問題である。 何度も繰り返していることだが、管理とマネジメントは違う。日語の「管理」という言葉は、英語では3種類の異なる概念をカバーするような、いささか曖昧な多義語である。おおむね、

    生産管理システムは生産を管理できるか | タイム・コンサルタントの日誌から
  • プロジェクト・マネジメント・システムは存在しうるか | タイム・コンサルタントの日誌から

    「マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。

    プロジェクト・マネジメント・システムは存在しうるか | タイム・コンサルタントの日誌から
  • エンジニアの"有害な振る舞い"への対処法 - Qiita

    記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニア上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、記事のポリシーに沿わない使用(難しい人というラベリングを特定個人に適用する使い方)が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40%低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

    エンジニアの"有害な振る舞い"への対処法 - Qiita
  • 完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita

    これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ

    完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
  • 1on1の効果を高める3つの技法 - NTT Communications Engineers' Blog

    この記事は NTTコミュニケーションズ Advent Calendar 2021 の11日目の記事です。 はじめに ヒューマンリソース部の岩瀬(@iwashi86)です。普段は、全社の人材開発・組織開発を推進しており、業務の1つとして、"1on1" の全社展開をしております。 記事では、その"1on1"の効果を高める具体的な技法を紹介いたします。アドベントカレンダーということで、ゆるめに書いてみます。*1 NTT Com における1on1の目的とは? 技法を説明する前に、1on1の目的について説明します。技法はあくまで目的達成に向けたHowでしかないためです。 1on1の目的とは何でしょうか?1on1それ自体には、複数の目的が挙げられます。代表的なところで言えば次のようなものでしょうか。 信頼関係の構築 離職率の低下 メンバー育成 目標達成へ向けた支援 etc... どれが正解というもの

    1on1の効果を高める3つの技法 - NTT Communications Engineers' Blog
  • 第5のリスク対応戦略を考える | タイム・コンサルタントの日誌から

    皆さんはギリシャ神話に出てくるカサンドラの物語をご存じだろうか? カサンドラはトロイアの王子パリスの妹で、予言の能力を持っている。しかし彼女には、アポロンの呪いがかかっていて、誰も彼女の予言を信じない、という状況にある。 有名なトロイア戦争は、王子パリスが、スパルタ国王の王妃で絶世の美女ヘレネーを、故国トロイアに連れ帰ったことから始まる。カサンドラはこの事件が、トロイアの滅亡を招くと予言するが、残念ながら誰もそれを信じない。 カサンドラは、トロイの木馬を市民たちが受け入れたことに対しても、破滅を招くと警告する。しかしこの時も誰も信じず、結局トロイアは敗北する。そしてカッサンドラ自身も、ヘレネーの双子の姉クリュタイムネストラの手にかかって命を落とすのだ。

    第5のリスク対応戦略を考える | タイム・コンサルタントの日誌から
  • EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO

    この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状

    EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
  • 予算の作り方|和田洋一

    経営の重要なツールである予算につき私見を書いてみる。 世に予算を「正確に策定する」議論は多く見受けられるものの、なぜ予算を建てるかに対してストレートに述べたものはあまり見ない。 「なぜ」がなければ「どのように」は導けない。 予算とは経営からのメッセージ予算は、スタッフの行動を促すための仕様書 CEOは、これを肝に銘ずるべき。 「見通し」で予算数値を作る人は経営していないと宣言しているのと同じ。 一方、単なる気合を書いてしまう人も、メクラ運転になるのでハタ迷惑。 仕様書は以下の二つの機能を持つ。 ① 経営の方向をメッセージとして打ち出す 予算は言語表現であると割り切る。 ・大幅増益としたい場合 会社や置かれているステージによって「大幅」を表現する数値は異なり(30%増、倍増等)、スタッフの感覚と一致しなければ効果は半減する。 ・次年度以降の飛躍のため、あえて踏み固めることを伝える場合 前年度

    予算の作り方|和田洋一
  • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

    はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

    なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita