toshi-o

31年間のソフトウェア開発経験を活かして、現場で本当に役立つ研修を展開中。「プロジェク…

toshi-o

31年間のソフトウェア開発経験を活かして、現場で本当に役立つ研修を展開中。「プロジェクトマネジメント」「コミュニケーションスキル」「DXマインド・推進」などの複数のテーマで500回を超える登壇経験を持っている。本や研修テキストには書いてないコンテンツを展開しています。

  • プロジェクトマネジメント（プロジェクトとコーチング）

  • DX

    デジタルトランスフォーメーションのことだけど、何やっていいのか分からない人向けのマガジンです。

  • コミュニケーション

  • 働き方改革

  • 問題発見＆解決プロセス

すべてのマガジンを表示

バグを計画する

1ヶ月も空いてしまいましたが、今回はソフトウエア開発の中でもかなり肝になること、「バグを計画する」というテーマで書きます。 そもそも一般的には「ソフトウエアバグ」というものは悪いイメージを持つ方が多く、”そんなもの無い方が良い”、”なんでゼロにできないの？”、という声をよく聞きます。 おっしゃる通り、無い方が良いし、ゼロにできたらこんな楽なものはない、のです。 がしかし、開発中のプロセスではこの議論は全くナンセンスで、開発中にバグが全く出ないということはあり得ません。 プ

toshi-o

    • 監視・コントロールプロセス（その2）

      前回、監視・コントロールプロセスの基本的なところを、医療行為とPMを対比させて書きました。 監視・コントロールプロセスの大きな課題、 ・正直に報告されない ・管理工数が爆発 に対して、ではどうしたらいいのか？ メンバーの人数にもよりますが、中～大規模プロジェクトになると、メンバーは数十人～数百人、さらに千人越えなんて事もあり得ます。 こうなるとある程度管理可能な規模のサブシステムに分けて、プロジェクトリーダーを複数配置して管理することが必要になります。 それでもやっぱり数

      toshi-o

      • 監視・コントロールプロセス

        さて、今までは重要な知識エリアの話を書いてきましたが、今回は5つのプロセスの中で一番悩ましい「監視・コントロールプロセス」についてです。 1．目的 監視・コントロールプロセスは何のためにあるのか？ それはズバリ、「早期発見→早期治療」なのです。 それってお医者さんの話でしょ！ はい、そうですけど、医療機関のプロセスとプロジェクトマネジメントのプロセスを比べてみましょう。 医療の場合： ①【患者】症状を報告する ②【医者】問診を実施し、必要に応じて精密検査を実施する ③【医

        toshi-o

        • リスクマネジメント

          リスクとは、「プロジェクトの目標に影響を与える不確かな事象あるいは状態のこと」というのが定義ですが、私はわかりやすく「このまま行ったらまずいと思っていること＝心配事」と言ってます。 一番分かり易い身近な例としてよく使うのは受験です。 ※このままの学力だとA大学に入れそうも無いなぁ・・・【心配事】 では、前回に引き続きリスクマネジメントの最初の一歩である、リスクマネジメント計画の作成手順で重要なポイントを押さえておきます。 手順1：メンバー全員でリスクを洗い出す ⇒タイム

          toshi-o

        バグを計画する

        toshi-o

        マガジン

        • プロジェクトマネジメント（プロジェクトとコーチング）
          12本
        • DX
          0本
        • コミュニケーション
          14本
        • 働き方改革
          18本
        • 問題発見＆解決プロセス
          9本
        • プログラミング教育
          45本

        記事

          タイムマネジメント

          非現実的な計画ってよくありますよね。 以下、タイムマネジメントにかかわるあるある話。 ・最初っからこんなスケジュールなんて無理無理・・・ ・この作業、まったくスケジュールに載ってないけどいつやったらいいの？ ・見積もりが5人月だから、5人で1ヶ月でやれって・・・チーム作るだけで1ヶ月終わっちゃうよ ・そもそも何作ったらいいのか分からないのに、なんでスケジュールができてんの？ ・いつも後ろから線引くスケジュールが出てくるけど、プロジェクトマネジャーって楽だよね・・・ どうでし

          toshi-o

          タイムマネジメント

          toshi-o

          スコープマネジメント

          スコープマネジメントというと今一つ何のことかよくわからないかもしれませんが、スコープは直訳すると「範囲」という意味で、 何をやって、何をやらないか、の範囲を決める、ことです。 プロジェクトマネジャーの中の知識エリアの一つである、「プロジェクトスコープマネジメント」がそれに該当します。 この知識エリアで必要な項目は以下の３つです。 ①提供するプロダクトやサービスの範囲を明確にする（プロダクトスコープ→要件定義書の作成） ②そのためにどんな作業が必要になるかを全部洗い出す（

          toshi-o

          スコープマネジメント

          toshi-o

          10の知識エリアと5つのプロセス

          PMBOK（ピンボックと読みます）とは、アメリカの非営利団体のPMIがまとめたプロジェクト運営に関する知識体系ガイドです。 PMBOKは「Project Management Body Of Knowledge」の略で、失敗したプロジェクトの失敗原因を追及して、「どうすれば失敗しないのか」「こうしないと失敗しますよ」というナレッジをまとめたものなのです。 PMBOKには10の知識エリアと5つのプロセスが規定されていて、それをMatrixで表したPMBOK Matrixという

          toshi-o

          10の知識エリアと5つのプロセス

          toshi-o

          プロジェクトに影響を与える3つの要因

          今回は、プロジェクトに影響を与える3つの要因についてです。 プロジェクトは計画を立案しそれに従って着実に実行していくわけですが、実行している間にプロジェクトに対して影響を与える要因が3つあります。 ①外部環境の変化 これは一番分かり易い。例えば、 ・マイクロソフトが新しいWindowsのVersionをリリースした ・ネットワークセキュリティーの基準が変わった ・新たな暗号化技術が使用される ・新たな法律が施行された ・競合企業から画期的な商品が発売された などなど、特に

          toshi-o

          プロジェクトに影響を与える3つの要因

          toshi-o

          プロジェクトにおける3つの制約

          だいぶ間が空いてしまいましたが、気を取り直して書きます。 前回プロジェクトを成功させるためのヒントを2つ書きました。 ①の「プロジェクトマンジメント手法を現場に取り入れる（Doing)」の方は、PMBOKに書いてあることなのでおさらい程度と、プラスして若干補足を書いてみようと思います。 まず、「プロジェクトにおける3つの制約」ですが、 1．コスト 2．時間 3．スコープ になります。 1．コスト これは一番分かり易いですよね、開発コストです。 人件費や材料費や設備費など

          toshi-o

          プロジェクトにおける3つの制約

          toshi-o

          プロジェクトを成功させるためのヒント

          マガジンのタイトルを「プロジェクトとコーチング」に変更しました。 今回のマガジンは最初プロジェクトマネジメントの解説しようと思ったのですが、そんなの教科書にいっぱい書いてあるのであまり面白くない。 30年間ソフトウエア開発に従事して、リタイア後にコーチングを学び、もっとコーチング的なコミュニケーションが出来ていればいろいろ問題解決できたのに・・と、もう後の祭りですが、本当にそう思うので、このあたりを中心に書いてみようかと。 技術現場の中でも特にソフトウエア開発現場は、多くの

          toshi-o

          プロジェクトを成功させるためのヒント

          toshi-o

          プロジェクトマネジメント

          前回、ソフトウエア開発って何で大変なのという投稿を書きましたが、近年ソフトウエアの開発量が指数関数的に増加し、ソフトウエア開発現場は本当に火の車状態で大変な状況になっています。 「何を作ればいいのかわからない」ということが最大の問題なのですが、それ以外にも要因はいっぱいあります。 そんなソフトウエア開発のプロセスは非常に複雑であり、自己流でやっていてもなかなか上手くいかないので、みんなどうしているのかというと、CMMI（Capability Maturity Model I

          toshi-o

          プロジェクトマネジメント

          toshi-o

          ソフトウエア開発ってどうしてそんなに大変なの？

          前回のマガジンは「職場のコミュニケーションの難しさ」でした。全部で12回投稿しましたが、そろそろ話も煮詰まった感があるので、まったく新しくマガジンを作ってみようと思います。 新しいマガジンは「ソフトウエア開発」にします。 初回は、30年間ソフトウエア開発現場にいて、ソフトウエア開発にとって最大の課題は何かについてです。 環境や言語は時間とともにどんどん新しいものが出てきます。 しかし、時間が経過しても変わらずソフトウエア開発者にとって最大の課題があります。 それはズバリ

          toshi-o

          ソフトウエア開発ってどうしてそんなに大変なの？

          toshi-o

          やればできる

          職場でのコミュニケーションの難しさを題材に、上司と部下の会話あるあるから、主に上司のあるべき姿を考えてみようというマガジンの14回目です。 【】は心の声、つまり言えないけど心の中でこう思っているという意味で読んで下さい。 あるある＃13： （部下）課長、今回のこのプロジェクトの計画を作ってみたのでが、現状では受注した時にお客様に提示した納期に対して、2か月ほど遅延しそうです。 （課長）何だって！　そんなことが許されるわけないだろう！ （部下）ですのでこのリスクに対して、私

          toshi-o

          やればできる

          toshi-o

          俺の背中を見て育て！

          職場でのコミュニケーションの難しさを題材に、上司と部下の会話あるあるから、主に上司のあるべき姿を考えてみようというマガジンの13回目です。 【】は心の声、つまり言えないけど心の中でこう思っているという意味で読んで下さい。 あるある＃12： （部下）課長、今回のお客様は私にはかなり手強くて、どのような切り口で話をしていけば信頼関係が築けるのか、何かアドバイスをいただきたいのですが・・・ （課長）今まで何度もお客様の対応の現場に連れて行って、それなりに勉強してきただろう。 （

          toshi-o

          俺の背中を見て育て！

          toshi-o

          言われたとおりにやれ

          職場でのコミュニケーションの難しさを題材に、上司と部下の会話あるあるから、主に上司のあるべき姿を考えてみようというマガジンの12回目です。 【】は心の声、つまり言えないけど心の中でこう思っているという意味で読んで下さい。 あるある＃11： （部下）課長、今回のお客様の課題をよく考えてみたんですが、今まで提案してきた内容より、さらにお客様にとって有効な提案を作ってみました。 （課長）でも、お客様は今までのわれわれの提案を気に入ってくれていて、ほぼ受注できそうなところまで来て

          toshi-o

          言われたとおりにやれ

          toshi-o

          いくら儲かるんだ？

          職場でのコミュニケーションの難しさを題材に、上司と部下の会話あるあるから、主に上司のあるべき姿を考えてみようというマガジンの11回目です。 【】は心の声、つまり言えないけど心の中でこう思っているという意味で読んで下さい。 あるある＃10： （部下）部長、今回のこの新技術は、お客様のXXといった問題解決のための画期的な商品を提供できる可能性が高いです。 （部長）なるほど、なかなか優秀な技術のようだね。 （部下）はい。今後ですが、商品化に向けて開発部門と協力し、1年以内の商品

          toshi-o

          いくら儲かるんだ？

          toshi-o