プロジェクトマネジメント初めて経験する場合の注意点

この記事は約14分で読めます。

少し前まで業務用のアプリケーションを7人のチームで作成していた。

中身は社内での業務の効率化に関わる事務処理に関するアプリケーション。

会社のサービスに関わるようなものではないので、失敗しても会社に影響はないようなものだったのだが、

運よく自分がプロジェクトマネジメント的な立場で仕事をさせてもらえることになったので、

終わってみての反省点などを考える。

アプリケーション自体はリリースすることができたが、それまでの過程はうまくいかないことばかりだったので、

主にうまくいかなかった部分をまとめておき、この記事を読んでいるあなたにとっての反面教師として頂きたい。

進め方

何から何までわからないことだらけ

プロジェクトマネジメントをやったことがないどころか、

アプリケーションの開発すらやったことがないという素人以前の状態からスタートした。

そのため、そもそもどのように進めていけば良いのかすらわからなかった。

毎週報告のタイミングがあるため、一応資料を作って報告はしてみるのだが、

完成に向けて進んでいる気が最初のうちは全くしない。

「お題は出すからあとは全て自分たちで調べて進めろ」という指示があり、

自分で進め方を調べるところから始めることで経験を積ませることと、

わからないことに対する対処の方法、

社内での仕事の進め方などを学ばせようという意図があることはわかっていたのだが、

実際に数々の問題に直面した際には立ち往生ばかりすることになった。

一応の完成を迎えた今にしてみれば、

ソフトウェアの開発には複数のモデルがあり、

要件定義、設計、コーディング、テストといったさらに具体的な開発工程が存在することなどがわかっている。

とはいえ、今でもそれぞれで具体的にどのようなことをすべきで何が必要なのかといったことは曖昧なままになっている。

だから、応用情報技術者試験を申し込み、今月受験する。(勉強はできていない。)

必要な機能は何か洗い出すことやプロジェクトの終わりまでに何をするべきなのか?

まともに勉強しないままに進んでいったので、

正直、せめて1人くらいは開発経験のある社員を置いて、

間違えていたり詰まっていたりする場合は方向を修正するためのガイドが欲しかった。

「あとは全部自分で調べてやれ。」と言う指示は、うまくいけば力はつくかもしれないが流石に無茶な指示だと感じた。

用法は違うけども、「先達はあらまほしきことなり」という言葉が思い返された日々だった。

ともかく、当初、上席者が意図していたわからないことに対するアプローチの方法や、

業務プロセスについて、少しくらいは身につけることはできたのではないかと思う。

具体的にはとにかく検索しまくり、本を読みまくること。

社内の規定やルールに関する部分は文書を読みあさって知っている人物に聞くこと。

正直、これしかないと思っている。

スケジューリング

色々と問題を抱えながらの進捗だった。

その一番大きな原因はスケジューリングがあまりに拙かったということ。

未経験でど素人ではありながらも、私がPMの立場にあるということは進捗管理は私の仕事だった。

しかし、毎回の報告の際にも記載すべき情報を載せていないこともあり、

予定通り進んでいるのか遅れているのかが相手に伝わらないまま、時間だけが過ぎていった。

実際には遅れに遅れており、アプリの機能的な面も含めて詰めるべき部分を詰められないまま終えることになった。

期限日の前日に至っても機能的な部分の話をしていることなど普通はあるのだろうか?

おそらくないだろうと思う。

一つ一つのタスクごとに開始日予定日、終了予定日、開始日、終了日、進捗状況を厳密に記載していかなければ、

進捗がどうなっているかはメンバーにしかわからない。

第三者が見ても進捗状況がわからず、助け舟の出しようもない。

そのことを期限日の数日前に指摘された。

とても勉強になったのでWBSなどを引いたのだが、もはや手遅れの状態だった。

仕方がないので最低限の機能だけを載せてカットオーバすることで間に合わせることとなった。

休みの期間に注意

社会的な目が厳しくなっているので、サービス残業や休みを取らずに働き続けることはできない。

自分自身は、一応は20代だが若いうちはそれなりに身を粉にして働く必要があると思っている。

無駄に残業時間を引き延ばして残業代をもらうと言うことではなく、

定時までに仕事を終わらせられる実力をつけた上で、

それでもさらに知識と経験を得るためにハードワークをすると言う意味で。

実際やってみると辛いとは思うが。

そう言うわけで、メンバーがいつ休みを取るかと言うことにも注意しなければならない。

特に夏休みなどで長期的に休暇を取った場合、休んでいる間の業務を誰かがカバーしなければならない。

私自身はハードワークはアリだと思うが、他人に「休みを取るな」なんてことを言うのはあり得ない。

そんな考えや発言は今の社会には合わない。

と言うか私だって休みたいときに休めないのは嫌なこと極まりない。

だから、メンバーが休んだとしても仕事が進むように準備することも、PMである私の役目だった。

しかし、実際にはそれでアプリケーションの開発が滞ってしまった。

ろくに対応策をたてることをしなかった。

まともにコーディングできる人物がいないと言う問題もあったのだが、

次の機会があればこう言うことを繰り返さないようにしたい。

コミュニケーション

途中からチームに入ったメンバーのケア

初めから7人で進めていたわけではなく、3人からのスタートだった。

理由はわからないが、途中から4人が加わり、最終的には7人で開発を進めることとなった。

途中から入ったメンバーにとっては、疑問点だらけのようだった。

私自身もはっきりと感じていたが、

正直、開発しようとしていたアプリケーションはjavaで作ろうとしていたのだが、

実のところ、エクセルで完結できることだった。

エクセルの方が簡単な上に早いし、期間も費用もかからない。

そんなことはわかっていたが、上席者からの指示だからと言うことでとりあえずは納得して動いていたのだが、

途中から加入したメンバーにとってはそのいきさつを知らない。

上司からの指示だからと脳死して割り切って動くことは簡単だが、

本質的な部分に焦点を当てて考えるメンバーほど、なぜこのような仕様になっているのか?

このような手段を取っているのか?理解することに時間がかかったし、

最後まで納得はできないようだった。

いずれにしても、プロジェクトに途中から入ったメンバーの疑問点や感じていることは何か?

しっかりとヒアリングして解消しなければ、その後の進捗に悪影響しかもたらさない。

納得感のないままに作業をしても作業効率は上がらないし、

会議でも同じような話題を何度も繰り返すことになる。

会議は事前に論点をまとめておく

3人寄れば文殊の知恵とは言うものの、3人以上で集まって話し合うとそれぞれが好き勝手なことを言い出すようになる。

誰もが言いたいことを腹のなかに抱えているし、2人か3人だけで議論が盛り上がることもある。

何も準備せずに会議に臨むと何も進まない。

会議で決めるべきことや話し合うことには優先順位がある。

しかし、そのことを事前にメンバー全員にきちんと伝えることをしなければ、

時間だけを使って何も決まらないと言うことが度々起きてしまうことがわかった。

会議をする目的と、会議で話し合うべきことくらいはまとめておき、

メールで送るか、会議の最初の段階で伝える必要がある。

途中からはそのことを意識して行なっていたのだが、

それでも途中から話が逸れていってしまうことがあった。

理由はメンバーによって、大変だと感じることや重要だと感じることが違っているからだと思う。

メンバーのなかに2人だけプログラミング経験のある社員がいたのだが、

彼らにとってはアプリケーションの開発は調べればわかることであり、

それなりに時間をかければ解決できる問題の集まりだと言う認識のようだった。

逆に、機能的な部分の要不要は厳密に突き詰めて話したいと言う思いがあり、

本当に会社にとって役に立つものを作るためなら、

全体的なスケジュールは遅れても仕方がないと考えているフシがあった。

私はと言うと、全体的なスケジュールは交渉して遅らせることはできるとは思っていたが、

基本的にはスケジュールは絶対に守るべきものだと認識していた。

逆にアプリケーションの開発経験がないから、

解き方のわからない問題が山のように積み上がっているように感じていたし、

それらを解決するにはどれくらいの時間が必要なのか?

そもそも誰が解決できるのか?全く見通しが立たなかった。

おまけに知識もないものだから、理解ができないままに同じような質問を何度もしていた。

経験のある彼らにしてみれば私はアホに見えただろうことは間違いない。

結局、議論はするものの、何も進まないと言う会議が繰り返されることになった。

間違いを指摘してほしいが発言がない。もしくはスルーしている

私は性格的に表立って意見を主張するような人間ではない。

内向的な性格なのでPM自体もやりたくはなかったのだが、

やっているからには進めなければならない。

とはいえ、全く経験のない自分が何かを意見しても的外れにしかならないだろうと思っていた。

だから、間違えていることがあればどんどん指摘してほしいと思っていたし、

そう言っていたつもりだったのだが、意外とそうはならなかった。

しかし、実際にはかなり指摘をもらっていたが気づけなかったと言うのが正しいと思う。

すでに書いたように、指摘されたことはそれほど大事ではないと、自分と相手の重要度の認識の違いからスルーしてしまったり、

指摘されたのに、何が問題なのか私が理解できていないからスルーしていたように思う。

スケジューリングやアプリケーションの機能的な話に一番ツッコミと反対意見をくれていたメンバーが、

途中からは何も言わなくなったところを見ると、

おそらく何を言っても無駄だと判断されたのではないかと思う。

その答え合わせを飲みに言ったときにでもさせてもらえると良いのだが。。。

どちらにしても、知識や経験がないと何が問題であるかさえも知ることができない。

PMは細かいタスクをすることはあまりないが、

それぞれの進捗がどうなっているのか、

どこが問題になっているのかを正確に把握するためにも一番に知識と経験が必要になる。

ナメられたら指示を無視される

今後の仕事にも影響してくるのでどうしようかと思い困っているのだが、

仕事ができないヤツはナメられる。

社内での自分に向けられる期待値は低い方が楽で良いと思っていたりするのだが、

小さいチームではあっても、トップがアホでメンバーにナメられてしまうのは頂けない。

多くのメンバーは大人の対応で協力してくれていたのだが、

1人だけタスクの割り振りや指示をしても拒否したり、

引き受けた上で無視すると言うことがあった。

人に嫌われるのは仕方ないとしても、普通に傷つくし、それで仕事が進まないのには困ってしまった。

そして、どうしたら良いのかわからなかった。

タスクを振っても進める意志がないのであれば割り振る意味はなく、放置するしかなかった。

腹は立ったが、それで感情的になって怒ったとしても何かが解決するわけでもない。

嫌われるようなことを何かしてしまったのだろうと思う。

その理由はわからない。

単純に仕事ができないからと言うのであれば、それは改善していくしかない。

気に障るようなことを言ってしまったのなら謝るしかない。

性格が合わないと言うのであれば諦めるしかない。

全員が仲良しこよしで仕事することはできないだろうし、そうする必要もないとも思うが、

何が気に食わなかったのか、今度教えてもらえるといいなと思う。

彼の場合は飲むのは好きじゃないかもしれないし、誘っても断られるかもしれないが、

普通に昼飯だったり、空き時間や帰宅途中でも良いから聞いてみたい。

根本的には私の仕事がマズイことが原因にあるのは間違いないので、

勉強して仕事ができるようにならなければならないと言うことに変わりはない。

アプリケーション

要件を明確にする

タスクやスケジュール管理でも同様のことが当てはまるのだが、

何が必要なのか?きちんと洗い出すことができていなかった。

さらに問題だったのは、何が足りていないのかがわからなかったと言うこと。

発生した問題や選択肢を自分たちで判断することができないので、

定例報告の際に伝えた上でどうすれば良いのか相談したらよかったのだが、

そう言った発想にすらならず、自分たちで抱え込んでいる期間があまりに長すぎた。

それで解決を保留にしたままにしたせいで、プロジェクトがギリギリまで遅れててんやわんやになってしまった。

担当者を明確に

誰が何を担当するのか?

私は気が弱いので仕事を振るのは気が引けていたのだが、

そうやってまごまごしているせいで、誰も担当していないタスクが放置され、

遅れてしまい、結局メンバーに迷惑をかける結果につながった。

怒られたり嫌われたくないと言う気持ちが自分のなかにあるからだと言うことに気づいたのだが、

性格の問題なので、治すのは難しいように思う。

それでも、やるべきことを放置するのは仕事を放棄することと同じになる。

苦手なことでも克服していかないとなぁなんてことを感じた。

報告

報告の目的を明らかにして時間をとる

最後の最後の方で、目的のわからない報告の時間を取ってしまったことがあった。

元々は必要のない時間だったのだが、報告対象の上司があまりに忙しすぎて空き時間がなかったため、先にアポイントを抑えてしまったことが原因にある。

本当に参加すべき会議は別にあり、その会議で周知も兼ねて報告すべきだったのだが、

できるかどうかわからないタスクを残した状態であり、

その会議に参加できるかどうかもわからなかったのだが、

結局は会議に参加することができた。そして、必要な報告は全てそこで済ませてしまったため、

枠だけ抑えておいた報告の時間だけが残ったと言う結果だった。

そういった経緯を説明することもできなかったために、メンバーにとっては意味のないことをしていると感じさせる結果になった。

報告の様子をメンバーは見ている

正直に言うと、怒られることが人と比べて異常に嫌だと思っている。

だから、上司の前になると上がってしまうし、口調もたどたどしくなる。

しかし、その様子をメンバーは見ている。

だから仕事ができないし頼りないやつと思われることは必至だった。

一応は営業をしていた身だったのだが、どうしても上がってしまうのだけは治すことができていない。

それでもやらなければならないことだからやることはできるのだが、

メンバーにとっては嫌なリーダーだったと思う。

できるかどうかわからない時

報告について、もう一つ問題を挙げるとするなら、できるかどうかわからないタスクがある時のことになる。

私には、報告は「全て問題なく完了した」と言う内容でなければならないと言う思い込みがあった。

しかし、実際にはできないことはできないと言う報告をするべきだった。

そのように報告することで別の方法を提示されるかもしれないからだ。

何かしらの問題があることがわかれば一緒になって考えてもらうことはできる。

しかし、問題があることを伝えなければ、それができない。

なあなあのままで進んでいくと、期限日直前になって「できません」と言うしかない。

「どうしてもっと早く言わないんだ」と言う展開に至る典型的なパターンなのだが、

しっかりとそのパターンを踏襲してしまった。

他の業務との兼ね合い

他にも複数の業務を抱えていたため、それぞれのタスクとの兼ね合いも考えなければならない。

一つの仕事だけに集中したいが、社員数は無限ではないからそう言うわけにもいかない。

ここでも、タスクの重要度と緊急度に分けて進めていくしかないのだが、

自分が受け持っていた業務のどれもが、期限ギリギリで慌てて進めることで凌ぎ切ったという印象だった。

やることが山積みになってしまったのはもう仕方がないので、

ともかくタスク整理とスケジューリングをしなければ始まらない。

まとめ

結局、開発に要した期間は3ヶ月ほどだった。一応は予定通りに終えることはできたのだが、

やっている最中は毎回の報告の時間が苦痛だったし、

期限が迫ってくるほどにストレスも増していった。

チームのメンバーともコミュニケーションがうまく取れていなかったので地獄のような期間だった。

それでも最低限の機能を載せることはできたしリリースには漕ぎ着けることができた。

スケジュール感はタイトなものだったし、自分の段取りがあまりにヘタクソだったので、メンバーにとってはクソなPMだっただろうと思う。

今度飲みに誘って反省点などを聞かせてほしい。

それから、今回は私はコーディングに参加することができなかったため、自分自身でアプリケーションを作ることができていない。

自宅で一人で作ってみるのも良いのだが、何人かのチームで一緒に進める中でのコーディングも経験してみたい。

そうしないとわからないことがあると思うから。

自分自身は社内でもまだまだ若手で、PMを任されるような立場にはない。

どちらかというと雑用的な仕事が多いのだが、改めてソフトウェア開発でPMに挑戦できる機会があれば、今回よりはうまく進められるようにしたい。

コメント