よく人が辞める職場のリーダーは、何が間違っているのだろうか？ - モチベーションは楽しさ創造から
人間関係に悩んでいる人がサラリーマンにはとても多い。私もサラリーマンの時そうだった。モチベーションアップは楽しさ創造から - 部下や後輩があなたを嫌う １０のワケでも述べたが、社員が辞める理由の多くは、上司との人間関係。上司が嫌いだから辞めていくのである。 その人間関係をややこしくしている大きな原因の一つに、リーダーシップやモチベーションについての考え方があるのではないだろうか？今、日本人が考えるリーダー像は、「闘将型」「戦国武将」「明治維新の際の志士」的な、睨みを効かせてガーンっというリーダーシップではないだろうか？言うことを効かないのであれば鉄拳制裁も辞さないという強い男のリーダーシップ（鬼の上司）である。 さすがに、企業内で鉄拳制裁するわけにもいかないので、本人は気づかないのだが、そのような人は言葉の鉄拳制裁を部下に行っている。言葉の鉄拳制裁といってもいろんなパターンがある。 怒鳴り
「企業理念」の大切さ
UIEvolution の起業は私にとっては初の起業であった。今から思い直してみると、ビギナーだった故のたくさんの失敗をしてきたが、今の私から見て「良くそれなしで会社として成り立ったなァ」と言いたくなるよう恥ずかしいことを一つしている。 「User Experience Matters」、「Pervasive Application」など、会社の外に向けたビジョンやミッションははっきりと打ち出していたものの、どんな人を採用してどんなカルチャーの会社にしたいか、という会社作りにおいてもっとも大切な「企業理念」を目に見える形の言葉にしておかなかったのである。 そもそも「企業カルチャー」の大切さを私が理解していなかったこともあるし、私自身の中でも「どんなカルチャーの会社にしたいか」というイメージが固まっていなかったのもある。Google・Microsoft・Sony・Honda、どれもファウンダ
自分という製品を“再開発”する「BMR」という方法 | シゴタノ！
『10年商品をつくるBMR』という本を読みました。 「BMR」とは「Basic Marketing Relations」の略で、 「新製品を発想し開発業務を進めていく際の枠組み（基本原理）」 であり、 「理解できるとマーケティングがやさしくなる」 と書かれています。 一読して感じることは、「BMR」という考え方の応用範囲の広さです。つまり、新製品の開発業務に携わる人以外にも幅広く役に立つヒントを学ぶことができそうです。 開発マーケティングと販売マーケティング よく、「マーケティングは売れる仕組みを作ること」という説明を見ることがありますが、それは販売マーケティングを指しています。確かにそれはマーケティングの一面ですが、その前に、まず売れる製品を作るという過程があることを忘れてはいけません。開発マーケティングなくして、販売マーケティングもないのですから。 特に最近では、売れる仕組みという意味
ビジネスリサーチの心得
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view 5．ビジネスリサーチのビジネスモデル ビジネスリサーチがアウトソースされる理由 ビジネスリサーチを社外に依頼する理由①〜信頼できる人「すべては依頼から始まる」からでも書きましたが、依頼主が社外にリサーチを委託する最大の理由は、事業環境を定点で把握… 2021.01.18 2021.05.13 146 view
ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント
プロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を紹介しましたが特殊事例だったかもしれません。今回は、もっと身近な事例を考えてみましょう。 前回、失敗しないプロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を考えてみました。はてなブックマークでも、多くの方からコメントを頂きましたが、やはり「そうは言ってもね」というのが正直な反応だと思います。 そこで今回は、プロジェクト管理の「負のスパイラル」を脱出するために、もう少し身近な事例を参考にしてみたいと思います。 ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント 短期ではなく、長期で考える 遅い人ではなく、早い人に注目する 大きく始めず、小さく始める 短期ではなく、長期で考える 通常のプロジェクトでは、前回紹介したAppleのように「締め切りを事
Railsで作られたプロジェクト管理ツール"redMine" (でぃべろっぱーず・さいど)
redMine - project management and issue tracking Rubyで作られたプロジェクト管理ツールです。 GanttチャートやMyページなど、Tracにはデフォルトで備わっていない機能が付いてますね。 デモサイトはこちらです。 Tracよりも使いやすいのかしら。 サイトに書かれている特徴には以下のものが挙げられています。 ・Multiple users/multiple projects →多様なユーザ／プロジェクトに対応 ・Fully customizable role based access control →アクセス制御によるカスタマイズ可能な権限管理 ・Issue tracking system →問題課題追跡システム（トラッキングシステム） ・Fully customizable workflow →カスタマイズ可能なワークフロー ・Doc
ウノウラボ Unoh Labs: 失敗から学んだ効率のよい会議術
こんにちはmatsudaと申します。 ２月に中途でウノウへ入社した新人です。 まだウノウでの体験は少ないので、これまで勤めてきた企業でやっていた会議で、自らの失敗談から学んだ会議を円滑にすすめるための会議術をご紹介します。 頭の片隅にちょっとでも残していただけるのであれば、とてもうれしいですね。 ■時間通りに会議をはじめる当たり前のようでなかなかできないのが時間通りに集まり、会議をはじめることです。ダラダラはじまる会議ほど、ダラダラと会議をする傾向にありました。 ■必ずアジェンダを用意する会議には必ずアジェンダを用意してください。アジェンダのない会議ほどあさっての方向に話題がそれることはありません。簡単なものでいいです。必ずアジェンダを用意するクセをつけてください。 ■冒頭に会議の目的を共有する何のために集まった会議なのか？お互い確認してください。「いや、会議しろと言われたから集まっ
ITmedia Biz.ID：失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント
失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント：デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します（2月21日の記事参照）。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない
コーポレート・ファイナンス入門
息子の大学で授業参観をする機会があったので聴講したのが「Corporate Finance」の授業。わずか７０分の授業であったが、とても分かりやすかったので復習の意味も兼ねてここに解説してみる。 まず、会社として採用することを考慮している二つのプロジェクト、「S」と「L」があったとする。プロジェクト「S」は、一年目に５０万ドル、二年目に４０万ドル、三年目に３０万ドル、四年目に１０万ドルのキャッシュフロー（＝会社に入ってくるお金）を生み出すが、プロジェクト「L」は、一年目に１０万ドル、二年目に２０万ドル、三年目に３０万ドル、４年目に６０万ドルのキャッシュフローを生み出す。 それぞれのプロジェクトに１００万ドルの資金が必要で、調達した資金には１０％の利息がかかると仮定したとき、会社としてはどちらのプロジェクトを選ぶべきか、というのが今回の課題である。 「投資した資金を回収するのにどのくらいの期
有能なプロジェクトマネージャを育てるには（2） ― ＠IT情報マネジメント
前回に引き続き、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。今回は特にPMBOKの使用法などについて考える。 団塊世代が組織から去りつつあるいま、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。2回目となる今回は、前回に引き続きシステム開発のプロジェクトマネジメント能力育成について考える。 システム開発プロジェクトマネジメントでPMBOKを参考にすると PMBOKは教科書ではなく参考書 プロジェクトマネジメントに関する知識というと、「PMBOKを教科書にして勉強しよう」という方がときどきおられる。PMBOKは、いろいろな分野で行われる“プロジェクト”という仕事のやり方を分析能力にたけた人が整理し、プロジェクトマネジメントの一般的・共通的な枠組みとして整理したものだ。 少し極端ないい方をすると、「共
Geekなぺーじ : プログラマのモチベーションを高める9の事項
「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
「トヨタのオペレーションは尊敬すべきものだが、マネジメントはベストといえない」
「トヨタのオペレーションは尊敬すべきものだが、マネジメントはベストといえない」 『ザ・ゴール』の著者ゴールドラット博士に聞く TOC（制約条件の理論）の創始者であり、ベストセラーとなったビジネス書『ザ・ゴール』（ダイヤモンド社）の著者としても知られるエリヤフ・ゴールドラット博士が来日し、日経情報ストラテジーのインタビューに答えた。 ゴールドラット博士が来日した目的は、生産管理のDBR（ドラム・バッファー・ロープ）、プロジェクト管理のCCPM（クリティカル・チェーン・マネジメント）などに続くTOCの応用分野の1つである営業強化手法「バイアブル・ビジョン」について講演するためである。 バイアブル・ビジョンとは、営業部門と製造部門が市場での競争優位を確立するための全体最適のフレームワーク。営業部門は顧客の抱える問題を思考プロセスを用いて分析し、顧客の利益を伸ばすための制約条件を把握する。一方、製
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
