タグ別アーカイブ: 昇進

私はどういう経緯でなったか(2/2)

・サブシステムを任される
システムにはサイクルがあって、定期的にリプレースが必要になります。(HWやソフトウエアの保守期間が切れたり、業務が時代に合わせて高度化するから)
そんなリプレースのときに一つのサブシステムを任されてサブシステムリーダになりました。
この時はメンバーを3人にして私入れて4人でチームを作りました。運の良いことに優秀なプログラマが一人入っていたのであとの2人は2年目程度の人でもなんとかなるだろうとふんでいました。そのサブシステムはメンテナンスをしてきたところであったので、中の構造はすべて把握しています。最初に作られていたのがぐちゃぐちゃだったので、リファクタリングしたのです。
ほとんどの設計は私がすべて実行し、共通部分、難しい部分のコーディングを優秀なプログラマ(設計とかのドキュメンテーションは不得意)にひたすら作らせます。
その作られたフレームワーク上で2年目たちに機能を作りこませたのです。概要設計までは私で行い詳細設計以降を任せる感じです。
後から聞いたところでは、初回とは比べ物にならない生産性だったそうです。
今から思うと普通の開発ではできない手法でした。(一般化できないという意味)

・管理をサポートする
そのかいもあって管理サポートをするようになり、管理チームに参加する様になります。見積もりの精査や品質管理、課題管理などの技術面を中心にサポートをしたのです。見積もり精査は、見積もりに対して、勘違いしているところはないか見落としているところはないか、妥当性を欠くところはないかを見ました。品質管理はバグが入り込む原因を分析して対策したり、直らないバグに対して助言を与えたりしました。課題管理は、課題に対して複数の解決方法がある中で最適なものを提案したり選択したり技術面の裏付けをとったりしました。

・専門家として参画する
別の案件では技術の専門家としてPMをサポートする立場(ITアーキテクト)で、システムの全体設計を行いました。基本設計までは私が行い、みんなに伝えて、サブシステムごとに概要設計から実施していただくという方法をとりました。
マネージメントをするマネージャーがいたので、その部分は任せて、システムアーキテクチャの策定、技術問題の解決に専念できたのでした。

・PMとして参加する
その後のプロジェクトではマネージャとなってシステム全体の開発構築を行いました。

何となくきれいな段階を追ってPMになっていったように見えますね。当然細かいところは省いていますから、真実ここまできれいではありませんが大きな流れとして、参考にしていただけたらと思います。

私はどういう経緯でなったか(1/2)

実際にはいろいろ紆余曲折はあるものの美しく並べるならば以下の通りです

・サポート要員としてまずはPJに
サービスインしたプロジェクトの残件対応としてこの業界に入りました。サービスインしたといっても問題は多く、バグも大量に残っていましたのでそれらを何とかするのが役割でした。

・いくつかの問題を解決
当時は派遣社員でしたから1月以内に成果を上げないと切られてしまいます。
最初の2週間は仕様書設計をひたすら読みました、早く何らかの成果を出さなければならないのに1000P以上あるあるサブシステムの設計書を渡されたのです。読み終わったことを報告して、障害一覧の中からプライオリティーの高いものから支持を受けて修正しました。
何とか1月以内に1つの修正物件をリリースすることができました。そこからは片端から修正です。

・他のサブシステムの問題を解決
サービスインしていますから使っているときのバグは重大障害として問題になります。大きなものになると担当者全員を集めて緊急対応することになるのです。
そんなことで客先に集められたのですが、たまたま私のいた作業場が近くであったため、先について、その時の責任者から簡単なサブシステムの説明を受けた後、障害調査をしたのですが、運よくすぐに原因が分かったのです。その時はまだ担当者が来ていなかったため、修正内容の案とその影響調査しながら待っていたのです。運が良かっただけなのですが結果的には担当者より早く対応したという結果だけが残りお客様の印象に残る実績となったのです。

・改修案件をやる
システムが安定してくると、今度はシステム変更案件なども入ってくるようになります。変更ですから、見積もり(どれだけ時間がかかるかを言うだけ)をして、受注できたら、それを実行する。というものです。

・大きな改修案件をやる
それらの改修案件をこなしていると、大きな改修が入ってくることもあります。そうなってくると一人ではできませんから、人を入れてやることになります。自分だったら何時間かかるというものはありましたが、ほかの人がそれだけの実力があるのかわかりません。同じくらいだろうと見積もって、ちょっと安全をみてまったくみんなが使えず自分が一人でやっても何とかなる期間と人数を報告してやりました。
当時は資格試験の受験生でしたのでパートタイマーのチームリーダーだったのです。2人いれて3人でやったのですが、私よりは経験が長い人たちでしたが生産性は半分程度であったと記憶しています。困ったら相談してくれと言ってあったのに一つのバグで丸一日悩んでいて、声を掛けたら相談してくれたのですが、単純な話であったためにすぐに直ったのです。悩まずに相談してくれたら1日(8時間)は無駄にせずに済んだはずです。といようなことがあるということを学びました。

ここまではシステム保守段階の話です。
ここからリプレース開発の受注後の開発を担当する話になります。

リーダーシップとは

プロジェクトマネージャーはプログラマーと違いたくさんの人を導いていかなければならないことがわかりました。その能力が「リーダーシップ??」です。

社員教育を重視している組織では管理職になるとき、リーダシップが重視され、リーダーシップ関連の教育等を受けることがあります。リーダーシップとはなんでしょう?必要なのでしょうか?
プロジェクトマネージャなどのハウツーではこのリーダーシップに重点が置かれていたり、管理職試験ではリーダーシップがあるかを見られたりします。
正直わかりません。
と思った人は、いい機会ですからここでリーダーシップについて考えてみましょう。

自分が部下であった時にどういう上司がよかったか?どうしてくれるのが理想だったか。を思い返してみてください。

どれが正しいというのはあまりない気がします。どのリーダでも成功するし失敗します。自分にあったリーダー像(自分の理想とする、ではない)を作りそこを目指して何が自分に足りないか、どうしたら足りないところがカバーできるかを考えます。

リーダーシップの色々

今回は3タイプを紹介しますが、日々リーダーシップに関する書籍や考え方などが発表されたりしてこの類型に当てはまるものばかりではありません。
いろいろ情報を集めて、自分のリーダー像を作り上げてください。
悪い例を入れてますが、これは、管理手法として似ているが非なる管理をした場合の弊害を示しています。どの管理手法も適切に行えばよい結果を生みます。
どれがよい悪いを言っているものではありません。それぞれのマネージメントスタイルです。

1リーダーシップのいろいろ
①こうしろあーしろ型
②みんなでやろう型
③見守るからやってみなさい型
④強引にぐいぐい引っ張る型

リーダーシップのあり方として
2責任をぷことは、任せきることではない

リーダに必要な行動として
3要員の意識を管理する

PJだけでなく自分も管理しなければなりません
4自己管理

例によって、気ままに書きますので
順番の前後等あります、気長にお待ちください。