自分がどんな仕事をしているのか？開発しているシステムが、お客様にとってどのような結果を生むのかを真に理解することです。
個人でチームの一員としてやっている場合、自然と身につくものであると思います。ですが、自然と身につくものだけでは不十分です。積極的に周辺や、接続したり連携する機能に関するエンドユーザでの使われ方の情報を集めましょう。
単に仕様を理解していてその通り作るだけではだめです。プログラマとしてはそれでよいのでしょうがチームリーダを目指すのですから周辺知識は必要です。重要なのはそのシステムは“どのように使われるか“です。この観点を持っていることにより、担当している単機能の単体試験だけでなく、結合試験、総合試験、運用試験に食い込むことができます。「彼(彼女)なら関連機能を含めたユーズケースを元に試験シナリオが作れる」ということになれば第一目標は達成です。
「彼がいなければどうにもならない」となるのが理想ですがまずは「彼に任せることができきる」となることが重要です。
開発工程で上流はベテランが行うのが一般的ですプログラマは多くここには参加できず、詳細設計工程あるいは製造工程から参加することになります。V字開発の工程ごとの人員表を意識すればわかりますが、詳細設計製造から入った人は単体試験が終了すると不要になります。人が減らされるのです。ここでいかに生き残るかが勝負です。そのための武器と考えてください。
隣の芝は青い？転職する？
「SEは徹夜も多いし、お客様からは無理難題言われる、大変だから客商売でもやろうかな」という話をデスマーチPJで疲れてくるとよく聞きます。どうなんでしょう、ほかの業界に行けば楽になるのでしょうか？
私はあまり変わらないと考えています。忙しい人はどの業界に行っても忙しいですし、それなりにストレスがたまります。
業界を変わる意味合いというか利点は、その業界で受けるストレスが自分に耐えられるストレスであるか？であると考えます。
どの業界にも忙しくない人や忙しい人がいます。忙しい人は多分ですが、ほかの業界に行っても忙しいと思います。いろいろ要因はあると思いますが、まずはその人がいろいろ任されるタイプの人ですと、頼りにされて仕事が増えていきます。仕事の仕方が忙しくなる仕事の仕方である場合もあるとおもいます。あいている時間があると何かをしてしまう人がこれに当たります。どんなことでも一度始めてしまうとやめられなくなってしまうのです。大企業病の「業務ややることがどんどん増えるが、業績下がってもなぜか減らない現象」の原因の一つです。
スーパーに勤めていた時は生鮮食品だったこともあり朝は６～７：００くらいから仕込みを始めて夜１０：００の閉店後片づけをして、次の売り出しの準備(売り場変え)をして帰ると、睡眠時間が４時間とか２時間であることもおおかったです
つまり「忙しい」は転職の理由にはならないかもしれませんね。
そういえば：開発技術以外の技術も磨こう
技術者は開発技術力に頼りがちで、技術者上がりの管理者も開発技術力を重視しがちですが、スキルとしては開発技術だけではだめです。時々、開発技術力のみを根拠としてチームリーダを任せたために、なかなかプロジェクトが完遂しないということがあります。お客様要望を技術力で実現しようとするか、お客様と用語会話が合わず要件定義ができないか、あるいは理想的なコーディングをすることに時間をかけて作業が終わらないことがあるからです。
そういう人は他がまかせられませんから、開発工程から抜け出せず、場合によっては開発工程のみであちこちのPJを渡り歩くことになります。
技術のみ職人にならないように注意しましょう。
個人実績
チームリーダになるためには、まずはプログラマーとしての実績が必要です。プログラマーの親玉にしようというのですから、プログラマーとして優れている必要があります。
ここでは「何々できます」などということは聞きたくなくて「何々してきました」「何々の経験があります」ということが重要です。言い方ではなく実際の経験が必要ということです。
開発スキル：こうこういうプロジェクトでの開発経験があり、そこで生産性良く開発ができた。
― 設計：設計品質が高くほかの人の参考になるようなメンテナンスのしやすい設計書を書いてきているスケジュール：スケジュールを常に守ってきていて信頼されている
― 品質：作ったプログラムのバグが少ない
― 要件策定：お客様と話せて、その要件をくみ取ることができる
問題解決実績：問題が起こった時、あっさり解決したことがある
助け合い実績：チームのほかの人が困っているとき助けて解決したことがある
責任感：責任感があって、不測の事態が発生しても、他のせいにせず、最後までやりきっている
バランス力：重要なものとそうでない物を正確に見分けて適切なプライオリティーで処理してきている。
これらの実績がすべてあると、ちょっとチームを任せてみようか？ということになります。
これらがあると認められるためにはどうすればよいのでしょうか？
次回話します
せっかくなので、戦略的ステップアップをしよう
★必要なスキルを身に着けて役割を奪い取れ！
この業界に入ってステップアップを夢見ている人も多いでしょう。私の場合は経験のないIT業界の派遣から中途採用され、マネージャーへなっていったわけですが、だれでもその可能性はあると思っています。
そのためには必要なスキルを身に着けて、役割を奪い取る気概が必要なのかもしれません。
ステップアップとしては、プログラマからのステップとしていきなり管理をするマネージャなることは困難です、私の経緯と同じように通常の段階としてはまずは
プログラマ→チームリーダー→サブシステムリーダー→プロジェクトマネージャ
という流れが一般的かと思います。
そしてその間に身に着けるべき知識・技術もあります。課題管理、品質管理、工程管理、見積もり、レビュー、要員育成、業務知識等の知識技術系の話。
本人の能力としてのマネージメントスキルとしては、強い意志、原則論、コミュニケーション能力、交渉力、意思決定力等などがあると私は考えています。
少しずつ一個一個語っていきます。
(順番はあれですが・・)
まずはチームリーダーになることとそこで身に着けるべき能力の話でしょうか。
いっぺんに管理部分をやっても意味がありません、それぞれの段階で身に付けなければならないことを身に付けて、確実な実力を獲得しましょう。
まずはチームリーダーになろう
PMになって役割が変わることを昇進というかは異論があるところを思いますが。面倒を見なければならない人ができるあるいは増えることをこの際昇進といいましょう。
４～５人程度の少数の開発者を下につけて、一部の機能を担当してマネージメントスキルを磨きましょう。プロジェクトを管理するのがプロジェクトマネージャなら、チームを管理するのがチームリーダーです。管理するものが、組織中心か、人中心かの違いがありますね。いずれも運営も管理しますが、直接の被管理体がチームなのか人個人なのかの違いがあります。人が管理できなければ組織は管理できませんから、十分にスキルを磨きましょう。
チームリーダになるためには何が必要でしょうか？「個人実績」と武器としての「ユーザ業務知識」「技術力」です。この「ユーザ業務知識」がない場合でも、他のたとえば「技術力」が非常に優れているということでもよいかもしれません。私はユーザ業務の業務知識を武器にしました。
チームリーダになってから必要になるスキルとしては「見積もり」「チームビルド」「工程管理」などがあります。これらはいきなり必要になります。
そして、さらなる発展のためにチームリーダになって「チーム実績」を積んでいく必要があります。
うまく実績が積めないと技術力のあるプログラマに戻されてしまいます。
必要なスキルやだいたいどの程度できればいいかを述べていきます。
①個人実績
②ユーザ業務の知識
③技術力
④見積もり
⑤チームビルド
⑥工程管理
⑦問題解決
⑧チーム実績
についての書きます
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
マネージメント本
マネージメント本は多く概念的であったりします。
このような理念でとかこのように行動をとか
マネージメントにはレベルがあってローアマネージメントミドルマネージメントトップマネージメントです。
マネージメント本のマネージメントというと通常はトップマネージメントを指して経営層向けの記述であることが多いです。
ローアマネージメントの実践的な内容が少ないのが一般的です、もちろん、抽象化してあてはめれば参考になることは非常に多く、バイブルにすべき内容も多いです。
★図、トップマネージメント⇔ローアマネージメント必要とされる資質
当然トップ向けであるということは中身は概念的になります。なぜか！
トップの人間は全体最適を求める必要があるので偏った一部の事情に方針を合わせることが吉ではないからです。
現場はそれぞれの事情・状況に合わせて個別最適を目指しますから短時間での臨機応変な対応が求められます。
★図、トップとローでのマネージメントの違い
我々は経営者ではありませんから、このローからミドルに向けての実践をやっていきましょう。
とはいえ、正しい知識ディシジョンはどうあるべきかなどの話は偉い人の話にはかないませんから、その部分はいろいろな本などを紹介させていただきます。
coming soon
今必死に書いていますお待ちを
どんな組織を想定しているか
組織の規模としては比較的大きなもの、マネージャーレベルで年間一桁億円、部門で数十億円、事業部門で数百億円程度の組織を想定しています。
いろいろな「あるある」的な話は小規模ではあてはまらない物もあるかもしれません。
想定する組織構造としては単純化しますが、ピラミッド型で構造は、プログラマ、チームリーダ、サブシステムリーダ、などのローアーマネージメント、プロジェクトマネージャ、部長・部門長などのミドルマネージメント、事業部幹部・役員・社長などのトップマネージメントがあるピラミッド構造の前提ではなします。
プロジェクト全体を管理したりする課長レベルの職級(職位)をここでは課長、役割(役職)をプロジェクトマネージャと表現します。課長の職級を上でまとめるのが部長、ある区切られた範囲の課をまとめるのが部門長という役割として話します。部門を束ねて、事業責任を負うのが事業長・経営層と表現します。
組織によっては職級(職位)は第何等級という風に細かい数字(十数等級ある場合もある)で表現されることもあります。これらは給与レンジと密接で役割にかかわらない位を表現します(単純に給与等級を表すために職級がある組織もあります)。
★図、ピラミッド図 プログラマ、チームリーダ、サブシステムリーダ、プロジェクトマネージャ
各役割の想定定義については、本文の中で触れていきますのでそちらを参照ください。
ご自身の組織に合わせて本書の役割を何と呼ぶかで読み替えてください。きっと思い当たる節や、こんなことあるあると思っていただけることと思います。
誰に向けてのものか
想定としてはプログラマとしてバリバリ開発をしていてそれなりに評価されたひとでこれからさらにPMにも手を出していきたい人や、PMに将来なりたいプログラマを対象としています。
とはいえ、プログラマからPMになろうとするときの話を私の経験に基づき書いたものですべてに当てはまるバイブルというものではありません。
顧客が存在するBtoBシステム開発プロジェクトを想定しています。
システム開発といっても色々な場面があります。社内システムを作る開発プロジェクトやゲーム開発のように社内に仕様を決める人がいてトップダウンですぐに仕様変更があるようなものはあてはまらない場合があります。
この場合は、顧客がいて、ある業務を行うためのシステム開発・構築を請け負い、お客様と要件定義交渉を通じて仕様を確定して設計をしたうえで開発を行う、IPAなどで発表しているソフトウエア開発プロセスなどに沿って進めていくようなプロジェクトです。(これらのプロセスは理想で誰もやっていないと思う業界や分野はあろうかと思いますが、官庁公共系の開発などではこれらを守ることを仕様書で要求されたりします。当たり前に行っているところも多いのです。)
とはいえ、システム開発プロジェクトであれば、言い回しはシチュエーションの違いはあっても大きく違うことはないでしょう。
小さなPJをやってきた人は本当にこんなことまで必要なの？と思うかもしれません。
言い換えれば、より大きなPJをやるのに何が必要か？という見方をしてもいいです（タイトルを変えて中身の同じ本をだそうかしら？）
もともと大型のPJをやってきているSIerのひとが見れば、「あたりまえじゃん！どこでもやっていることだ」か、「気持ちがわからん」という風になる内容です。
私は中・大型PJの仕事をやってきているので、社内システムや小さなシステム、オープンソースプロジェクトではここで述べていることはあまり当てはまらないかもしれません(どこまでやるかなどの品質に対する考えかた、費用に対する考え方など)。品質担保に対する方法論など大きな点は変わらないと思いますが、その点注意をして読んでください。
技術論や、プロジェクト管理手法にも触れていますが、あくまでも一例です。いらないところは読み飛ばしてください、本書は必要なところを拾い読みすることを前提に作られていますから、様々なレベルや状況について述べていてその意味での対象読者レベルの一貫性はありませんのでお許しを。