∑考=人

そして今日も考える。

システム開発におけるリーダーの難しさを体感した

私はリーダーという役割が嫌いだ。もちろん、自分から進んでやることはまずないし、人を動かして全員で大きい何かを成し遂げる、みたいなことにもあまり興味が無い。自分がプレーヤーとして主体的に動ける方が好きだ。

 

例えば、バスケットをしていた頃も、チームとして勝利することよりも個人の成績の方が自分の満足感には繋がる。ずっとそんな価値観で行動してきた。一般的に、チーム一丸となって成果を出すことはすごく美徳のように語られるけれど、私は10人で100を成し遂げるよりも1人で15を成し遂げた方が普通に嬉しいと感じる。悲しい人間なのかもしれないが、少なくとも今の私はそういった狭い視野でしか物事を捉えることができない。

 

そんな私でもしばしばリーダーという役割を任されることがある。なぜかこの国においてはプレーヤーとして優れている人にマネージャーやリーダーといった役割を任せたがるのだ。それはアルバイトとて同じである。そういうわけでリーダーのような立場を全くもって経験していないわけではない。

 

とは言え、プレーヤーとしての能力とリーダーやマネージャーに求められる能力は全く別のものである。私はプレーヤーとして評価されたことはあっても、リーダーとして何かを成し遂げた記憶はない。そもそも私の考え方として、個人の意向を尊重したいので、全員を1つの方向性に向かわせたいとはあんまり思わない。その上、マネジメントスキルも乏しいため、やろうと思っても上手くいかない。

 

昨日で5日間の総合演習が終わった。今までの研修と本質的に異なっていたのは、個人ではなくチームで1つの成果物を作成する、という点だ。具体的には、要件定義に始まりシステム設計、製造、テストまで全て同じチームでこなし、顧客企業に対して構築したWebシステムの提案まで行う、という実践的な課題だった。

 

冒頭でリーダーの話をしたのは他でもない、私が総合演習のリーダーを務めることになったからである。結論から言っておくと、満たすべき最低限の基準にプラスアルファを付け加えることはできた。でも他のグループと客観的に比較したとき、システムについても提案についても明らかに劣っていたと言わざるを得ないと思う。

 

言い訳ならいくらでも頭の中に思いつく。チームメンバーのせいにすればいいのだ。しかし、他責から生まれるのは一瞬の自己肯定感のみである。というわけで、ストイックに自分の何がいけなかったのか、を考えてみた。大きくは以下の3点に尽きる。どれもリーダーには必須の行動であろう。自分の未熟さを改めて思い知った。

自分のこだわりがなかった(自分なりのゴールが設定できていなかった) 

まず、チームとして何かをする場合、リーダーとしてどうしたいのか、という意志が必要である。それを持たないまま議論を進めてしまうと、各メンバーのまとまりのない意見をどれも実現しようするハメになり、チームの中にプライオリティがいくつも存在するような現象を引き起こす。

 

例えば、ある1人はシステムの機能面を充実させることが最も大切だと考えているが、別の1人はデザインこそが最も大切だと考えており、時間が追い込まれた時に、何をするべきかがチームとして明確にならないため、プロジェクトが難航してしまう。なので、全員の意向は尊重した上で、チームとしての目標はリーダー自身が決めなければならないのだ。

できないことにNoと言えなかった(厳しい意思決定を下せなかった)

上記の話にも関連するが、できないことに対してNoと言わなければならないときがある。作業を進めていく中で少し時間に余裕が生まれると、次はこんな機能を追加しようとか、今のシステムの仕様をこうした方がいいのではないか、といった色んなプラスの提案が生まれてくる。

 

もちろん、作業を進めていく仮定でしか見えてこない問題点はあるし、それを改善したいと思うのはとても良いことである。しかし、2時間の時間的余裕が生まれたから3つ機能を追加したいと言われても、それを2時間でもし完成させることができなければ、結局別の時間が減っていくことになるのだ。

 

実際システムの機能を作る場合、作った後にちゃんと動くかどうかテストもしなければならない。そして正常に動作しなかったとき、プログラムのどこにエラーが存在するのか、なぜそのエラーが発生するのかを見つけるのは想像以上に時間が掛かるものだ。

 

今回も自称プログラミングが得意だと言っているメンバーにとある機能を15分で作るように(本人のできるという主張を信じて)任せたが、実際には1時間ぐらいかかって色んな作業に支障が出た場面があった。

 

そのメンバーの能力不足が問題なのではなく、私自身がチームメンバーの力量を正確に把握する必要があり、その基準を満たしていないと判断したのであれば、その提案にはNoと言い張らなければならなかったのだ。タイムリミットが近くなる前から、時間を強く意識して、できるかできないかの基準を持っておく必要があると思った。

士気を落とさず本人の意向に沿わない作業を割りふれなかった

リーダーの仕事において、これが最も難しいことだと思う。人間やりたいことをやっているときは、自然と作業効率は上がるものだ。しかし、やりたくないことをするときはどうしてもモチベーションが下がってしまう。

 

しかしながら、仕事の中でどの作業も楽しいと考えられる人はそうそういない。やりたくない(けどやるべき)ことに対していかにモチベーションを持って取り組むのかというのは、私自身にとっても課題であるが、それを人にさせるとなるともっと難しい。

 

今回も、プログラミングが好きな人は次々と新しい機能を追加しようとし、デザインにこだわりたい女性たちは、ついつい時間を忘れてデザインに没頭してしまっていた。「木を見て森を見ず」状態に陥ってたメンバーに、まず細部よりも全体を作ることを優先させたかったのだが、それを強要すると案の定士気は低下してしまった(というか作業が遅延した)。

 

私自身が、リーダーという仕事が好きではないため、自分をモチベートするのに必死であった。そんな中でチームの方向性を随時正して、かつ士気を下げないのは困難であり、今後一番の課題になりそうである。

 

と他にも挙げればキリがないのだが、研修の終盤でようやく多くの反省点が見えてきたのは本当に良かったと思う。反省点を次に活かす。今の私にできるのはそれだけだ。