複業フリーランスのhillpointです。
ITエンジニア、特にシステムエンジニアが成長していくと、小さなチームのリーダーをするようになります。
最初は、プログラマーと二人だけのチームかもしれないし、小さな機能を担当する数名のチームかも知れません。
そんな小さなチームでも、リーダーはリーダーです。
どんな立派なリーダーでも、プロジェクトリーダーであってもプロジェクトマネージャーであっても、管理職であっても、最初からリーダーの人なんていません。
最初は小さなチームのリーダーからです。
これからのキャリアアップの第一歩です。
そんな新米リーダーへ。
リーダーのちょっと役立つテク教えます。
なお、これは、リーダー論ではありません。
リーダーのちょっとしたテクニックで、リーダーとしての考え方、リーダーシップではありませんので、その辺は自分で考え、勉強し、実践し、失敗して身につけてください。
専門用語について
アイコンがついている専門用語は、「知らないと恥ずかしいITエンジニアの用語集」ページに説明を記載しているので、専門用語の意味が解らない場合、リンクをタップして、説明を参照してください。
IT業界の初心者リーダーへ役立つ。ちょいテクニック
工数見積り、スケジュールは、担当するメンバーに立案させる。
特にスケジュールですが、人間、自分で書いた作ったスケジュールは、守らなければと言う意識が働きます。
なので、がんばってくれます。
逆に誰かが作った、指示されたスケジュールって、あまり責任感は無いんです。
最初から「無理じゃねぇ」と言う先入観がありますから。
リーダーは、メンバに見積り、スケジュールを作ってもらったら、しっかりとレビューしてください。
そして間違いは指摘しますが、意見は尊重してください。
頭ごなしにダメ出ししてはいけません。
よくあるのが
めちゃ高い見積り
めちゃ長いスケジュール
なぜ、そう考えたのか？どこにネックがあるのか？
話し合い、意見を聞き、仕上げてください。
必ず理由を聞きましょう。
はたまた
絵に書いたような見積り
枠にはめただけのスケジュール
これらも注意してください。
楽観主義なのか？
なにも考えて無いのか？
できると思っているのか？
問題・リスクは無いのか？
これだけでもメンバーの特徴と今後のフォローの仕方が見えてきます。
また、これは、他社なり、下請け企業なりに、発注する場合も同じです。
当たり前ですが、見積りとスケジュールを提示させます。
納期が決まっているケースがあるでしょうが、納期までのマイルストーンに対してもスケジュールを提示してもらいます。
これにより受注者は納期だけでなく、納期までのマイルストーンに対しても責任感がでます。
ことあるごとに、どうしたいか？を問いかける
いわゆる報連相、その他、日常のちょっとした会話であっても、事ある毎に「あなたは、どうしたいですか？」と問いかけてください。
例えば、仕様検討していて、お客さんから、要件にはないんですが、仕様追加になるコメント貰いました。
なんて報告があったりします。
正解は、要件にないため、現状では対応できません。
仕様追加として追加発注してもらう。だったとします。
正解を伝えることは簡単なことですが、「あなたは、どうしたいですか？」と問いかけます。
メンバーは、正解を知ってるもんです。
リーダーがどうしてほしいか？も解ってます。
バカじゃないんです。
ただ、解っていても実行に移さない事もあるんです。
メンバーは、「これ要件にないので、追加発注してもらうようお客さんに説明します。」と回答したとします。
メンバーにとっては、言いにくいことかもしれませんが、メンバーが主体的に切り分けを行い、適切な処置をしてくることで、メンバーは大きく成長していきます。
その際、どんな事を考え、どんな問題に向き合っているのかも、聞きます。
この仕様追加は、運用する上で絶対必要なので、要件漏れだと思います。
要件定義の時に、なぜ漏れるのか？疑問です。
こうやって仕様追加・仕様変更が発生し、開発工程が圧迫されています。
「あなたは、どうしたいですか？」
要件定義から、チームに入って、漏れないように進めたいです。
結果、プロジェクトの円滑な進捗に効果があると思います。
とここまで言わせれたら、もうあとは、メンバーの挑戦と成長を見守るだけです。
リーダーは、要件定義にメンバーの参画を段取りするだけです。
「あなたは、どうしたいですか？」は、自発的な行動を後押しします。
リーダーは、チームとしての目標を決める
一般的な企業であれば、育成手段として、個人の目標設定があると思います。
個人の目標は、プログラマーなら、技術習得するとか、開発効率をあげるとか、SEなら、業務ノウハウ習得とか、品質確保とか、個人のスキルをあげる、そういった目標があるでしょう。
また、組織としての目標もあると思います。
組織としての目標は、売上がいくらとか、コスト削減とか、より収益を改善する、そういった目標があるでしょう。
チームとしては、個人と組織の中間にあるような、チームの成長を願った目標を決めます。
例えば
このプロジェクトでの検証の障害数を10件以下としよう。とか、チーム内のモジュールの共有率を10%あげようとか。
目標は、チームとして取り組む必要があるもの、結果がでるものとします。
もちろんメンバーにも共有して、目標達成にむけて、なにをしないといけないか？考えてもらいます。
このプロジェクトでの検証の障害数を10件以下としよう。としたとき、メンバーが3名いたなら、1名あたり、3件以内となります。
ひとりひとりの成績を、競いあわすだけで、効果がありますが、ここでは、チームで10件というほうを重要視します。
例えば、難しい機能を担当したメンバのほうが障害がでるリスクは高いわけです。
そういったリスクをチームとして、どうやって解決するのか？そんな話し合いをしましょう。
クロスレビューで、メンバの思い込み・勘違い問題をつぶしましょうとか
コードチェックツールを導入して、全員のコードをチェックして、同じような問題をつぶしましょうとか
知恵とか工夫を持ち合って、やることを分担して、チームとしての成果を出すことを一体感持って取り組めると最高です。
自然と、お互いを気遣えできたり、時には厳しく間違いを指摘しあえたりするチームになって行きます。
こういったチームとしての雰囲気は、様々な人たちの目に留まります。
目標達成できなかったとしても、チームとしての評価、リーダとしての評価、メンバーの評価はあがるでしょう。
そして、また、やってほしい、今度はこのプロジェクトをやってほしいなんて、人気のチームとなります。
以上 「新米リーダーへ。リーダーのちょっと役立つテク教えます。」でした。