教育・訓練 2015年09月~2016年03

1.「成功」のカギはコミュニケーション
【要点】
激しい議論をしたり,みんなと違う意見を言うメンバーの存在を悪ととらえてはならないということ

・文書化のスキルが不可欠
失敗しているプロジェクトを見ると,文書化のスキルが不足していることが多い
プロジェクトマネジャやチームメンバーはまず,自ら筆まめになるように心掛けたい
ドキュメントを書いているより,行動が先だ」となりがちだが,そうした行動を続けていてはかえって問題が大きくなる。

信頼関係がすべての基本

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070706/276988/?rt=nocnt

【感想】
確かに文書化のスキルは必要不可欠。
初期の開発できちんとしたドキュメントを作らず、後後になってきちんとしたドキュメントを作ろうとする所が初期メンバーから曖昧に引き継いたメンバーが曖昧な言葉でしっかりとした文面にしかならず、結局ソースから設計書を起こすというパターンはよくありますが、こんなパターンにこそ同じ事を繰り返さないためにも文章化のスキルは必要なんだとしみじみ実感致しました。

2.新・リーダーの品格
【要点】
ヒューマンスキルはIT業界での強みに
会社のトップマネジメントは、上に上がれば上がるほど、社内の部門長から報告を受け、それに対して指示を出す直接的なコミュニケーションの時間が増える。
まずは同僚とうまくコミュニケーションできているのかというベースの部分がポイント
次に人を束ねられるか、といったマネジメント力が求められます。

自分の未来を決断する
「優れたリーダー」を目指すのか?何人規模のプロジェクトをまとめられる人材になりたいのか?ずっと現場で活躍し続けたいのか?
エンジニアリングサイドとビジネスサイドのどちらを志向するのか

どう転んでも必要な「人間力」

【URL】
http://news.mynavi.jp/series/Leader_hinkaku/002/

【感想】
どう転んでも必要な「人間力」

どちらかというと「人間力」というか「人心掌握術」のほうが正しい表現では?と思ってしまう記事でした。

3.PM実践体系–重要性増すPM,そのシステム開発での実践体系を知る
【要点】
「いかに予算や納期を守り,バグの少ない高品質のシステムを構築するか。それこそがプロジェクト管理の要諦だ」。日本の多くのITベンダーやソフト開発組織は,今なおこうした“旧態依然”の考え方から抜け出せていない
しかし、「しっかりした体系的知識や方法論に基づいて,プロジェクトの立ち上げから終結までを,統合的にマネジメントする」という考え方をベースにした,新しいマネジメント技法が脚光を浴び始めている。

実質的標準のPMBOK・・・「PMの体系的知識」として国際的なデファクト・スタンダードとなっている。ISO(国際標準化機構)が策定した「プロジェクトマネジメントにおける品質の指針」(ISO10006)のベースにもなっている。
個人の経験や考えではなく,欧米における多くのプロジェクトの経験やノウハウを体系的な知識としてまとめていること。
【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070221/262666/?ST=selfup

【感想】
これはさらに上の管理職の問題だと考えておりますが、「プロジェクトマネジメントにおける品質の指針」(ISO10006)は一度目を通してみようかと思います。

4.プロジェクト計画--システム開発プロジェクトの「計画」を作成する
【要点】
コミットメントを明確にする
「プロジェクト目標の明確化」・・・システムの稼働環境や開発環境を決める
「開発対象と環境の最適化」、「開発方法論と工程の定義」・・・利用する開発方法論や開発手法,適切な開発ツールを選定するとともに,そのプロジェクトに適した開発工程を定義する
「見積もりとリスク査定」・・・開発範囲やシステムの規模,取り扱うデータ項目の多さ,開発生産性などの前提条件に基づいて,開発工数と開発期間を見積もる
「WBS(Work Breakdown Structure)とスケジューリング」・・・プロジェクトマネジメントで計画を立てる際に用いられる手法
「文書化計画」・・・ユーザー企業に納品する要件定義書や設計書,運用マニュアルなどの文書の作成および納品時期,作成者,文書の品質管理方法などを計画する
「組織計画と要員計画」・・・。要員計画では,まずフェーズごとに必要なスキルの定義を行い,直近のフェーズについては具体的なアサイン(誰が担当するか)まで決める
「教育計画」・・・最後に「必要となるスキルの種類」や「そのスキルが必要とされる時期」に応じて,プロジェクト・メンバーの「教育計画」を作成する。

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070314/265142/?ST=selfup

【感想】
上記の点が今の仕事にどれだけ当てはまり、どれだけ当てはまらないのかを明確し、何故当てはまらないのかを分析してみるの良いかなと考えております。
次回の教育ネタ?

5.品質管理計画--プロジェクト全体を通じた品質基準や方針を策定する
【要点】
プロジェクトマネジメントにおいて何を行うべきか。世の中には欠陥を未然に防いでくれる魔法のツールも,エラーを排除できる画期的な設計手法も存在しない。慎重かつ地道な,品質向上活動があるのみである。
プロジェクトのスケジュール遅延とコスト超過を防止し,しかも高い品質を確保するには,自主検査やレビュー,テストなどの「欠陥除去工程(Defect Removal Processes)」,いわゆるバグつぶしを必要なときに適切に実施しなければならない。そのためにはプロジェクトの計画段階で,欠陥除去工程のスケジュールや方法,目的などをまとめた「品質管理計画」を策定しておく必要がある。

システム開発における欠陥除去をテストだけに頼っていると,品質管理のコストは非常に高くついてしまう。多くの欠陥は,要件定義フェーズや設計フェーズといった上流工程で発生しており,その発見時期がテストなどの下流工程にずれ込めばずれ込むほど,修正に時間がかかるからである
事実,大規模なシステム開発における欠陥の45~80%は,要件定義や設計段階における問題に起因することが,全世界のIBMの経験から分かっている

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070404/267404/?ST=selfup

【感想】
上記の点が今の仕事にどれだけ当てはまり、どれだけ当てはまらないのかを明確し、何故当てはまらないのかを分析してみるの良いかなと考えております。
そもそも品質基準の基準の定義から考えてみるのも面白いかなと考えております。
次回の教育ネタ?

6.初めてのプロジェクトリーダー(1):開発者からリーダーへの視点の切り替え
【要点】
3つの切り口:「価値」「原則」「実践」 ※ 「実践」については(2)を参照。
「価値」・・・私は、リーダーが守るべき価値は3つあると考えています。それは、「チームプレイ」「顧客満足志向」「中庸であること」です。
「原則」・・・何か意思決定をする場合に、まずは、これらの原則を切り口にして考えをまとめ、判断し、行動に移します「シンプルイズベスト」「管理というよりは演出」「チームは一期一会」「目的、課題、アクション」。

【URL】
http://www.itmedia.co.jp/im/articles/0503/09/news104.html

【感想】
「価値」・・・「中庸であること」これについては、少し疑問を持ってしまいますね、極端な思考はあまり良くないと記載されておりますが、極端な思考は決断する上では重要な要素だと個人的には考えております。
この記事は少し組織的すぎる考えたのようですね、悪いとは言いませんが少し違和感を感じてしまいます(「原則」のシンプルイズベストと言っていることが矛盾するのでは?)
「原則」・・・「目的、課題、アクション」の明確にすることやはりこれが一番重要だと思いますね、大抵ろくなPJはこれが明確になっていないから無駄に迷走する形になるんですよね~(遠い目をしている私www)

7.初めてのプロジェクトリーダー(2):なにはともあれ、まずはチームビルディング
【要点】
役割分担・・・バリバリ進めていく必要がある機能は「アタックタイプ」既存の技術を使って、じっくり慎重に進めていく必要がある部分は「ディフェンスタイプ」仕様全体をつかむ「バランスタイプ」

【URL】
http://www.itmedia.co.jp/im/articles/0504/06/news092.html

【感想】
タイプ分けは、確かに良い考えかと・・・今までの仕事を振り返ってみると「ディフェンスタイプ」ばっかの人間が多かったり、「バランスタイプ」の人がいない場合とかあって酷い目にあったことが・・・私としてまずは、この人がどのようなタイプを意識してみます。

8.初めてのプロジェクトリーダー(3):朝会を15分で終わらせるには理由がある

【要点】
[朝会のポイント1] チームの状況を語る
[朝会のポイント2] メンバーの顔色をうかがう
[朝会のポイント3] アクセル&ブレーキ
チームのスピードを上げる(アクセル)、下げる(ブレーキ)

【URL】
http://www.itmedia.co.jp/im/articles/0505/11/news101.html

【感想】
[朝会のポイント2] メンバーの顔色をうかがう
[朝会のポイント3] アクセル&ブレーキ
↑ そんな暇がないと言って、状況だけを語る。
そんな朝会しか見たことない
これは理想論ですね

9.初めてのプロジェクトリーダー(4):開発中、リーダーは何をしている?

【要点】
進ちょくの見える化
運用の注意点
1) タスクの粒度がそろっている
2) メンバーに経験者が多い
3) 期限が比較的長い

【URL】
http://www.itmedia.co.jp/im/articles/0506/15/news112.html

【感想】
リーダーとしてすべき点また状況次第での対処?が書かれておりこの要点を次の教育のキーにして理解を深めるよいものかと考えております。

10.初めてのプロジェクトリーダー(5):リーダーとしての問題解決能力を磨く

【要点】
真実より事実
分類と切り分け
理論と理屈
現実的な解決策
責任の取り方
パフォーマンスが出ない
1. 計測する
2. 目標を設定する
3. 分類し、分析する
4. 解決する

【URL】
http://www.itmedia.co.jp/im/articles/0507/08/news115.html

【感想】
自分や自社にとっての”都合の良い真実”よりも常に”客観的な事実”で物事を見る。
これは、今の現在の大きな課題の一つであり、残念ながら上記のような考えを持つ社会人に出会ったことがあまりありません。
まぁそんな腐った人にならないように”間違わない、正しく見る”力をトライ&エラーを繰り返して模索して行こうと考えております

11.初めてのプロジェクトリーダー(6):「ふりかえり」でプロジェクトを改善する

【要点】
メンバーとKPTする(Keep(良かったので次もやりたいこと)、Problem(問題だったので次はやめたいこと)、Try(次にやってみたいこと))
プロジェクトリーダーにとって貴重な時間
メンバーを導く手段として
お客さまとKPTする
1人でKPTする

次の教育で「KPT」についての詳細記事の読破もしくは現在仕事に対して「KPT」を実行してみます。

【URL】

http://www.itmedia.co.jp/im/articles/0507/29/news110.html
【感想】
作業工程の「ふりかえり」もこのようなやり方があるのですね
機会を作ってKPTを簡単な表にしてみて試してみます。

12.初めてのプロジェクトリーダー(7):リーダーシップは天性ではない

【要点】
リーダーの修行方法
「リーダーになったつもりシミュレーション」
リーダーシップは天性か?
リスクとチャレンジ

【URL】

http://www.itmedia.co.jp/im/articles/0508/26/news117.html

【感想】
やはりリーダーとは、努力の塊であり、天性のものではありません。
今までの記事から様々な知識と経験からなるものがリーダー。
ただし、私がこの記事と現在の自分状況から言いたいのは、リーダーでも”間違ったリーダー”にならないこと。

– 以上 ‐

PJへの道のりはキビシwww

次回へ(半年後)続く


コメントを残す