開発者からリーダーへの視点の切り替え

[ 開発者とリーダーとの違い ]

　お客様
　　｜
　プロジェクトマネージャ
　　｜
　プロジェクトリーダー(あなた)
　　｜
　メンバー×(数名)

[ リーダーのスキル ]

• 開発者と違う視点を持つこと

成果物を指摘したり、別の観点から見ると、もっと品質がよいものができる
のではないかと考えることが大切である。

━━━━━━━━━━━━━━━━━━━━━━━━

[ 価値 ]

• 追い込まれると、チームの価値は二の次になってしまう。
• また、メンバーもこれらの価値を守れる状態を保つ必要がある。
• メンバーのモチベーションをあげる。

━━━━━━━━━━━━━━━━━━━━━━━━

[ チームプレイ ]

• チームの力を最大限に引き出すことに価値を見いだすべきです。
• チームの力を引き出さない限り、達成できない仕事があるということ

を十分に認識する必要があります。

１人でも欠けたら、作業に支障がでる。
チームワークを大切にする。

━━━━━━━━━━━━━━━━━━━━━━━━

[ 顧客満足志向 ]

• 顧客満足。顧客の「うれしさ」に敏感になりましょう。
• 顧客が大してうれしくないことをして、無駄働きをしないという意味も含んでいます。
• お客様の要求がどのようなものなのか、お客様とも打ち合わせし、最善のものを作ることが要求されます。

━━━━━━━━━━━━━━━━━━━━━━━━

[ 中庸であること ]

• 状況に応じて良いと思われることを大胆に取り入れる勇気や、状況に応じた良し悪し

を判断するロジカルさ、つまり引き出しの多さが必要

• 色々な観点から物事を考えられる力を養う。

━━━━━━━━━━━━━━━━━━━━━━━━

[ シンプルイズベスト ]

• シンプルな設計を心がける。
• 今後のメンテナンス性を考えた設計、製造を心がける。

━━━━━━━━━━━━━━━━━━━━━━━━

[ 管理というよりは演出 ]

• メンバーに行動を指示する場合→自発的な行動を促す言葉を使う。

「～してください。」→「～してみてはどうですか？」

• プロジェクトと関係がない技術的な話題にも積極的に参加し、メンバーと議論する。

メンバーの性格も把握する必要がある。

• 成果を上げたメンバーを褒める。

作業を指示する場合も命令するのではなく、意見を尊重する。

━━━━━━━━━━━━━━━━━━━━━━━━

[ チームは一期一会 ]

• 開発プロセスや役割はメンバーにあらかじめ説明し、途中で変える場合には、

その都度正しく説明する必要があります。

打ち合わせを心がける。

━━━━━━━━━━━━━━━━━━━━━━━━

[ リーダー ]

• いわれたことだけやっているのでは務まりません。

リーダーが混乱し何をすべきか分からなくなってしまうと、問題です。

リーダーはプログラミングをしないということが前提です。
万が一現場の手が足りなくなった場合は、比較的リスクの低い箇所を選び
ひっそりとやり遂げましょう。リスクの高い部分をリーダーが抱えこむと
事態が悪化します。

• リーダーが作業に没頭することで、視野が狭くなり、チーム全体の問題に

対処する余裕が失われる。

作業を抱えない。あくまで調整役にまわる。

• ベテランメンバーのモチベーションが下がってしまう。

作業を分担したら、その役割はあくまで担当者に任せ。
担当者のスケジュール調整および成功までのサポートを行う。

• 細かい部分ばかりに気になりだして、全体的な修正を命じた結果、バグが

混入させ、結果的に納期に間に合わない。

細かい部分などは、的確な指示をし、実質の作業はメンバーにやってもらう。

• 「スキルと経験が足りなかった」と考え、いままでの自分の経験・スキルに

よるやり方と、失敗したプロジェクトと　状況との間に生じる矛盾と葛藤を課題
としてとらえ、次の機会には、この課題を克服した新しい自分のやり方として
統合していけるかどうかを検討する。

前回の失敗を踏まえ、新たなプロジェクトを成功に導く。

• せっかくプロジェクトリーダーという立場を任されたなら、自分の責任の範囲

内で新たなチャレンジをリスクとして取り込むべきです。

プロジェクトリーダー１年生という立場で、失敗を恐れず、多くを学べ。

━━━━━━━━━━━━━━━━━━━━━━━━

無駄な作業をなくし、チーム内でバランスよく作業を割り振り
円滑にプロジェクトを成功に導く。常にチャレンジを目指す。

今までリーダー経験がないので、リーダー経験を積んで
仕事の幅を広げて生きたい。

━━━━━━━━━━━━━━━━━━━━━━━━