リーダーシップ:見守るからやってみなさい型

この手の上司は、組織づくりや、他のステークホルダとの調整を行って、その部下がやりたい環境を整えるタイプです。
決して放任主義ではありません。
先立って、部下は上司に、そのような方針でやりたいか何が必要か問題ないかを相談する必要があります。その方針を理解、承認して、部下の権限を越える部分の環境を整えたりします。ここでは、上司と部下の信頼関係に基づきことが進められる形になります。
見守り型なので正しく定期的に報告を受けていることが必要で、その報告内容には目を光らせます。問題があり解決が難しそうであればまずは注意を促し、解決をチャレンジさせますが、無理だと判断した場合は、即座に権限を引き上げて指揮を執る必要があります。
この場合他人が指揮を今まで取ってきて、ある程度悪い状況になるまで我慢していますから、そこから成り代わるというのはかなりのマネージメント技量が必要となります。場合によっては単独の問題だけを引き上げて、解決する必要があるかもしれません。
ここでは当たり前ですが、自分の管理責任が問われます。なおかつ解決に当たっては自分が前面に立ちますから、外見えにもその人が問題を起こしたように見えます(くだらない言い訳はしませんから)。責任を負わされることを覚悟して相手に任せるのがこのタイプです。
コラム:責任をとるから好きにやりなさい

私はこのタイプですが、うまくできているとは言い難いです。なかなか難しいものがあります。一人でやりたい人が下についている場合はいいのですが、自分で考え判断をしない人が下についた場合、管理者としては、ほぼ付きっ切りで指導をすることになります。その際は、具体的にやることを指示するのではなく自分から思いつかせるように誘導するのですが、非常に時間がかかります。部下のパーソナリティーによっては、プレッシャーとなってつぶれる場合もあります。
優秀な人は私のやり方に不満を持つ場合もあります。自分に丸投げされているように感じるからです。動機づけをしっかりしてわかってもらうことが重要かもしれませんね。(確かに手を抜きたい気持ちがあるのは本当ですので、部下の言うことを否定できないのですけれども)
まあ私はリーダーシップのある方ではないので、ここは永遠の課題です。リーダーシップ研修を受けても、戸惑うことも多いのでここで整理しています。今後も試行錯誤です。お互いに頑張りましょう。

悪い例:放任型
任せるという名の放任はだめです。プロジェクトを成功に導くのがマネージメントですから、放任はその義務を放棄しているのにほかなりません。責任を負うというのは謝ることではありません。責任を負うというのは成功させるということで、失敗しそうになっても成功に捻じ曲げることです。
どんな場合でも状況だけは把握し、行動できるようにしましょう。自分がフォローできる範囲で任せるべきです。そういう意味では自分の能力もある程度把握しておく必要があるかもしれませんね。「この程度ならまだフォローできるから注意だけして様子を見よう」という感じですね。

リーダーシップ:みんなでやろう型

このての上司はみんなの気分を盛り上げるのが得意です。みんなでやるからと言って管理しないとか支持しないというのではありません。このタイプの上司はビジョンを明確にもち、それをみんなに伝えます。そのビジョンに沿ってそれぞれに行動を促し、みんなで同じ方向同じ行動をとっていると感じさせ、モチベーションをあげていきます。

この方法にたけていると、無理なことも成功させることができることがあります。たとえばプロジェクトがトラブル続きで先が見えなくなり要員が疲弊してきているときに、この手のリーダーが主導権をもって行動すると、ビジョンを示してくれますから、先が見えない中に、あるゴールが見えてくるわけです。そのゴールに向かう具体的な行動を指示することで、みんなは安心してくるのです。「今は大変だがみんなでがんばろう!」という雰囲気にしやすくなります。
ビジョンがあいまいだったり理解できない物だったり、そのための行動が見えないとなると無意味どころか、信頼関係も失ってしまうかもしれません。先を見る高い能力とそれを伝える高いプレゼンテーション能力が求められます。

悪い例:各サブシステムリーダが優秀だとありがちですが、みんなでやろうと声だけ出して、ビジョンを示さず、みんなにいろいろ任せて、自分で判断しない場合。
何となく、それぞれのサブリーダが優秀で、うまく回っているときはいいです。
トラブルがあって管理レベルのディシジョンが必要になった時にとたんにうまくいかなくなることがあります。
あるいは、サービスイン真近になってシステムの整合性が取れずに大事になることがあります。どんなにサブシステムリーダが優秀でもマネージメントレベルで整合をとらなければならないことはたくさんあります。それらをせずに進めると後につけがまわることに注意が必要です

リーダーシップ:こうしろあーしろ型

一見マイクロマネージメント的に見える。自分ですべてを掌握して、細かい指示を与えていくタイプです。人に任せることができない優秀な人に多いやりかたです。かなり高い能力が必要とされますから、自分にも厳しい人が多いです。大きなPJになるとほかの人は多分まねできないレベルにあたったりします。
そういう人の部下には業務遂行能力がある人が下につくと大きな力を発揮します。
管理能力は組織を管理して適切に導く力、業務遂行能力は担当している業務を自ら遂行する能力です。これらは違うスキルですから注意が必要です。(大抵は有能な人は両方できるんですけどね。)
問題点としては、人が育ちにくくなる可能性があります。部下の業務遂行能力は格段に上がります。遂行レベルに関しては、細かくチェックされて学習の機会が多いからです。一方チェックしてもらえることから、自ら胃の痛くなるような責任を負う力が弱くなります。自分ややらなくても、あるいはできなくても、怒られるが、すぐにほかの人が割り当てられ、PJには何ら問題が無いように進みます。組織間調整も上司がやってくれますから、自分の範囲の仕事をきちっとやっていればいいのです。
ある意味部下としては楽ですがそれでいいのかというと疑問が私にはあります。

悪い例:かき回しがた
能力が低い管理者がこれを行うと単純にかき回しただけになることがあります。
例えば問題の本質ではなく、得意分野として管理者がとらえ、そこだけを深堀して支持を行い、ほかにとりうる手段や、大局的解決方法を検討しなかった場合に、PJがあらぬ方向に流れることがあります。
現場は重要でないと思っていることに時間をかけさせられるのもこの一例です。
始末が悪いことに、この手の管理者は自分が正しいと思っていますから、なかなかひかないし、気が付きもしません。ある意味それでいいのですが、ちょっと大変です。
注意が必要です。
(それでいいといった意図は、管理者としては一貫したポリシーを持ち、そのポリシーに従ってPJ推進をしていくことにより、周りが対応しやすくなり結果的にはおたおたしても最終的にはうまくいく組織になることがあるからです。リーダーとしてはポリシーがないのが一番困るからです。)

リーダーシップとは

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

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

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

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

リーダーシップの色々

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

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

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

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

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

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

コラム:怒る、叱る

「怒ることと叱ることは違う」、よく言われることですが、整理してみましょう。
怒る場合典型的なのは「ぷりぷり」という感じでしょうか?つまり、怒るのはその人個人の感情の状態で、その行動は、その人の思いや感情状態を解決したいときあるいは、相手に伝えたいときに出る直接的な行動になります。
叱る場合も相手に何かを伝えるという点では一緒ですが、伝えたい事柄が「自分の感情状態」ではなく、「間違いに対する回復」である点で大きく違います。
叱る手順としては、「気づかせる⇒理解させる⇒反省させる⇒行動の促し」となろうかと思います。空き地で野球をして、窓を割った時に出てくるかみなりオヤジ的にやるならば、

①気づかせる「こらー!!」
②理解させる「こんなところで野球をやってはいかーん、窓を割ってしまっただろう!」
③反省させる「何をしたから窓が割れたかわかるな、ごめんなさいは?!」
④行動の促し「もうやるなよ、気を付けるんだぞ」

という感じでしょうか。
叱るときは、何を伝えたいのか、具体的には、どういう気づきをさせるべきと考えるのかを整理して、自分でわかったうえでしかるべきです。
部下に失敗をさせてしまった上司を叱る場合、管理せずに放置していたことを叱るのか、その部下が失敗しないように事前にチェックすべきであったことを叱るのか、失敗したときにその傷口が大きくならないように行動しなかったことを叱るのか、それぞれその管理者が何を怠ったかによってポイントを絞ってしかるべきです。
だいたいの叱るポイントを押さえたら、今度は叱り方ですが、①のところで直接てきにこちらから言うという方法もあります。ほかにも、何が悪かったと思うかコーチングの傾聴手法で引き出す手もあります。自分で引き出した場合、そこには理解もついてきているとよいでしょう、注釈を加えてたとえば「そうだなそこのところが足りなかったな、別な観点でこう見ると、そのことがよくわかると思う。過去にもこういう例があった」などと、理解を深まらせる話をするのもよいでしょう。そのうえで期待する行動をさせるのが良いと考えます。
やってはいけないのは、複数の事柄を抱き合わせで叱ることです、何をしていいのかぼんやりしてしまいます。子供や犬をしつける時のやり方です。人間は大人になったとしても本質的には変わりませんから、やはり、叱るときにはポイントを絞ってもっとも理解させたいことのみをしかるべきです。

大人なんだから」と思うかもしれませんが意外と重要ですよ。

コラム:官公庁・公共系と民需では要件定義の立場上の考え方が逆

かならずしもあてはまるものではありませんが、官公庁と民間では要件定義の持っていきたい方向が逆になります。
何が逆かというと、要件定義において、ベンダー側のアプローチとして民需ではどんどん機能を入れるようにアプローチをします。しかし、官公庁では機能を減らしていく方向にドライブしなければなりません。
なぜかというと、調達方法の違いに原因があります。
私は民需系のシステム開発経験はないのですが民需では多く、先のコンサルや要件を確認する中でやることを決定していき、やることが明確になった段階で再度見積もりを提出し、協議していく形になります。この時、良い機能やほしい機能がたくさん盛り込まれていれば、要件を削るのではなく、予算を増やしてもらえるかもしれません。
官公庁系の場合、調達は入札になります。完璧に作った仕様書に基づき、それを実現するのにいくらでやってくれるかを入札します。要件定義でこの仕様書項目で具体的になにをどこまでやるのかを協議しますが、やることが増えても費用は増えません。入札で金額が決まっているからです。
官公庁側担当者は、これはこういう解釈だこういうものだと言いながらできる限りの要件を盛り込もうとします。ベンダー側は仕様書からはそのようなことは読み取れない、書いてないと主張して、やることを予算に収まるように極力少なくしようとします。なかなかにお互いに苦しい交渉です。官公庁側もわざとそうしているのではありません。仕様書では書ききれなかったり、その時には決まっていないことも多いのです。官公庁系の場合要件の齟齬で大赤字プロジェクトになることもしばしばです。お客様に合わせた仕様書の読み取り方など慣れていないと危険ですね。

経営者としては無駄な失敗をしないためにも官庁・公共の案件では慣れた人を当てることが重要です。







イギリスの経済学者が役人の考え方や予算のかけ方を解説!本当かウソか、こんな風に国家予算は膨れていく。


政府の働きなど、間違えない政府の考え方を述べています。

技術力-SI技術

お客様の業務を理解して、システム全体をデザインして導入し、保守していく能力です。システムに関すること全部じゃないかとおっしゃるかもしれませんがその通りです。
ここでは、技術を分割している関係上、お客様の要件を理解してシステムの実装に落とすことに着目します。要件定義能力といってもいいかもしれません。

お客様とお話ができるというのは重要なことです。「どういうこと?」と思うかもしれませんが、業務をシステム化する以上、業務を知らなければできません。たとえば医療業界では医学の専門用語が飛び交い、業界の常識が当たり前のように理解されていなければ使えない物が出来上がることになります。場合によっては、生物学の常識を知らないと、たとえばデータベースのキーに患者の名前、生年月日、血液型等を入れてしまうかもしれません。病院では血液型は変わる可能性がありますからそのような場合でもキーにはできないのです。(白血病などで骨髄移植をすると血液型が変わる可能性がありますし、病気の種類によっては検査上違う血液型と判定されることもあります。)
流通業界ではリテイルの常識を知らないとシステムの拡張性に関する作りを間違えるかもしれません。部門が増えたり商品カテゴリーも商品特性ではなくメーカーによって違う扱いにしてあったり、同じメーカでも複数の部門にまたがることもあります。(塩コショウ、焼き肉のたれは、一般食品(グロッサリー)扱いのものと精肉部門扱いのもの(生たれで冷蔵が必要なもの、ハムメーカの塩コショウ等)があります。)これらは会社の方針によりますが、このことを知って柔軟に拡張できるシステムにしていないと、新たな取扱商品が処理できないことになりかねません。同一商品他部門扱い価格違いチェック等の問題も発生します。
研究系などでは研究論文を読まないと駄目である場合があったりします。この場合は大学等でその分野の研究に携わっていないと理解できないことも多いです。実務では論文の内容をシステムで実装してくれという乱暴な依頼も経験しています。
官公庁のシステムでは法律を執行するためのシステムですから、当該法律(たとえば社会保障関連の法律群)を理解していないと、システムが作れなかったり、仕様書に法律と行政解釈(電話帳の2倍くらい厚い)がついてきたりします。

これらの業務知識は一朝一夕では身につきませんが、身についてしまえばそれは資産というべきノウハウになります。こういうノウハウがあるためにISerはこのような各分野における業務知識を独占しようとします。
極端な業務知識でなかったとしても、その業界の人と話ができるということは重要です。これ自身SIに携わる人にとっては技術・能力となることを理解する必要があります。

技術力-システム基盤技術

開発技術のほかOSに対する技術、システム構成、HW構成に関するものも身に着けてください。これらはシステム基盤技術と呼ばれます。基盤技術には基盤技術の専門家がいますから業務系アプリケーションプログラマはあまり深くやる必要はありませんが、自分やチームが作ったプログラムがどのように基盤リソースを使っていくかは理解してください。制御系、基盤ミドル開発者はSWのHWに対する影響を深く理解してください。
システムは必ずサイジングをしますが、ここでどの程度リソースを使うかどの程度のリソース、性能が必要か答えられるとものすごくその人は重宝します。チームを任せたくなります。
システム構成が組めると超上流つまり開発の上流工程の設計よりさらに上流の提案工程に参加する能力があることになります。民需は要件定義を経てからシステム構成を組みますが、入札案件である官公庁は要件定義前の提案段階でシステム構成まで組み切って入札金額を決めて参加することがあります。ここでいかに精緻なリソース見積もりができるかで入札金額を抑え、落札することができるかが決まります。
基盤の専門家は業務アプリケーションのことはわかりませんから、業務アプリケーションSEが個別の必要リソースを算出することになります。

何をやらかしたらどのリソースが枯渇するかという経験も重要ですね。性能問題を解決できることは後々まで残るSEには重要なことです。

技術力-運用技術

運用に関してみると、派手な分野ではないように見えます。しかし、システムを使う上では重要な位置を占めていてこれ自体技術といえます。

(イ) 業務運用

業務そのものをしたり業務をサポートする運用業務を指します。業務そのものをする例では、人事システムであれば、人事異動時の大量のデータの入力検証、社員証の発行連絡等となります。業務をサポートする運用の例としては、ヘルプデスクによる業務システムのトラブルに対応したり、業務システムの使い方を講習する研修を行ったりとなります。

システムの開発を請け負った場合はあまりここまではないのですがSIを請け負った場合は業務そのものまで踏み込んで実施することが多いです。

(ロ) システム運用

この場合のシステム引用はシステムの稼働を監視して常に稼働状態を保つことを意味します。

(ハ) LCM

数年前から言われだした新しい考え方でライフサイクルマネージメントというものがあります。システムのライフサイクルをすべて管理して運用するという考え方です。設計から運用まで請け負うSIと何が違うのかというと、現在のシステムの使われ方や問題点を現行の運用の中で吸い上げて分析し、システム改善や次期システムのシステム化方針に持っていき、時期につなげるというサイクルを回し続ける考え方です。

民間の企業ではこれらの考えに基づいてシステムを一手に引き受けるというのは企業の戦略から有効であろうと思います。

官公庁では問題があって、自社内にLCM部隊があって回していくならともかく、SIとして外に出している場合、この考え方だと次期システムの仕様を現行業者が決めることになります。公平性の観点から仕様を決めた業者(コンサル業者)は入札に参加できませんから毎回業者が変わることになるか、そのようなことになるような調達は業者として避ける傾向にあります。なぜなら、費用をかけて身につけたノウハウが無駄になるからです。多くの場合業者は血を流しながら初回はノウハウを身に着けるのです。

技術力-開発技術

たとえば、開発技術に優れているのであれば、困っている人がいたら助けてあげましょう。PMがある開発担当者のところで悩んでいてそれがその担当者のバグでなかなか治らなかったとすると、あっさり解決してあげてください。PMに対するアピールとしてはかなり強力です。タイミングとしては、やることがなくなってどうしていいかわからず、固まっているときです。何かをしているときに口を出すとただのおせっかいになってしまします。

固まっている人がいたら声をかけてあげましょう。
正直みんなは悩みすぎです。一つのバグに1日とか2日悩んでたというのをよく聞きます。がっくりです、一時間悩んでわからなければいったん棚上げして後ででもチームで相談すればいいのです。一時間悩んで解決しないものがその人が2時間悩んで解決するとは思えません。文殊の知恵を集めましょう。
私は自分でも解決しますが、わからないことや不得意なこともあります。PJの中で誰がどの技術に詳しいかどういう性格をしているかを把握しておきましょう。困ったときに必要な人に聞いたり、つないであげるだけでもかなり強力です。
自分がわからなかったときどうするか?私は1時間たっても解決しなかったら騒ぎます。みんな寄ってきてなんだかんだ解決してくれたりします。ありがたいです。

技術はどのように身に着けたらよいでしょうか。
私は開発技術は60%センスだと思っていますが、残りは他人のソースをどれだけ読んだかと考えています。ソースを作る時の考え方を理解して何を考えてこうしたのかこうすべきなのはなぜかということを考えつつソースコードを読むのです。そうすると、だんだん物語を読むように、ソースが語りかけてくるようになります。書いた人の性格がわかったり、だれか書いたかわかるようになってきます。
制御や低レベルの関数群などはベテランが作るべきです、またベテランが作っていることが多いです。彼らの経験がそのソースには生きています。なぜこれだけの機能なのにこんなに長いのか?堅牢な仕組みが出来上がっているかもしれません。インターフェース関連は特に経験が生きてくる面があります。あるいは単純に冗長なだけかもしれません、機能の堅牢性だけでなく、メンテナンス性、正規化等の観点からもソースを読むようにするといいかもしれませんね。

ソースを読むということからするとOSSに手を出すのもいいかもしれません。ここでは技術力だけでなく人脈も身に付きます。私もいくつかのコミュニティーに参加して楽しんだことがあります。この世界では飛び込めばすぐそこにあります。自分でもやれるし人に会うこともできます。いろんなOSSコミュニティーがあります。ぜひ飛び込んでみてください。







私はもともとCプログラマだったのですが、マニアックなCの使い方も面白いですよね。仕事ではメンテナンス性が悪くなるので可読性を優先しますが・・・


オープンソースコミュニティーに参加するものいいですが、自分で運営してみるのもいいかもしれませんね