読者です 読者をやめる 読者になる 読者になる

マネージャの次に目指すもの

on

システムエンジニアとしてのキャリアパスはどう考えれば良いのでしょうか。

現場のプロジェクトにアサインされているときには、仕事で一杯いっぱいでキャリアを考えている時間はないと現実から目をそらしていないでしょうか。いつまでも忙しいふりをして自分の明日から逃げているなら、それは思考が停止しているのです。

悩むマネージャ

実はマネージャの方がキャリアパスについてどう考えれば良いかという悩みを持っている方は多いいのです。システムエンジニアから見ればマネージャというロールに選ばれていること自体がいいように思えますが、当のマネージャは現場の技術から手が離れてしまうことが自分の技術の陳腐化を不安視してしまうのです。

もし、マネージャ職を解かれてしまったら、果たして現場に戻ったときにプロジェクトの前線で思うように手を動かすことができないのではないかと。特に一番前線に近いマネージャは目の前でプロジェクトを見ているわけですからメンバが新しい技術を使えば使うほど、内心は遅れてしまう自分の技術に将来のキャリアパスに不安を覚えずにはいられないのです。

現場に戻る

ある程度マネージャをしたら、現場に戻り上流や企画ができるシステムエンジニアを目指すのがひとつのキャリアパスと思うのです。

もちろん、現場に戻るためにはマネージャをしながらどこの技術エリアにランディングするか方向性を決め、準備しておくことが必要なのは当たり前の話です。

マネージャをしていて良いことのひとつに相談する相手を多数知り合えることがあります。マネージャのときには、現場のプロジェクトを助ける側として相談先を見つけていたことが、現場に戻るときには今度は自分が現場で助けてもらう先になるのです。

実際に、マネージャの頃のプロジェクトで知り合いになった方と現場に戻ってから専門技術において情報交換することで戻った先での仕事の裏付けのデータにするなど、過去の関係を先になって活かすケースはよくあることです。

そして、多くのマネージャはこの選択肢を選ぶべきだと思うのです。ある程度の年数をマネージャで過ごしたら、少なくとも、上流やコンサルティングができる専門領域を持って50代前には現場に戻るべきでしょう。

上を目指す

さらにマネージャの上を目指す。これもひとつのキャリアパスです。が、マネージャでさえ一握りですからさらに絞られるわけです。候補としては。よりビジネスに志向した取り組みが必要になるのは当然のことですし、技術に加え、営業面への関与も必要になります。まあ、その先を目指すと決めた時点で準備はしているでしょうから頑張ってください。

 +(プラスで)場を作る

 何れにしてもマネージャの先のキャリアパスを考える際には、自分のキャリアで得てきたノウハウを後進に渡す場を作ることが必要です。はっきり言えば、自分が持っているノウハウなんて誰も真似なんてできませんからそういう点では何ら心配しなくていいものです。それよりは、似た考え方を持つ人を増やすために時間を割いた方が良いです。そうすることで、現場で困ったときに助けてもらえる候補者を増やすことができるからです。

 

質問がないのに補足説明が必要な資料はダメ資料

on

異なる組織が複数集まる会議があって、その会議での重要な資料の報告で信じられない光景を何度も見せられる身にもなって欲しいものです。

異なる組織といっても会社の代表が集まる会議なので表面上は穏やかに、ただ、記録に残るような言葉については鍔迫り合いをするような雰囲気に一気に変わることもある、という「大人って面倒臭いねぇ」という場なんですよ。

会議の資料説明の基本の「キ」

隣に座っているオジサンシステムエンジニアがまとめた資料を説明しているのですが、ワタシが思うところの会議資料の説明の基本ができていないのです。ワタシが思うところの基本は次のようなことです。

  • 資料説明は記載していることだけを読み上げる
  • はっきりと聞こえやすい声で話す
  • 議論をするのであればどのタイミングでするかを先に示す

この3つは最低限守って欲しいなぁ、と。

なぜ資料説明は記載していることだけを読み上げるのか

単純なことです。会議をしているのですから、その場で合意するなり、討議して結果を出すなり、新規の宿題として継続案件にするなり、まとめを報告して受け入れてもらうとか、会議の目的に応じた結果に導く必要があります。

であれば、資料を資料に記載どおり読み上げ、理解を促し、議題の目的である討議結果か承認の可否を得るように持っていくことが目的になるわけです。

そうした目的を達成しようとするのに、資料に記載されていないことを説明し始めたら出席者は判断を行えるかということです。

記載していることから議論が広がる場合は、ホワイトボードに広がった議論をまとめたり、口頭でも途中途中で整理をしたりすることをしないと発散したままでタイムアップになってしまいます。

口頭での追加説明は資料がダメ資料

そうした考え方に立てば、説明する資料以上のことをその場で、質問があったわけでもないのにあれこれと補足説明を始めるようであれば、それは資料がもともと説明する資料として書き込みが足らないのです。

つまり、ダメ資料ということ。出直して来てください、というか、事前に誰か見てあげて。

はっきりと聞こえやすい声で話す

横で聞く身になって欲しいのですが。隣に座られるから、同じ組織と思われるのも嬉しくないんですが。

はっきりと聞こえやすい声ではない話し方とは、

  • 自信を持っていない
  • 話す準備をしていない

からではないか、と思うんですよねぇ。シドロモドロだし。そんな説明で聞いている方のみになって考えて欲しいのです。誰一人資料について信頼が置けるかと。

議論をするのであればどのタイミングでするかを先に示す

見ていると、もう成り行き任せなんですよ。これどうなっちゃうんだろう…みたいな。鋭いツッコミがあると黙っちゃうし。

合っていようが間違っていようが、考えたロジックがあるならそれを軸にして打ち返せばいいのに、反発があるとその意見に表面上同意しているような態度を取るんですよね。言葉では。

会議で議題を持ち出しているなら時間内に期待する結果を得なければ参加者の時間を無駄にすることになるのですから。

 

 

そんな会議に毎回出てくるオジサンシステムエンジニア様を見ていると、なんでこの人を選んだのんだろうと不思議になるんですが。

 

 

 

Amazon Primeだと見れない時があるしブルーレイボックスまだだし…

 

 

課題はトラブルになってから這い寄ってくる 

on

日々、顔を見ていないと段々と忘れてしまうもの、それが課題管理です。

多くのプロジェクトではExcelを使って、使いはじめたはいいけれどプロジェクトチームのメンバは誰もが自分のタスクで一杯いっぱいで忘れたわけじゃないけれど、優先順位が低くなっていくパターンなのではないですか。

課題の放置は危険がいっぱい

どんな些細な課題でも課題として起票したときは、まだ課題なんです。ところが些細な、小さな課題も放置してしまうと、後々の作業のボトルネックになったり、手続きが滞って、プロジェクト全体の進捗にインパクトを与えたりすることがあります。

大体、課題はプロジェクトの問題を解決するためにわざわざExcelに書き起こしているのですから、放置しておけばその問題が強化されて手に負えなくなるのは自明のことです。

目に入らなければ優先順位が下がる

人の習性として、視覚に入らなければ気にならなくなるものです。逆にいえば、気になることは視界に入ってくるようになります。

これは普段の日常生活で経験している方が多いですよ。買おうかどうしようか気になると、急に街中でみかけるようになります。これは無意識に探しているんです。だから、思っていたより持っている人が多いことに気づくんです。

課題管理も同じです。サーバの中にあれば、ディレクトリまで辿って、ファイルを開かなければ視界に入ることはありません。視界に入らなければ、ましてや課題が自分の担当でなければ後はどうなっていくかは想像がつくと思います。

課題もWBSのひとつです

課題は解決しなければならないプロジェクトの問題だ、と先に述べているようにプロジェクトとして進捗させなければならない作業のひとつです。

ということは単なる作業です。

ちょっとWBSと違うのは、このアウトプットを作るのにこの作業をすれば良い、というようなインプット、プロセス(ツール&テクニック)、アウトプットが決まっているわけではありません。

わかっているのは、この3つです。

  • 問題
  • 問題を放置したらどうなるかという最悪の予想
  • 解決したい期限

結局、期限があるのは同じなので、進捗させなければならないことは「同じ」なのですから、WBSに課題のカテゴリを作って、朝会でWBSに混ぜて問題の解決状況の確認と判断をしていくのが良いのです。

二重管理にしないために

課題管理をExcelでやってしまうと課題管理自体のExcelWBSの両方に課題のことを同期を取って管理して行かないといけなくなるので、ちょっと面倒です。

この面倒も危ないです。面倒はそれこそ問題で解決しなければならないことです。課題の問題を解決しようとして自分でやらなくなる原因を作らないようにしなければなりません。

一番お手軽なのはチケットシステムを使って、課題も作業と同じチケットとして登録し、ビューを分けておくのが入力の手間を増やさない、という観点でベターでしょう。

ただ、可視化れない、視界に入ってこないので、朝会で確認後、印刷して壁に貼っておくくらいでしょうか。

だったら、カンバンでいいじゃん、なのですが、デジタルデータにしておかないと後で検索できないので、チケットシステムに戻る、が最小の手間で課題を進捗させるのが経験的におすすめです。

 

婚期と育成が下手なマネージャ

on

システムエンジニアを一人前に育てることは大変手間が掛かる上に、育ってみたら期待するような活躍をするかどうかはまた別な次元の話なのです。

ああ、いきなり重いテーマでオープニングしてしまってなんとも言えない気持ちにしてしまったけれど、これはある意味永遠のテーマなので仕方がないのです。

今のマネージャは育成が下手になっている

はっきり言って、今のマネージャで部下なり、プロジェクトチームをプロジェクトを通じて育成するスキルはお世辞にも上手とは言えない。いや、下手ですね。中には上手な人もいますけど。

どうして下手かというと育成の訓練を自ら作っていないから。それも自分の人生として責任を負う方で。いつも書いていますが自分の育成の機会は自分で作るものです。誰かにもらうなんてありえないし、待っていては死ぬまで機会は来ないです。

子育てが一番の育成の機会

婚期が遅いですよね、システムエンジニア。20代で結婚する人はしていますけどそういう人は今だと学生時代からつきあっていますもんね。

しかし、なんとシングルが多いことか、特に中年のシステムエンジニア。シングル自体はいいし、ワタシだってそれほど早くなかったので偉そうに言えませんが。

それはさておき、育成の機会というただ一点だけで言えば、子育てほど育成と期待と現実を身に沁みて経験は他にありません。

少なくとも成人までの20年は養育の義務があるし、成人後も日本の社会は連帯保証をさせられるので青天井の請負契約を暗黙に契約していることと同じなんですけどね。

育成は恋人との関係を疑似訓練できる

そうした関係の上を学ぶには子育ては良いですが、それと同じくメンバの育成をとおして子育ての訓練をすることができるようになります。

そういう観点でだと、メンバ(男女関わらず)の育成を多く経験することで、将来できるだろう彼氏・彼女との関係をどうすれば良いかを経験することができるんですよ。

期待

育成には育成する側の「勝手な」期待や妄想がいっぱいで始まるものです。育って欲しい育成対象の個人の考えなんてこれっぽっちも知らないのにね。子どもなら自分の意思もまだわからないけど。

それでも期待をすること自体は良いのです。ただ、期待を決めつけてしまうことは後の過程で育成する側を縛ってしまうことになるので幅を持たせるか別の選択肢を持っておくことが必要です。

方針

方針は、育て方の考え方、軸です。これがブレると育成対象がこちらをみたときに困惑するんですよ。毎回言っていることが違う、態度が違う、と。育成の方針は、育成対象が関心を持っているだろうとか期待する方向に関連することを目の前のちょっと先に置くだけにしようとかそういった、育成での関与の仕方です。

関係

関係は育成する側と育成対象との距離感です。子どもであっても距離感は大事。育成対象から来る分には全面的に受け入れますがこちらが育成を依存に変えてしまってはいけないのです。育成の皮を被った依存は育成する側を苦しめるし、育成対象の負担だけでしかないので。

 

 

 

作業のプロトコル決めてる?

on

課題管理の話はまた今度にして今日はなぜ作業プロセスが大事かというお話。

みんなが大好きな詳細設計工程でお話を進めます。

突然ですが、詳細設計工程でどんな作業をやっているか1分で書き出してください。

Q 詳細設計工程の作業を列挙せよ

A  _______________

 こんな感じで挙げていただいていればオーケーですね。

  1. 情報収集
  2. 検討・執筆
  3. 内部レビュー
  4. 外部レビュー
  5. 反映・提出

こうした工程の作業を作業プロセスと呼んだりしますが、作業に関係するメンバが好き勝手に作業をしないように作業の順序や作業方法を統一することを作業標準とか単に標準化と称したりします。

なぜ、こうした作業プロセスの標準化が大切なのでしょうか。

作業の標準化はただ同じやり方にしたいからではないよ

作業プロセスを標準化しようというと細かいルールをたくさん作って面等くさいとか、書類がたくさんできるだけで管理のためにするんだと思うかもしれません。

実際、作業プロセスの標準化が本来の目的を失って管理のための管理になっていることが多いからシステムエンジニアは毛嫌いするんですよね。

まあ騙されたと思って、本当の狙いを確認してみませんか。

  1. 情報収集
  2. 検討・執筆
  3. 内部レビュー
  4. 外部レビュー
  5. 反映・提出

WBSを共通化できる

まずは、作業の段取りを5ステップに決めています。ただ、作業順序を決めているようにも見えますが、作業プロセスを5ステップに分けることで、WBSが工程内で統一化されます。WBSのボリューム次第ですが機能をWBSのレベル3にするならば、レベル4はこの5つのステップと共通の作業とすることができます。

「あの機能どこまで完了したの」

「内部レビューまで完了しましたよ」

 となればあとは外部レビュー以降が残っているんだな、とわかりますね。

さらに言えば、5ステップ目が作業をexitしてよいか判定するためのゲートウェイになります。

進捗管理を組み込める

次に、作業プロセスが5ステップになったので、進捗が工程内で同じ単位で計測できるようになります。これについては一昨日のエントリでも書いていたので読まれた方は想定できたと思います。

         WBS 進捗管理 

  1. 情報収集   ○   ○    
  2. 検討・執筆  ○   ○      
  3. 内部レビュー ○   ○      
  4. 外部レビュー ○   ○       
  5. 反映・提出  ○   ○   

品質管理プロセスを組み込める

3番目は、品質管理プロセスが組み込めるようになります。というか既に内部レビュー、外部レビューとして組み込まれていますね。

重要なことは、作業プロセスに組み込んでいるので品質管理プロセスを経ないと作業が完了しないという点です。

         WBS 進捗管理 品質管理

  1. 情報収集   ○   ○    ー
  2. 検討・執筆  ○   ○    ー   
  3. 内部レビュー ○   ○    ○    
  4. 外部レビュー ○   ○    ○    
  5. 反映・提出  ○   ○    ー

誰がどこで困っているかがわかるよ

一番大きいのは朝会などの困っていることでどのステップで困っているかが可視化できることです。なぜなら、作業プロセスが標準化されることでプロジェクトの作業に関する共通のプロトコルになるからです。

プロジェクトが上手くいかなくなる原因のひとつは誰が何をやっているか可視化されず、小さな躓きがプロジェクトの他のメンバの目に触れず、リスクをプロジェクト自ら強化してしまうことになるためです。 

 

(続)%の進捗報告は何かを隠している

on

課題管理って割と影が薄いよね、と書こうかと思っていたのですが、ご質問がありましたので補足をしておいた方が良いのかしら、と思ったので続編です。

「トータルではプラスマイナス0でオンスケになってしまう」の部分が%による表現とどう関連するのかが理解できていません。

ここの部分ですね。

2つのWBSがあって、1つが期限3日前に完了していて、2つ目が3日遅れているとトータルではプラスマイナス0でオンスケになってしまうんです。正しい進捗は、3日遅れですよね。

WBS
|計画|□□□□□|

|実績|■★□□□|

WBS
|計画|□□□□□|

|実績|■■■■■|■■■

便宜上、「□=20%」の進捗とします。

また、「納期はWBS1とWBS2は同じ」とします。

WBS1は、5営業日で完了すればオンスケのところを2営業日で完了です。計画以内で作業が完了すると進捗は100%です。120%になったり、160%になったりしません(当たり前ですが)。

WBS2は、8営業日で完了した(8営業日目を★に変えました)とします。

WBS
|計画|□□□□□|

|実績|■■■■■|■■★

 

WBS2の元々の納期は5営業日で、どのくらい進捗しているか不明(ここでは定義していないので)ですが、完了はしていません。
#例の結果から計算すれば5/8営業日なので63%くらいの進捗率だったことになります。

ここでプロジェクトの進捗会議で何が起きているかを想像してみましょう。

PM「WBS2の進捗は」

メンバ「進捗60%くらいです」

PM「いつ終わるの」

メンバ「あと3日くらいです」

 %で進捗会議をしているプロジェクトの進捗会議の風景としてはこんなやり取りをしていますよね。

WBS1 100%

WBS2  60%

と報告していただければ「正直なプロジェクトマネージャだなぁ」 と思うかもしれませんが、現実には

「なぜ遅れているのか」

「アクションプランは」

と問い詰められるのも想定されるシナリオです。

ところで、%で進捗管理をするプロジェクトマネージャは、都合悪いことは誤魔化したいので

  • ある特定のWBSの進捗が芳しくなくて、対策中で先が見えている
  • 進捗は把握できているので報告はいい感じに楽をしておきたい

とか、進捗管理がダメPMなので、

  • ある特定のWBSの進捗が芳しくなくて追求されたくない
  • 進捗は把握できていないので報告で指摘されたくない

としています。

こういった場合、どう心理が働くかというと、プロジェクトマネージャは

WBS2は3営業日遅れて完了するはずだけど、WBS1は3営業日早く完了したので一緒にしたらプラマイゼロでいいや」

と考えてしまいますよね。

まあ、都合よく報告したいので%は関係ないかもしれません。

でも、0−100%の場合は、そうはできません。 

WBS1 100%

WBS2   0%

ですから。

そういったことを書いていませんでしたが、頭に浮かべながら書いていました。そういった意味合いでは、作業プロセスと%を紐付けしていないプロジェクトの進捗は報告者であるメンバはもちろんプロジェクトマネージャ(もそれを集約するので)信頼性は劣りますね。

もう少し書いておくなら、

進捗を作業プロセスで%を紐付けしていないプロジェクトは感覚でしか%を報告していないので何か都合の悪いことがある

と、いうことが言えます。

まあ、作業プロセスに%を紐付けするのは結局0−100%になってしまうんですけどね。

なので、↓につながるのでした。

 

進捗管理で進捗を正しく把握するには

「完了の個数/完了予定の個数」

で把握しないと意味がありません。