全員が「明るい、楽しい」と感じるチームにしたい ― ＠IT情報マネジメント
前回「優秀なプロマネはメンタルな働きかけもうまい」から少し間が空いてしまいましたが、第2回目の今回は、リーダーに求める心の在り方をお伝えしたいと思います。といっても、1回目をご覧いただいた方であればお分かりだと思いますが、道徳的な話をするつもりはありません。結果として道徳的な話と同じ内容となるかもしれませんが、心理的な裏付けによって、チームのパワーを最大化するために必要な心の在り方にフォーカスしています。 2つのコミュニケーション コミュニケーションは、コミュニケーションを取る相手の違いから2つに分類されます。1つは、他者とのコミュニケーション。もう1つは自分自身とのコミュニケーションです。 前者については、ビジネス書などでも「説得術」「販売テクニック」「リーダーシップ」といったキーワードを基に書かれることが多いので、普段からなじみがある方もいると思います。一方で後者は、どちらかというと、
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
部下のモチベーションを上げるコミュニケーション（5）
コミュニケーションで必要なのは、相手と信頼関係を築くことです。部下のモチベーションを上げようとする場合にも、「なんでこんなにモチベーションが低いんだ？」と、上から突き放したように見るのではなく、「そういえば、俺も入社して1年目のときは、こんな感じだったよ」というように、部下の立場に立って見ることです。それができて初めて、「こういうふうになっているから、モチベーションが低いんだろうか」とか、「これをしてもらえれば、もうちょっとモチベーションが上がるかな」と対応を考えることができます。まず相手の立場に立って、体験を共有することが必要です。 その際に、これまで紹介した、ミラリング・ペーシング・バックトラッキングと、感覚傾向に一致した対話をすることがポイントになります。 感覚傾向に合わせた対話をする 例えば、モチベーションの下がっている部下が、上司に、「いや～なんか、この案件は本当に先が見えないで
【上級】失敗プロジェクトの共通項 第2回
【上級】失敗プロジェクトの共通項 第2回 【仕様変更/追加】 誰がいつ何をなぜ決めたのかを明らかにし，版数で管理する どんなに正確に仕様を詰めようとしても，開発着手前に仕様を完全に凍結することは不可能である。そこで，どうすれば仕様変更/追加を減らせるか，どうすれば仕様変更/追加の影響を小さく抑えられるか，を考える。 仕様変更/追加を巡るトラブルの多くは，プロジェクトに利用者を適切に参加させることで防げる。 情報システム部門がベンダーとの窓口となっている想定プロジェクトのようなケースでは，利用部門の意見が反映されにくい。しかし，利用部門はシステムに対して多くの問題意識や要求を持っている。立会検査時に同席した利用者部門から仕様変更要望を受けて，結果として大きな仕様変更に対応せざるを得なくなるリスクがある。 非協力的なユーザーへの対処法 仕様変更/追加マネジメントの基本は「版数（バージョン）管理
【上級】失敗プロジェクトの共通項 第3回
【上級】失敗プロジェクトの共通項 第3回 【ユーザーとのコミュニケーション不足】 進ちょく報告は最低限，業界の知識も必要 最近増えてきた短期開発の弊害が顕著に出やすいのが，コミュニケーション不足である。仕様凍結後にユーザーとの打ち合わせを全く行わないケースもあると聞く。特に恐いのは，ベンダー側の業種/業務知識の不足に起因する思い込みや勘違いで，間違った機能を実装してしまうケースがある。 運輸会社の業務システムは，協力関係にある業者間でデータ交換の標準化が進んでいる。その辺りの事情に疎いままだと，必要な機能と開発した機能にズレが出てしまうリスクがある。場合によっては，無償で修正せざるを得ないだろう。 業界知識の習得は必須 コミュニケーション不足を引き起こす要因は大きく3点ある。 第1に，メールやFAXなどに頼りすぎるのは危険だ。ベンダーは，利用部門や情報システム部門の責任者を含むユーザーとの
【上級】失敗プロジェクトの共通項 第1回
「外注したソフトの品質の悪さに閉口した」「検収時に利用者から使い物にならないと文句を言われた」「どうやり繰りしてもカットオーバーに間に合わない」…。プロジェクト・マネージャ（PM）の悩みは尽きない。 システム構築プロジェクトを成功に導くために，具体的にどのようなマネジメントを行うべきか。過去の失敗プロジェクトの積み重ねを分析することで，その傾向と対策が見えてきた。 ここではプロジェクト・マネジメントの中でも，失敗の原因を発見し潰すための“リスク・マネジメント”に焦点を当てる。前半は，リスク・マネジメントを行うための具体的な作業の内容を紹介する。後半では，ダミーのプロジェクトを想定し，そのプロジェクトが陥りやすいリスクとその予防策を紹介する。 11個の作業で構成する システム構築におけるリスク・マネジメントの標準的なフローは，11個の作業で構成する＊1。作業の大半は，上流工程でのリスクの洗い
【上級】失敗プロジェクトの共通項
最近，特に目立つのが見積もりミスによる開発コスト/期間オーバーである。受注優先の考えから営業部門の判断で，無理な価格，納期，不利な条件で受注，契約されやすい。結果として納期に間に合わず，稼働後のトラブルも多く発生する。 見積もり審査会を設置する 見積もりミスは，マネージャの努力ではどうにもならないことが多い。全社的な取り組みが不可欠だ。見積もりミスが起きる最大の理由は，営業部門の独断を許す体制である。これを回避するには，社内体制の整備と，その運用にかかっている。 社内の体制としては，見積もり審査会を設置するのが望ましい。プロジェクトが大規模になるほど，リスクの範囲が拡大，多様化するため，個人や担当組織のみでは判断しきれないからだ。担当者からの見積もり提示や安易な概算見積もりの提示をなくすのが，最優先である。 見積もり審査会のメンバーは，理想的には以下の5つの部門で構成する。 (1)プロジェ
【上級】失敗プロジェクトの共通項 第4回
【上級】失敗プロジェクトの共通項 第4回 【協力会社のソフト品質不良】 目標，役割，スケジュールを共有し，中間確認も怠らない 開発丸投げは，それ自体が大きなリスクである。協力会社がシステムの品質を損なうケースが頻発している。 品質とは，安定稼働だけを指すわけではない。品質の6特性を漏れなく満たす必要がある。6特性とは，機能性，信頼性，使用性，効率性，保守性，移植性を指す＊7。プロジェクトをトラブルなく遂行するという観点に立つと，特に性能確保，負荷対策，イレギュラーな仕様の品質目標を定量的に明示することが重要である。 想定プロジェクトのケースでは協力会社への発注比率が開発全体の50％と高い。マネージャがユーザー対応や社内の開発管理に追われて，協力会社の管理を怠ると，受入検査時に多くの障害や仕様の食い違いが表面化するリスクがある。 1社ですべての開発を請け負うのが困難な今，外注先のソフト品質マ
【上級】失敗プロジェクトの共通項 第5回
想定プロジェクトでは，多くのサーバーやミドルウエアが使われる。OS，Web/APサーバー，データベース，負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ，スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業，休日出勤を招くことになり，納期にも影響を及ぼす。 スキルマップの整備が不可欠 プロジェクトと技術者をうまくマッチングするには，社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ，社内からの協力を仰ぐといった運用が可能になる。 スキル評価の方法は，一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい（図7）。 大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け，さらに開発言語なら「Jav
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
