Milkのメモ帳

日々の思いつきを忘れないようにのメモ用です。

Milkのメモ帳

仕事のスタイルが違うので、チームを変更されるかもしれない。


f:id:maxminkun:20171018210036p:plain

こんにちは。Milkです。
どうやら、私はチームを変更されるかもしれません。

ビックリされる方もいるかもしれませんが、そんなに深刻な話ではないのでご安心を。

しかし、原因は私と現在のPL(プロジェクトリーダー)との、仕事スタイルが異なるために起きたことなのです。

ここ数日。仕事でだいぶモヤモヤとしていましたし、フラストレーションが溜まっていました。


現在のプロジェクト

これを話すとだいぶ専門的な話になります(笑)

それに・・・長くなる。

少し、かいつまんでご説明しましょう。

最初から問題を抱えたシステム

現在稼働しているシステムはC言語で動作しています。

これは、プログラム言語としては古めの言語で、現在の”主流”とは異なります。

しかしながら、動作スピードの向上を目的として利用されることもあるので、さほど珍しいものではないのです。

さて、問題はC言語で書かれているということではなく、中のロジック(プログラムの構成)が無理を重ねたシステムであるという点です。

そもそもの話からいくと、このシステムは我々が構築していたものではなく、他社が作成したものでした。

しかし、お客様から「バグが収束しない」と言う話が持ち上がり、業界ノウハウを持つ弊社に対して「どうにかして動く状態にしてくれ!」と言う無理難題からスタートしたプロジェクト(PJ)だったのです。

当然ながら、最初は引き受けるのを拒否していました。

しかし、様々な要素が絡み、どうしてもそれを受注しなければならない状況に陥ったのです。

www.milkmemo.com

案の定、このPJは大炎上。

私は途中から「支援部隊」として招集され合流しますが、その状態は悲惨なものでした。

その記憶が私には脳にインプットされ、今でも記憶から消えません。

フルスクラッチで作り直す

さて、システムと言うのは実は老朽化していきます。

何故かと言うと、ICTは新しい技術がどんどん生まれてくるからです。

C言語が時代遅れだとは言いませんが、現在システムを構築する上で最初から候補に上がると言う言語ではありません。

現在稼働中のシステムは、今でもバグが多発し、メンテンナンスも大変。

ならば、「C#言語で一から作り直そう!」と言う話になったのです。

www.milkmemo.com

C言語は、C++言語に進化し、さらにMicrosoft社によって進化が遂げられた言語がC#言語になります。

まぁ、こういったプログラム言語の話は、話せば延々と続いてしまいますのでここまでにしましょう(笑)

大事なのは、「フルスクラッチ(新規での作成)」である点です。

私は、リスクとして幾つかの点を懸念していました。

  • 前回の炎上の時とプロパー(弊社社員)の構成が代わっていない
    (協力会社を含めても減っている。つまり、マンパワーが足りない時がいつか来る。)
  • 言語を変更するという難易度の高さ
  • 指揮系統の曖昧さ

これを踏まえて、私の中では確実に「再炎上する」と心のなかで確信していました。

幸いなことに、私の専門は「C#」なので、フルスクラッチの状態でもなんとか乗り切れるかもしれないという、本当に微々たる希望はありましたが、上手く乗り切れる保険にしては弱すぎる。何しろ私自身が病み上がりなのですから・・・

このPJを成功させるのに大事なのは、マネージメントを行う部分で、本来のこのシステムを扱っているプロパーのスキルが以前の炎上の時から上がっているのか?

ここにかかっています。

しかし、私はそこに懐疑的だったのです。

PJに参画スタート

f:id:maxminkun:20171018213709j:plain


既にPJとしては動き始めていました。

私は少し遅れて参加を始めたのです。

最初は状況が上手く掴めず、ただ時間を過ごすだけになってしまっていました。

設計書を読んでみたり、隙間時間に技術報告書を作成したり・・・

しかし、会議に参加する中で、何となくですが実態が見えてきたのです。

そして、私の中では「炎上するかもしれない。」が「確実に炎上する。」という確信に変わっていきました。

それは、私とプロジェクトリーダー(PL)との仕事のスタイルの違いが大きく関係してきます。

また、このPJの運営方法についても、私なりに分析をしましたが、結論は「このチームはこの案件を支えきれない。」と判断し、早めにリスク排除をしなければならないと結論付けました。

ですから、プロジェクトマネージャー(PM)と話し合いを持つことにしたのです。

体制は、「PM - PL - プロパメンバ(Grリーダ兼務) - 協力会社メンバ」と言う流れだと思って下さい。

実質PJを運営するのは、PLの仕事です。

PMは複数のPJをお金の面でマネージメントしますし、時にはPLの状況をフォローする立場になります。

私は、一担当員のプロパメンバとして入る予定でした。
(敢えて過去形にしているのは、後でご説明します。)

PJの進め方に異議を唱える

PMは50代半ば。PLはもうすぐ40代の方です。

私はと言うと、アラサーのぺいぺい平社員。
(実は、このPJ内では協力会社メンバを含めて最年少らしいです。)

しかし、過去に小さいながらもPLを経験させられるなど、メチャクチャなしごき方をされてきました(;・∀・)
(世の中ではそれはパワハラと言うのでは?(笑))

数週間過ごした中で、私の中ではある程度の分析の結果が出ていました。

ここで私が動き出せば半ば謀反(笑)

しかし我慢の限界に来ていたので、「チーム全体に問いたい!」と朝礼の時に私が発言したのです。

PM「先ず、私と話をしよう。それでいいかな?」

分かりました。後で相談させて下さい。

と言うことになりました。

PMと話したことは以下の点。

  • 全体の工程が見えない。今どの時点にいて何をしているのか教えて欲しい
  • 現在、一生懸命に既存システムのファイルI/O(ファイルへのアクセス)を洗い出す作業をしているが、それはなぜか?
    (データの保持の仕方やアクセスタイミングは、新システムの設計時に考えればいいことのはず。)
  • 大事なのは既存のプログラムと、既存の設計書の乖離をなくすことである。
    (なぜなら、引き継がれるのは「設計書」のみであるため。)
  • PLからの指示の「意図」が理解出来ない。
    (私への作業が細分化されすぎて、何を求めているのか分からない。)

PMの回答

f:id:maxminkun:20171018220749j:plain


まず、工程表について。

これは、実質「工程表はない」との回答。

工程表がないんですか?!

PM「大枠はある。しかし、細かいものはない。なぜなら、完全に受注になってないからなんだ。これは事情があってそうなっている。でも、それを待っているわけにもいかないから、我々としては先行着手して出来る範囲のことをし始めているんだ。」

しかし、朝礼では個別のタスクの進捗の報告だけで、全体の工程について話はないですよね?
私にはどのようにPJが進むのか理解が出来てないのですが・・・

PM「まぁ・・・確かにそうなるね・・・」

次に、なぜ既存のファイルI/Oの洗い出しやタスクフローの洗い出しを行っているのか。

次の案件はフルスクラッチのはずです。データを保存しているファイル群についてDB設計に入るのは分かりますが、これらにアクセスする既存のシステムのタイミングを事細かに資料をつくっても意味はないと考えます。
私たちに必要なのは設計書です。新規開発のときには、そもそも設計書を作成してから、データ設計に入るはずです。なぜ既存に引っ張られるようなことをするんです?
既存のプログラムを引き込むような行為を誘発するのは正しくないと私は思っています。そして、人的リソースが限られています。ここにパワーを割くのは意味があるのですか?

PM「意味はある。」

何故です?次のシステムは、フルスクラッチなんですよ?
データにアクセスするタイミングは自分たちで決めればいいじゃないですか。既存のシステムの方式を採用する意味が分かりません。他のシステムとのインターフェース(接続する部分)の仕様を合わせるのは分かりますよ? でも、我々の範疇は我々が設計をし、作りやすい方式でプログラムを書けばいい。
大事なことは「設計書」と「既存システム」の乖離がないことです。新システムに引き継ぐのは「設計書」だけです。それがお客様の要件だからです。そしてシステムの試験を行うのも「設計書」を網羅できているかしか確認のしようがないじゃないですか。
今の作業が既存の「設計書」の漏れを補完する作業なら意義を見いだせます。しかし、資料を膨大に作って、しかもファイルI/O部分なんて採用する必要性もないものを洗い出している。
私には理解しかねます。

PM「これは、今の協力会社メンバのトレーニング期間なんだ。今の処理の内容について理解をしている人間がいないと、PJが回らなくなる。それに、ちゃんと設計書にフィードバックする期間も設けている。だから無駄にはならない。」

私が言っているのはそういうことじゃないんです。新規案件には既存ソースなんてものは存在しないですよね?
そもそもの出発点が違うと言っているんです。これから増える新規メンバに対して基本になるのは「設計書」です。「既存システム」ではない。
仮に「既存システム」に触らせるようなことをすれば、そのプログラムを混入されるリスクは高まります。それだけはしてはいけない。
だからこそ今注力すべきは、「設計書」と「既存システム」の仕様の乖離をなくして、最新版の「設計書」に仕上げることなんです。「既存システム」の調査をさせるなら、「設計書へのフィードバック」にパワーを割くべきです。
今後に引き継げない資料を作成しても意味はありませんし、過去のシステムの動き方を参考にされたら同じものが出来てしまいますよ?

PM「言いたいことは分かった。でも、既存システムのソースを読める人間を確保しておくのも大事なんだ。そこは理解してくれ。後は結局二度手間になると言いたいんだよね? それは確かに指摘通りだと思う。ウェイトのかけ方を調整しないといけないかもな。」


そしてオフレコの話へ

PMと私は休憩を兼ねて喫煙所に行きました。

PM「率直に意見を述べてくれるのは嬉しいよ。こういうのは嫌いじゃないんだ。」

なんか色々言ってすみません。

PM「別にいいんだよ。」

これは言い難いんですが・・・
私は以前の炎上時に途中から参画していますよね?それを経験しているので、憂鬱なのです。
案件の難易度は前回より高いと予想しています。そうなれば出来るだけリスクを事前に排除しないと、同じことが起きます。
申し上げにくいですが、このまま突き進むと私は炎上すると確信しています。リスクが散在している。そして以前の状態からプロパのスキルがアップしているかと言うと、私にはそう見えません。同じマネージメントをしようとしている。それが最大のリスクです。

PM「それはPLのことかい?」

ハッキリ言えばそうです。恐らく(PM)さんは、PLに経験を積ませたいんですよね?

PM「そうだね。」

今のやり方を続けると、体制を維持できなくなりますよ?

PM「彼も試行錯誤してるんだよ。」

それは分かります。
しかしながら、全体での情報共有や、個々への指示の出し方に問題があります。

PM「と言うと?」

指示の目的が説明されないことです。
何のために必要な作業なのかが説明されなければ、私としても何を求められているのか分かりかねます。
事細かに”作業内容”を指示はしますが、私のアウトプットが何に使われるのか、或いは何のための作業なのかが説明されません。
そのために、彼の中では何かの構想があるのかもしれませんが、アウトプット結果がイメージと違うと何度も作業が往復することになります。

PM「明確なビジョンはないんだよ。どうしても試行錯誤になる。」

ならば尚更です。悩んでいるならそのまま言ってもらった方がサポートし易いんです。
ふんわりとでも、「こういう方向に進みたい。その為にはこういうアプローチを考えているけれどどうかな?」と言われれば、私としても作業の流れや方向性が見いだせるので、担当者ベースで調整が図れます。しかし、彼の中で全てか完結してしまっているなら、私は何を求められていて、結局何のポジションに居るのか分からないんです。
このままでは各担当者は、お互いに情報を共有できないままPJが進みます。最終的に炎上しますよ?

PM「うん・・・彼は口下手だからな・・・分かった。Milkの言い分は分かった。彼にも話をしておくよ。」

課長と話をすることに

課長「よう。どうだい?調子は?」

正直に言うとよくありません・・・

課長「それは作業場の環境が悪いの?」

いえ・・・危機感がないことに不安や苛立ちを感じるんです。私は前回の炎上時の支援組でしたから・・・

課長「ああ・・・確かにそうだったね・・・そんなに酷かったの?」

私に直接話しをせずに、メール1本で協力会社メンバのタスク管理を任せたことがあったんですよ?オリジナルのプロパメンバはお客様打ち合わせで出払うからって。私はメールが見れない状況だったのに・・・
それ以来、申し訳ないですけど、あのチームのマネージメントスキルには懐疑的です。

課長「そんなことがあったのか・・・」

チーム移動の話が現実味を帯びる

あのチームを上手く軌道に乗せるには、PLから情報を引き出し、各担当者と調整を図る人間が必要です。
PLの中でクローズされていてはPJが回りません。その役割を担う人がいないといけない。
しかし、それを私がやってしまうと「出来るのならやってくれ!」と成りかねません。
心は踏ん張って調整役をやろうと思っていても、身体が今はついてこないんです。今はPLとのコミュニケーションのとり方や、自分の仕事をどのように調整するのかでかなり葛藤しています。

課長「それは非常に不味いな・・・」

結局、PMに話した内容を課長にも説明することになりました。

その結果、課長はPMと話し合いをしてみるとのこと。

私がマネージメント側に寄る形で仕事をしてくれれば大変助かるが、今それをすれば私が倒れかねない。

それは、双方にとって苦しい状況になると・・・

そういう経緯もあり、私はチームを移動する可能性が現実味を帯びてきました。

結局リーダーはどうあるべきか?

f:id:maxminkun:20171018232820j:plain


私は少なくともPJを運営するリーダーは、その方向性を示すことが第一に大切なことであると考えています。

それは必ずしも「正確で絶対に正しい」というものである必要性はない。

大事なのは、以下の点だと理解しています。

  • PJ全体が情報を共有できる環境をつくること
  • 事細かな指示ではなく、目的を説明し方式については担当者に任せること
  • 自分が作業を持たないこと
    (リソースの問題で自分が作業を受け持つ必要があるかもしれませんが、半分までに留めるべきです。)
  • 担当者間の調整に注力すること

弱さを見せることはリーダーとして失格を意味しません。

私はそう理解しています。

リーダーは方向性を示すこと。それが仕事です。

「こういう方向に進めたい。」

それさえメンバは分かれば、具体的な方法については担当者が考えるのです。

そうでなければ、全ての作業にタッチしなければならなくなります。

これは、小規模なPJならまだなんとかなりますが、大所帯になれば通用しなくなります。

と言う訳で、私の「リーダー論」と、今のPLの「リーダー論」が合致しなくなったのです。

最後に

さて、私はどうなるんでしょうかね?

窓際で厄介払い扱いになってるかもしれません・・・(笑)

いや・・・笑ってる場合じゃねぇ!

まぁ、どうにかなるのかもねー。

(゚∀゚)

そう信じるしかないね。