システム開発って、工事を進めてるのに、近いイメージがある
そういうつぶやきを、システム開発の現場にいるメンバーから
聞く事が、あります
コンピュータの仕事、というと、ちょっと知的で、きれいな仕事を
連想する人もいるかもしれないですが、結構力仕事といっていい
部分があります
たとえば、トンネルを掘る工事をしていて、こういう計画で
こう掘り進める、と、あるのですが、いざ掘ってみると
硬い岩盤にあたって、計画どおりいかないなんてあるわけですよね
あるシステムを、作っていて、使った製品の制約が後から
わかり、その調査であり、回避のしかたを模索するのに
時間が使われるなんてことは、しょっちゅうあります
システム開発のプロジェクトにおいて
いまの現場がどういう状態なのか、知る、ひとつのキーワードは
「スケジュール」がどうなのか？
ということです
そういう意味で、そのプロジェクトを運営する、プロジェクトマネージャが
どのくらいの、経験と力量、人脈、等々、もっているかというのは
とても大きなポイントになります
そのシステム開発における、リスクをどこまで想定しておけるのか
というのが、客の信頼を維持し、メンバーとの関係を良好な
まま仕事すすめる、鍵となるからです
数年前の、当社システマーズで発行してる、メルマガに
担当者が、横並びのメンバーの、遅れについて、気づいたとき
どういう振る舞いがいいのか？という話題で、記事を書いたことが
ありました
私が、だした、道筋は、オープンな場で、その遅れについて
情報共有するでした
もちろん、その状況次第で、それはNGということも想定は
できます
ただ、ある麺少なくとも、メンバーの成長という点で
理想的な状況があるのなら、オープンな場で、情報共有と
考えます
この話をしたときに、真っ向から、それはちがうと
指摘した、そのとき結構仲良くしていた、他社の人がいるんですね
つまり、オープンにするまえに、リーダがどういう判断をするか
リーダに情報を預けるのが先だと、主張されたのです
確かに。実際そういうほうが、いろんな手をうちやすい
そういうことも、経験上言いたくなることは、認めます
言い換えれば、私が↑でいってることは、オープンにできる
チームであることを、維持するのが大事といっていいかも
しれません
昨日、ごく親しくしてる人と、「チームとは」という
やっぱり、理想ということを、念頭においた、会話をしました
理想のチームでは、言いたいことを、がまんせず言えるというのが
あると、私は言いたいのですね
異論はあるでしょう
だけど、私はこだわりたいです
いいチームであれば、たとえば、立場の違い、上下関係
そういうことを、超えて、ものが言える、いいやすい
そこを、めざすべきだと。
