例えばバリューストーリムマップで作業プロセスを見直す

(私)センパイって、週末って何しているんですか。
(先)え、週末?週末なんてないよ。忙しいからなー。
(私)悪いことしているんでしょう。
(先)そうだよ、如何わしいことをしているんだよ。
(私)イカガワシイとか、マジでやってそうで怖いです。ネットでつるしあげられないでくださいね。私、取材に巻き込まれたくないので。
(先)大丈夫だよ。如何わしいけど合法だから。
(私)そっちの方がやばそうです。グレーっぽくて。それで何しているんですか。
(先)聞きたいの。聞いたら巻き込むよ。
(私)仕事で慣れてますから。
(先)土曜日は勉強会だな。
(私)へえ、センパイも勉強するんですか。
(先)相変わらず口が減らないというか。
(私)だがそこが可愛いんですよ。
(先)自分で言うな。
(私)センパイが言ってくれないからです。それでなんの勉強会なんですか。
(先)アジャイル
(私)アジャイルってアジャイルアジャイルですか。
(先)頭大丈夫か。
(私)いつも明晰ですよ、センパイよりは。それで何しに行くんですか。そのアジャイルの勉強会とやらには。
(先)内緒。
(私)だって、センパイのプロジェクトはウォーターフォールですよね。アジャイル関係ないですよね。
(先)見えているものだけが世界に存在するなんて誰が言ったんだい。
(私)また中二病ですかー。
(先)そうじゃないよ。真面目に。見た目で判断していると騙されるよ。
(私)どう言うことですか。
(先)ウォーターフォールでやっているのはそれでレポートする必要があるからさ。WBSを作るのだってマネジメントのモニタリングに合わせないといけないからね。でも、開発プロセスはマネジメント側に見えないだろう。インタフェースは計画と実績の進捗だからさ。
(私)それでどうしてアジャイルを勉強する必要が。
(先)プロジェクトはいつも同じ条件では出来ないじゃん。メンバは誰かは入れ替わるし。私ちゃんみたく新人が入ってくることもあれば、誰かが出て行くこともあるしね。スキルレベルもプロジェクトで経験を積めばレベルが前より変わるしさ。顧客も違うし、作るものも何一つ同じものはないし。一番違うのは全く同じ要件で出来上がるシステムだったとしても、中身のコードは作るときのコンディションで違うんだよ。毎回微妙に違うラーメンのスープみたいなものだよ。
(私)コードをラーメンのスープに例えるのってどうなんですかねー。
(先)そこじゃないよ。例えなんだから。プロマネ業はさ、メンバの進捗の障害を取り除くのは当たり前だけど、その障害が初めから分かっていたら障害になる前に取り除いておきたいし、できるならその障害なんて存在しない環境で仕事をしてもらった方がパフォーマンスは発揮できるじゃん。
 例えばさ、作業でミスが起きたらメンバを叱ったりしない。ルールを破ったりしなければね。これは絶対。プロセスで起きたのなら、作業プロセスを見直す。バリューストリームマップを使ってね。
 そう言う風にいつも考えているんだよ。
(私)センパイって変態さんかも。いつもそんなことを考えているんですか。変態だー。
(先)想像していたよりオレが真面目過ぎて驚いてるのかもしれなけど、なんだ、その褒め言葉は。
(私)褒めてないし。
(先)じゃあ、行くか。土曜日。まだ残席あったから今から申し込めばいけるし。一杯だったら、運営に頼んでスタッフ側で入れてあげるよ。
(私)運営に顔が利くんですか。すごいですね、センパイ。あれ、スタッフ側に入れてあ・げ・る、ってどう言うことですか。
(先)言っていなかったっけ。運営スタッフなんだよ、オレ。じゃあ、ようこそ、スタッフに。集合は9時な。場所はメッセ入れておくからさ。ホイホイのぽっちっと。あとfaebookのグループに登録しておくわ。これでっと。あ、自己紹介くらいしておいてな。
(私)ええぇぇ…。

 

 

 

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

 
トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 

 

 

頭の中を可視化できないプロマネはメンバを不幸にする

「いつまでお仕事をしているんですか、お昼ですよ。今日はお寿司屋さんに行きますよ」
「あ、もうそんな時間なんだ。珍しく集中してたよ」
「ほらほら」
「わかったから、ちょっと待って」
「それでどうして珍しく仕事をしてたんですか」
「それおかしい。仕事はいつもしているんだからさ。それに人に言われるとちょっとカチンとするな」
「あれー、仕事は納期までに終わらせろ、淡々とやれっていうのが口癖なのに。お仕事ラブなんですねー。焼けちゃう」
「(あーもう)プロジェクトのさ、メンバが手が回らないところの仕事を手伝っていたらついつい楽しくなっちゃったんだよ」
「へー、メンバのお手伝いすることもあるんですね」
「たまたまできるところが遅れそうだったんだよ。仕方がない」
「センパイはさぁー、プロマネじゃないですか」
「そうだよ」
プロマネにエンジニアの技術が必要だと思いますか」
「一般的にエンジニアのキャリアパスはエントリのエンジニアから分岐する様に作られているからなぁ。必然と何かしら持っていると思うけどな」
「それはそうかもしれませんが、プロマネになってからも」
PMBOKとかさ、そうした欧米型の職能別の役割分担がはっきりしている仕事の仕方だとプロマネはプロジェクトマネジメントの専門家として責務を果たないとダメだろうから必要ない、が答えなんだろうな」
「それって日本は違うってこと」
「現実的にプロマネを1人月コストを持てるとか、1人月売り切らなくてもペイできるコスト構造になっていれば問題はないはずなんだけど」
「コストの話は難しいからそっちに置いて、結局、技術は必要なんですかー」
「持っていることに越したことはないけれど…」
「mustじゃない、wantだよってこと」
「そうかな。多分というか原則論というか基本軸で考えるのがいいんだ。こういうテーマは」
「どーいうことですかー小学校5年生の女の子にもわかる様に教えてくださいー」
「(…なんで小五女子なんだ…それはさておき)PMの仕事は何か、で考えればいいんだよ」
「はいはーい、PMさんのお仕事はなんですか」
「プロジェクトチームの進捗の障害を予測すること、実際に起きたら小さなうちに除去するなり、回避するなりの判断をすること、完了する見通しを立て終わらすこと、かな」
「あー、それ聞いたことあるかも。どこで聞いたのかな…忘れた」
「おい、いつもキックオフやチームメンバが増えたときにオレが言っていることじゃん」
「ウソですよー。覚えてますから」
「ホントか。そう、ならいいけどさ。伝わっていないとしたら寂しいじゃん。いつも聞いてもらっていると思っているのにさ」
「大丈夫ですよ、センパイの言葉はちゃーんと私に届いていますから」
「よかった…。じゃない、基本軸なんだけどさ、役割分担を役割が少しずつ被る様にして、その分掌を果たせる様に環境を作ることが必要なんだ。そのためのSOWでもあるんだし」
「そうですね、センパイのプロジェクトだけは必ず分担図を配りますもんね」
「そういう思いがあるからさ…。分掌でミスるとメンバの仕事の負担も変わってしまうからさ。プロマネの頭の中を可視化することがとてもチームにとっては大事なことなんだよ。だって実現するのはチームだからね」
「そうですねー。何考えているかわからないPMのプロジェクトに当たると早く任期終わらないかなーって思うもん」
「それはそれで問題あるな」
「そうかー。プロマネに技術が必要なのかなと思って聞いたけど、PMの頭の中を可視化するって大事ですねー」
「マジ大事」
「あっ、きましたよ。ランチのお寿司。いただきまーす」

 

 

 

PMに技術が必要かどうかはまたの機会として、プロマネが実現したいプロジェクトの運営やプロジェクトの進捗のさせ方は全部、プロマネの頭の中にあるんですよね。

それをタイミングよく見せる、つまり可視化して伝えることができなければ、チームは右往左往して混乱をするのです。無駄な試行錯誤をさせられて、出てきたものを評価する様にあれこれ指示を出すのは間違いです。何より、プロマネの責務を果たしていないしイズムにもインテグリティに欠ける行為ですから。

 

 

PMBOK対応 童話でわかるプロジェクトマネジメント

PMBOK対応 童話でわかるプロジェクトマネジメント

 
マンガでわかるプロジェクトマネジメント

マンガでわかるプロジェクトマネジメント

 

 

 

センパイとコスト意識とランチと

「センパイ、お昼行きませんか」
「もうそんな時間かー、今日はどこに行こうか」
「今日は、コスト意識を持ってお財布に優しいお店を選びましょう」
「何っているんだ。いつもはガッツリと食べているのに」
「そんなことないですって。いつも、コスト意識を持って仕事をしているんですから」
「嘘とは言わないけどさぁ、嘘っぽいわ」
「そんなことないですってば」
「それで」
「何がです」
「何があったのかって聞いているんだよ」
「ああ、マネージャのメールでコスト意識を持てって書いてあったから実践しているんです。エライでしょ。褒めてもいいんですよ」
「またコスト意識が出てきたか。何度目だ、コスト意識。今は前みたく業績それほど悪くないはずじゃなかったっけか。もしかしてどこかでまた炎上しているか…」
「何をブツブツ言っているんです。危ない人ですよ。ブツブツ言わなくても危ない人ですけどね、センパイは」
「はいはい、それでどこに行きたいの」
「そこはほら、コスト意識の高いセンパイが良いお店をオススメしてくれるんですよ。そうじゃなかったら、美味しいお店に連れて行って奢ってくれてもいいんですよ」
「何言っているんだ…。そうだ、前から気になっていた店があったんだ、そこに行ってみる」
「わ、新しいお店の開拓ですね。ちょっと楽しみ」
「で、センパイ、コスト意識を持ってってなんですか」
「(ずるっ)え、さっきまでコスト意識、コスト意識って言っていたじゃん。わかってないで言っていたの」
「えへっ」
「…いつものパターンか。そうだな、会計できるんだっけ、簿記とか」
「さっぱりですね」
「家計簿つけてる」
「いいえー。上限決めてそれ以上使わない様にはしてますよ」
「(あら、感心な子だな、いや、騙されちゃダメだ)そうだなぁ、仕事でのコスト意識の話だからなぁ。例えるなら家計がイメージしやすいんだけど実務と違うからなぁ」
「一人でブツブツ言っているとおまわりさん呼びますよ」
「いいから、それより注文しよう、これな」
「じゃあ、こっちにしようっと。それでコスト意識ってなんですか」
「そうだな、まずは言っている人の立場で考えてみようか」
「えっとマネージャさんのことですね」
「そうそう、それでどうしてコスト意識を持てって言っているんだろうね。何か思いつく」
「えー、わからないから聞いているのに。センパイは灰色の脳細胞はちっちゃいんですか」
「脳はみんな同じサイズらいしいよ」
「またまたまたご冗談お上手、センパイは。同じにしないでください」
「そうだねー(棒。さて、どうしてコスト意識を持てって言っているのだろう。文字面から、文面通り捉えれば、コストを認識しなさい、っていうことになるね。認識するということは業務上、ーー多分、それぞれのメンバの仕事上で関わる範囲というかコストの責任を担う範囲でーー、だろうと思うけれど、プロジェクト上のコストに何があるかをまずは知らないと認識しようがない」
「そうなんだ」
「そうだよ。知らないと理解できないからね。コストとは持っているリソース、資源だよ、それを外に払い出す行為だ。キミの給与は、プロジェクトの予算から支払わされている。それで、だ。プロジェクトにアサイメントされるとアサイメントが終わるまで固定費としてプロジェクトからコストが支払われ続ける。たとえ、仕事の成果があろうともなかろうとも」
「難しいこと言いますね、センパイのくせに。えっと、遊んでいていも仕事をちゃんとしていても同じ様に給与がもらえるってことですよね」
乱暴に言えばそういうこと。それを認めてくれるかどうかは別だけどな」
「是非それでやらせてくださいー。プロジェクトのニートにな・り・た・い」
ニートって古いな。死語だよ、死語。それでだ、ここでも一度、元に戻ってコスト意識を持てってどういうことかを考える。さずがにニートをしているメンバはいないはずだ。進捗でバレるからね。その上で考える。何がコスト意識に結びついているか」
「面倒なこと考えますねー、もう、スパッと行きましょう、センパイ」
「キミが聞くから考えているのに…もうやめるよ」
「やめないでー、素敵、センパイ」
「そうかな、かっこいいかな、オレ。じゃあ、続ける。プロジェクトにアサイメントされているメンバは何かしら成果を出している。その上で、コスト意識を持てと言っているとしたら、何に大してか、だ。何も支払っている給与を減らしたいわけじゃない。そんなことをすればみんな辞めてしまうからね。じゃあ、経営者として何を求めているかだ。そうか、効率なんだな」
「効率ってあの効率」
「あのがなんのかはわからないけどさ、たぶん、その効率。プロジェクトのリソースに対して支払っている給与などの費用をどれだけ効果的に利用しているかということだな」
「小学校5年生の女の子に説明するくらい優しく」
「意味がわからない。エンジニアの1人月の成果を1とする。面倒なので給与も1とする。エンジニアが1働いたら、プロマネは1のリータンの成果を得られる。計画どおりに」
「オンスケってことね」
「まあ、そうだ。そこで給与はそのまま1で、エンジニアの1人月で得られる成果が1.5になったらどうなる」
「生産性が上がってますね。そんなことあり得ないでしょうけど」
「あったとしたら」
「仕事が早く終わりますね」
「そうしたら」
「早く帰るー」
「いいけどマネージャとしたら、0.5人月分の成果を先取りできるわけだ。コストを伴わなくて」
「ラッキーですね」
「そうなんだけどさ、つまりだ。マネージャは効率を上げなさいと言っていると考えていいってことになる」
「でも同じやり方だとそんなことはゼーッタイに地球上で存在しないですから」
「どうしたら実現できる」
「やり方変えないと」
「そういうこと。作業プロセスを変えて効率化を図りなさい、ってことだよ」
「そうすると色々ツールとか必要になりますよ。お金がかかるとコストが増えますよ。いいんですかそれで」
「そうした生産プロセスを変えても、そのためのコストが増えても全体のコストダウンが計れる様な効率的な作業ができる様にコスト意識を持ちなさいってこと」
「そんなの暗黙が多くて普通のエンジニアに理解なんてできないですから。無理ゲーです」
「まー、伝わらないわな。だから繰り返し言っているけど全く効果がないんだよ」
「そこはコスト意識を持ってやってもらわないといけませんよ、センパイ。今日もご馳走様でした」

 

 

STARTUP(スタートアップ):アイデアから利益を生みだす組織マネジメント

STARTUP(スタートアップ):アイデアから利益を生みだす組織マネジメント

 
「数字」が読めると本当に儲かるんですか?

「数字」が読めると本当に儲かるんですか?

 

 

 

エンジニアに人気のないマネージャ業ほど面白い仕事はない

「そう言えば、どうしてマネージャになったんですか。大変でしょう」
「辞令が出たからねぇ」
「それはそうですけど。辞令が出なければなれませんから。でも、断ることだってできたんじゃないですか。プロマネが好きだと言っていたじゃないですか」
「どうして断る話になっているの」
「だって人気ないですよ。なりたいキャリアパスの最下位をプロマネと争っているじゃないですか」
「別に忌み嫌うような職種じゃないと思うけどなぁ。面白いよ、マネージャ業もプロマネ業も」
「はたから見ているとプロマネだって大変に見えますよ。マネージャになったら幾つもプロジェクトを見ないといけないし、メンバは我儘言うじゃないですか」
「そうかな、それほどでもないと思うけど」
「1つのプロジェクトをマネジメントしているだけでひぃひぃ言っているプロマネが多いいですよ。その1つだけだってろくにコントロールできていないんですから」
「それはたまたま難しいプロジェクトだったんだよ。ワタシが担当してきたのは偶然にもそうでなかっただけだよ。今も複数のプロジェクトをプログラムマネジメントしているけれど、みんな協力してやっていてくれるから助かっているよ」
「いやいやいやいや、そんな教科書的な答えはいらないですってば。と言うことはアレですか、格の違いってやつですか」
「よくわからないけれど、同じだと思うんだけどなぁ。プロジェクトマネジメントもプログラムマネジメントも」
「だから同じじゃないですって。どうしたら同じになるんですか」
「そうだなぁ。こちらのリソースは1つだよねぇ。これは変わらない。だからお仕事の優先順位をつける。優先順じゃないよ、順位ね。順位はプロジェクトにつける。プロジェクトの進行の障害となる課題の芽がないかを探す。レポートは見るけど、課題管理表や障害管理表の方が有益な情報が多いかな。まずはプロジェクトの進捗上の診断を定常的に行うねぇ」
「それだけでも時間が幾らあっても足りないじゃないですか」
「だから、優先順位をつけて割り振るリソースにキャップをかけるんだけどね。あと」
「あと」
「勤怠から残業時間を見ている特定メンバに偏っていないかとかさ、遅くまでいるのに残業をつけなていないなんてしていないかとかさ」
「勤怠は36協定があるからですか」
「それもあるけれど、まずはプロジェクトのコスト面と言う別の切り口かな。オンスケでもコストが2倍掛かっていたらそれはプロジェクトに問題があるし、遅延しているのにコストを計画どおり使ってしまっていても問題があるし、遅延していてコストも相応にしか使っていなければ何か問題があるし。もちろん、健康面の切り口あるよ。計画外にチームから離れてしまうことになったら別の問題になるからね」
「ほら、あと面談もしなければならないし、個人的な相談だってあるでしょう」
「面談はしっかり時間を取らないとね。全員が全員上手に時間を使って話せるとは限らないからね。マネージャというだけで緊張してしまうメンバ立っているらしいからね」
「それでちゃんと話せますか」
「そう言い切れないのはまだまだ勉強が足らないんだろうねぇ、ワタシが。だからさぁ、雑談をするようにしているんだ。お菓子ボックスを置いているのもね、別にやる必要はないんだよ。でもさ、きっかけがあれば話しやすいでしょう。どんな技術に関心を持っているとか、困っていることとかさ」
「色々考えているんですねぇ。ますます勘弁して欲しい感じの仕事に思えてきた」
「キミはゲームするじゃない。それだって準備をして対策をして攻略するじゃん。同じだよ。マネージャ業もプロマネ業も」
「ゲームに例えないでくださいよ、ゲームするときに思い出しちゃうじゃないですか」

 

 

マネージャ業は、ビジネスの継続を担うのですがその中には、一つひとつのプロジェクトを計画した範囲内で着地するかを見ていなければなりませんし、プロジェクトを担うメンバを育成する機会を作らなければならいです。

もちろん、プロジェクトごとの再三なり、ビジネス全体での採算を確保しつつ、です。ですので会計の知識も必要になります。

定量的に押さえられるところはいいのですが不確実に変動する人の動きを許容しながら成長を助け、伸ばしつつビジネスと紐づけていくなど同時並行で行わなければならい様に見えますが、全ては優先順位をつけてリソースをタイムスライスに合わせて割り振ってやりくりするほかないです。

そうした中でどこに仕事の楽しさを見つけるか。マネージャこそ、オペレータになってはいけないのです。マネージャが創発的な考えを持って行動し続けなければ、メンバは下請けのオペレータになってしまうので。

 

 

人を動かす 文庫版

人を動かす 文庫版

 
マネジメント[エッセンシャル版] - 基本と原則

マネジメント[エッセンシャル版] - 基本と原則

 
マネジャーの教科書――ハーバード・ビジネス・レビュー マネジャー論文ベスト11

マネジャーの教科書――ハーバード・ビジネス・レビュー マネジャー論文ベスト11

 
自分の小さな「箱」から脱出する方法 ビジネス篇 管理しない会社がうまくいくワケ

自分の小さな「箱」から脱出する方法 ビジネス篇 管理しない会社がうまくいくワケ

  • 作者: アービンジャー・インスティチュート,中西真雄美
  • 出版社/メーカー: 大和書房
  • 発売日: 2017/08/25
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る
 
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

 

 

エンジニアでWIPを知らない人はまだ効率を知らない

「お、珍しい。今日はどうしたの」
「あのですね、効率的にやるからと言って複数のワークパッケージを抱えるメンバがいるんですよ」
「それで」
「いつも終わらない」
「終わらないだろうね。普通なら」
「ですよね。でも、本人は複数のワークパッケージをやりたいと言うんですよ。ほんと面倒。終わらせると言ったら終わらせて欲しい。こっちの身にもなってくれって思う」
「荒れてるねぇ。誰かにクレームでも言われたのかい」
「プロジェクト報告でですね、ほら、全社の。アレで重箱の隅を突っつかれて。それもどうでもいいじゃんと思うんですよ」
「あそこはそれが仕事だと思っているからね。言わせておけばいいんだよ。言った後は共犯だからさ」
「それはそうするとして、その終わらないエンジニアなんですけどどうしたらいいでしょうか」
「どうしたいの」
「コミットしたら終わらせさせたい」
「やってみたら想定外のことが出てくることもあるじゃない。ワークパッケージがレディになってなかった、ってことで」
「それはそれで仕方がないんですけどね、そうすると他に抱えているのも道連れになるので困るんです」
「じゃあ、与えなければいいじゃない」
「すんなり受け入れてくれないんですよ、効率がいい方がいいって言い張って」
「で、どうしたいの」
「そうですね、予定したワークパッケージは特段イレギュラーなことがなければ見積もった予定完了日に終わって欲しい、かな」
「まあ、そうだよね。で、どうするの」
「それで困っているんじゃないですか」
「あのさ、作業を着手して何かに躓いるんでしょ。そのメンバは」
「そうです、割と躓きますね。ここでってところで」
「色々とありそうだけど、そのメンバさんはさ、予定どおりにいつも終わらないから終わらそうとしているんじゃないのかな」
「どう言うことですか」
リカバリをしようとしているんじゃないの。気持ちは」
「どう言うことですか」
「だからさ、いつも予定日に終わらないことが多いんでしょ。で、引け目を感じると言うか後ろめたいと言うか。だから次は頑張って取り戻そうとしている…かもしれない」
「あ、そう言うことですか」
「もしかしたら」
「そうだとしても、それはそれで困ったなぁ」
「あのさ、ワークパッケージの粒度が大きいんじゃないの」
「りゅうど」
「そう、ワークパッケージの大きさ。それの大きさを1つ小さくしてみたら。それでまずは完了することの経験を積ませる。スピードも出るよ。感覚論だけど」
「はあ」
「副次的に困っていることが早くわかる」
「ああ、ワークパッケージが小さいから」
「そうそう」
「なるほどですね」
「でも、それで複数のワークパッケージを抱えることに対しては」
「そのメンバだけ変えるんじゃないよ。チーム全員の仕事のワークパッケージを小さくすれば、そのメンバだけじゃないのでいいも悪いもなく全員同じルールになるでしょ。それで文句言うかなぁ」
「ルールを変えるんですね。なるほど。思いつきませんでした」
「腹立ててるからだよ。仕事なんだから終わらせることを考えないと。あれ、キミもそのメンバとある意味同じじゃないの」
「やめてください、効率なんて思っていないですから」
「それはウソだな。複数のワークパッケージを抱えることに効率的でないと思っていたからここに来たくせに」
「そんな意地悪言わないでくださいよ」
「終わらせてナンボだよ。お仕事なので」

 

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 
カンバン仕事術

カンバン仕事術

 
リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

 

 

 

小さなチームで大きな成果を得ることや大きな組織にスケールしながら変化し続けることはアジャイルだけではない

2012年以降、アジャイル開発がある一定のビジネスを牽引するようになったと思っているのだけれど、アジャイル開発での小さなチームで大きな成果を得ることや、大きな組織で変化し続けることはアジャイルだけの専売特許なのかしら。

従来の、傍流のシステム開発を担うビジネスではリソースが十分割り当てられることはないかった=小さなチームでしか対応することができないだろうし、小さくても組織であれば組織内の再編の波に揉まれながらも生き残るためには成果を何かしらの形で示していかなければ次の組織人事で消滅してしまうのだから。

大きな組織でも世の中の変化に対して受け身ではなく、やはり生き残るために次のビジネスやソリューションを開発する組織だってあるのではないかしら。

ただ、小さなチームで大きな成果を得られるように活動をしていても生き残れるかどうかは別の話だし、大きな組織で変化をし続けることで生き残れるわけじゃないし。それにそういった組織の中にいなければ、小さなチームや大きな変化する組織があることを知りようがないという事実もあるので。

まあ、そうだよね以上のことはないのだけれど。

アジャイルの専売特許とは誰も言っていない

アジャイルを謳っていなくても、必然とアジャイルなチームにしなければビジネスとして成り立たないことだってあるのです。

それはビジネスとして成り立つための様々なリソース、経営陣のポリシーや事業予算配分で示される事業戦略上の制約条件により、結果的に小さなチームでしかビジネスできないケースがそれにあたります。

何もSIerのビジネスが大規模開発や再構築のプロジェクトばかりではないのです。そう思っているなら、もう少し世の中のエンジニアと心のNDAを交わした後にお互いのビジネスについて情報交換を通して擬似体験した方が良いです。エンジニアに関わらず人は経験した範囲しか視界に入っても認知しないのですから。

小さなチームで大きな成果を得る

 前述の小さなチームでのビジネスは生き残ることが最大の目的になりがちですが、メンバのスキルと視野に入れるビジネスが組織に要求するスキルセットのギャップを検証していれば、マネージャは必然とメンバの育成を考えたアサイメントをすることを考えるはずです。

#マネージャ的には揃っていないところでビジネスをしなければならいのはツライ

少なくとも今は持っていないスキルセットの一部を何かしらにより充足しなければならないけれど、大概は、マネージャのリソースか外部リソースを買ってくる他ないので。それができるのは最初の頃までで、マネージャのリソースをあてにしてしまうとマネージャが本来やらなければならないマネージャ業務ができずこそがビジネス的に死角になるし、外部リソースに慣れてしまうとメンバが新しいことを学ぶ習慣を得る機会と不都合なことを外部に投げてしまう悪い習慣ができてしまうためです。

こうしたことも並行でこなしながらも、ビジネスを回すためには少数精鋭のチームを育て、チームのメンバにはフラットなロールとマルチなスキルセットを要求しながらビジネス的なリターンを得られる構造をマネージャは作らなければならないのです。

 で、これはアジャイルな性質を持ったチームではないでしょうか。何もスタートアップやプロダクト開発だけのものではないと思うのです。まあ、誰も限定はしていないと思いますけれど。

ただ、大きな、であるかどうかはビジネスの特性に依存するのでSIビジネスであれば、扱うソリューションの元締め的なポジションにならないと単価的に伸び代が制約を受けるのはわかった上でビジネス展開、つまりスケールアウトを考えなければならいです。

大きな組織で変化し続ける

このスケールアウトを考え始めるときに保守的=取り組んでいるビジネスを維持するために受け身になっては元来要求されているビジネスとして生き残るという危機感が薄れてしまうので危ない観点なのですけれど。

チームを複数同時並行で走らせようとするとチームの分割を考えなければならないし、他の組織からリソースを移すか、採用によりリソースの補充を考えなければならないです。その際に出てくるのが育成という投資ですが、そこで現状のビジネスを(うまく行っているとして)をオペレーションするコピー要員を作ってはいけないということを忘れてはいけないのです。

#基本的にスケールアウトを目指した瞬間から組織行動は稀薄化と劣化をするものだ、と認識した方が良いです。なぜなら、個体であるエンジニアが解釈してエンジニアの価値判断で行動するから。だから繰り返しインストールが必要なのです。

大きな組織を目指すとしても主導権を持って変化することを手放してはいけないのです。育成をするのであれば、小さなチームでビジネスを回すために組織の存在意義として持っているポリシーを充足する要員にインストールしなければならないし、合わなければ外に出す方が正しい判断だと思います。

こうした組織をスケールするにしても小さなチームがビジネスの基本要素であり、それを続けるのは組織として変化することがビジネスとして生き残るために必要な戦略だからです。それはSIerだとしても変わりません。

 複数のチームを同時並行で回すときの複数がどれだけコントロールできるかはマネージャのパーソナリティに全てが依存していきます。視界の広さ、届く視線の深さはマネージャの特性で違いがあります。複数になった途端、両方とも見切れなくなるマネージャは少なくないです。1つなら有能であったとしても複数では鈍感になるマネージャが少なくないです。これはチームのリーダも同じです。

 

結局、マネジメントがどう考えてビジネスをしたいかが組織人事として表現されるのであって、それに後から名前をつけても(つけるのは結構ですが)そうなんだ、ですけれど。名前より生き残る方が大事なので。

 

 

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦

 
「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

 
ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ハーパーコリンズ・ノンフィクション)

ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ハーパーコリンズ・ノンフィクション)

 
[新版]グロービスMBA経営戦略