プロジェクトは破綻する。

仕事のこととか、salesforceのこととか、書評とか書いてます

転職をきっかけにエンジニア半生を振り返ってみる(3)





 

 

f:id:momokuri777:20170128073121j:plain

かなり前にエンジニア半生を振り返ったが、そのとき在職中の会社のことを書くのは控えていた。

時間が経ち、その会社で結果的にどういうことになったのかまとまったので、今日は語ってみる。

 

 

事業会社の立ち回りになかなか慣れなかった3社目(2012~2017)

SIer時代に知り合ったユーザ企業の会社に、開発部のマネージャとして転職したあっし。

下請けの会社から事業会社に変わったため、これまでと真逆の立ち回りを求められることとなり、最初の1~2年は本当に苦労した。

 

大きく変わったのは、対象となるビジネスの相手。

サイトを運営していたので、いかにpvを稼いでサイトの価値を高めるかが重要。

そのため、意識する相手が顔の見える顧客から、見えにくいネットユーザに変わったのだ。

 

そのためには、とにかくサイトにたまるデータを分析し、ひたすら改善をしていくことが必要になる。

前職であれば、顧客がやりたいことに疑問を感じても、顧客が求めているものを作れば、それが正解と割り切れたし、売上とすることができた。

しかし今度の仕事には正解がない。

誰も正解がわからないまま、あーでもないこーでもないと言いながら、前に進んでいくしかない。

 

この事業会社特有の進め方に、あっしはすぐには慣れなかった。

自分の成果がわかりにくかったから、自分が貢献できているか実感がなく、ものすごくやりにくさを感じていた。

 

正解かどうかわからない中、会社はさまざまな企画を案件化していく。

あっしは不安な中、案件の開発担当となり、プロジェクトをいくつか仕切ってきた。

 

その最初の仕事で、あっしは躓くことになる。

あっしのマネジメントが、まったく通用しなかったのだ。

 

今振り返ると、当時のあっしのマネジメントは納期を重視しすぎる傾向にあった。

下請け時代は、納期と言えば絶対はずせないもの、という意識が強かった。

それをそのまま引きずった形だ。

 

社内の企画担当の者からはきつめのスケジュールを告げられたが、入社して最初の仕事ということであっしは絶対成功させてやろうと意気込んだ。

あっしはリリース日を死守するべく、開発担当の下請け業者を厳しく指示をしていた。

しかし、あっしやり方に不満を持ったメンバが指示に従わなくなり、ついにはマネージャをはずされる寸前までいってしまった。

 

あっしは素直に頭を下げた。

もう一度チャンスをください、と。

結果、プロジェクトは体制変わらず継続され、リリース日までに一通りの作業を終えることができた。

 

しかし、あっしのプライドはズタズタになった。

あっしがこれまで積み上げてきたものを全否定された思いだった。

特に、プロジェクトを破綻させまいと長年研究してきた自分なりの「失敗しないメソッド」が、むしろ破綻へ導いてしまったことがショックだった。

 

この会社でどん底だったのは、入社半年後のこのときだ。

そこからあっしは事業会社の立ち回りというのをイチから学んでいくことになる。

ここでの学びは、いまのあっしの基本スタイルとなっている部分が多い。

 

このときどんなことを学び、自分の糧としているか。

5つ紹介しよう。

 

絶対に成功させないといけないプロジェクトなんてない

あっしが先に述べたプロジェクトでメンバに反発され、躓いて落ち込んでいるときに、会社に誘ってくれた開発部の責任者である友人がこんな言葉をかけてくれた。

 

「まわりの言うことなんていちいち気にしなくていいですよ。だって、いま作っているサイトなんて会社でも初めて試みだし、誰も正解なんてわからない。みんな言いたいこといいますけど、みんなを手の平で転がすくらいの感覚で対応すればいいです。それで本当に無理だと判断したら中止しちゃいますから。」

 

あっしにとっては、考えてもない言葉だった。

中止にするなんて、できるのか?

しかし、中止がアリという選択肢があっしの頭にインプットされた途端、抱え込んでた思いが一気に開放された気がした。

 

下請け時代は、仕事を途中で投げ出すなんてありえなかった。

しかし、今やっていることは会社の1つの企画にすぎない。

下請け業者を雇い、それなりにお金をかけている状況で、中止となるとそれなりの損失になることはわかりきっている中で、それでも中止はアリなんだ、という驚き。

そして、そこまで言ってくれる友人に器の大きさを感じた。

 

今を思えば、計画通りにできないプロジェクトだったら、これ以上無駄なことをしないために中止する、という判断もあり得る。

それはプロジェクトの進行の問題ではなく、そもそも計画が無理だったという可能性もある。

よくよく考えれば、あっしのプロジェクトはリリース日ありきで進められていた。

典型的な破綻プロジェクトだった。

 

プロジェクトは、成功するかどうかもわからない企画にすぎない。

これ以上無駄と思えば、ときには中止と言う判断も下す。

それもアリなんだと、あっしに強烈にインプットされた出来事だった。

 

企画の人間に必要以上にびびらなくていい

企画と言うのは、当たるかどうかはわからない。

しかし、企画を考える人間は、絶対成功する!いける!と言うスタンスでまわりを巻き込み、ときには強引に物事を進める。

あっしもその勢いに圧倒され、言われたとおりにやらなければならないと思い込み、プロジェクトメンバに無理をさせてしまった。

 

あっしは正直、企画の人間が好きではない。

思い付きでしゃべり、今日はこれがいける!と熱心に語っていたのに、次の日になると他のものに心移りしている。

なんだか軽いし、節操がないところが嫌いだ。

 

また企画職と言うのは、ちょっとできる人がやっているイメージがある。

ビジネスを考える仕事なので、ビジネスのことをいろいろ知っているし、そんな話をしているところを見ると、ちょっとかっこいいし、華があるように思える。

そんな人に、こっちにはわからないビジネス背景を語られ、最後に「だから必要なんだよ」と自信ありげに言われたら、ちょっと圧倒されてしまう。

 

とにかく、一緒に仕事をするにはちょっとやりにくい人種だな、と思っている。

 

ただ、企画を考える人は前向きで居続けなければやってられないところがあるのかな、と思う。

考えた自分だって、それが成功するか本当のところは確信がないかもしれない。

それを会社で予算をつけて本格的にやろうってなると、途端にプレッシャーになる。

それはそれできついだろうな、と。

 

今となってみれば、そんな不安な気持ちをいっしょに共有するスタンスでよかったのかな、と思う。

どっちが偉いとか関係なく、同じ会社の人間なら、同じ方向を向くように接するべきだったのかなと。

 

ただ、企画の人間はやっぱり好きになれない。

もはや相性の問題かも。

 

自分なりの正解を考える

企画の人が決めたリリース日を絶対視し、プロジェクトメンバに無理をさせて失敗したことは先に述べた。

今を思えば、なぜ人が決めたリリース日にそこまで執着してしまったのか。

下請け体質が染みついていたとしか言えない。

 

プロジェクトでは、リリース日までに盛り込む機能は決まっていた。

それを最低限やり切ることを目指していたが、そのやり方をあっしは間違えた。

自分のタスクを前倒しで終わらせたメンバに、何の言葉も配慮もなしに、遅れてる仕事をやってもらおうと思ったのだ。

 

本来であれば、前倒しをしたメンバはとてもありがたい存在なのに、そのメンバに対してさらにタスクを積み上げてしまっては、早く終わらせた分だけ損をする印象を与えてしまう。

しかし、あっしはそんなメンバの気持ちに気付かず、自分の役割を果たすことしか考えてなかった。

 

プロジェクトではサイトを作っていたが、そのサイトのローンチは大々的にお披露目するようなものでもなく、ひっそりと始めることになっていた。

つまり、外部と足並みそろえるために決められたリリース日ではないのだ。

だから、その日に固執する必要はそれほどなかった。

しいて言えば、開発メンバ数名のリソースが使える期限がその日までということだ。

 

この状況において、プロジェクトマネージャとして取れる手段は他にもあった。

もしリリース日までにできてない部分があったとしても、サイトとして致命的な機能でなければ、無理に詰め込まずにリリース後にやることもできたのではないか?

リリース後にまわせるものがあるなら、開発メンバに無理をさせる必要はなくなるのではないか?

 

そもそもサイトと言うのは、できてからがスタートである。

そこからpvを伸ばすために改善をしていく必要があり、一度作ったサイトはどんどん手を加えられる。

最初にどんなにちゃんと作っていても、のちのち変わることが前提の代物だ。

SIer時代の業務システムと一緒にしてはならない。

 

そう考えると、もっと軽く考えてよかったのである。

どうせ変わるんなら、時間をかけてきっちり作るのではなく、まずは小さく作って始めればよい、と。

そういう肩の力を抜いたマネジメントでよかった。

 

あっしは人が決めたリリース日に固執し、結果プロジェクトを破綻させた。

これは一種の思考停止で、他者に依存した無責任な仕事の進め方である。

プロジェクトマネージャであれば、そのリリース日を変更することさえ提案する覚悟を持たねばならなかった。

 

自分の仕事には、自分なりの正解を考える。

そのためには視野を限定しないことが大事だということを学んだ。

 

部署間の情報共有を積極的にやる

上記3つは入社直後にやったプロジェクトで学んだことだが、これはそれから1年ぐらい経った頃だ。

事業会社の立ち回りを身に着けて、余裕を持って動けるようになってきたときに、ふとこう思った。

うちの会社って、なんだか足並みがそろってないな、と。

 

SIer時代は、発注元の会社というのが明確にいて、そこに対して全社員が第一線で働くという仕事のし方をしていた。

あっしも、客先に常駐して働いていたので、常に顧客の目の届くところで仕事しているという感覚はあった。

それがなんとなく、会社の一体感を形成していたところがあった。

 

しかし、事業会社では第一線にいる人は営業、サポートぐらいで、他の部署ではごく限られた人しか顧客とのつながりがなかった。

その結果、社員の足並みがそろっている印象がそれほどなく、それぞれの部署がそれぞれの思惑で動いている感じがした。

 

その結果、どうなるか。

部署間の情報共有がほとんど行われてなかったのだ。

 

あっしはこの違和感に気付いて、会社の情報共有を個人的に促進していった。

やったことといえば、当時は開発部の人間だったから、必要だと思ったときに他部署に出むいて説明したり、既存のMTGに5分だけ参加させてもらい情報を共有するというやり方をしていた。

もしくは、導入されたばかりのsalesforceのchatterを使って一斉メンションしていた。

 

効果は徐々に表れた。

他部署と開発部のやり取りが増え、お互いのことを理解するようになった。

その後、情報共有の文化がある程度根付いたが、そのきっかけづくりに貢献したと自負している。

 

何か問題があると、すぐにルールや仕組みを導入したりしようとするが、やるべき情報共有をやるだけで大抵のことはうまくいく。

これがきっかけで、やり方次第で結構どうにでもなるな、という自信がついた。

 

就職って運の要素も相当にある

最後になるが、ちょっとだけ愚痴を語らせてもらう。

 

あっしはこの会社にプロジェクトマネージャとして入社したが、辞める直前にはいちエンジニアに過ぎない状態になっていた。

入社2年半が経った頃に異動をして、当時社内に導入したばかりのsalesforceを使って業務を改善する役割を担うことになったのだ。

 

それは要件のとりまとめから実装まで、すべてをひとりで行う孤独な作業だったが、おかげで久々にコーディングする機会を得たし、salesforceを知るきっかけにもなった。

それ自体は、今を思えばとても貴重な経験になっているので、特に何も思っていない。

 

ただ、入社してからずっと、戸惑い躓き悩みながらも学び、会社の中で生きていくための種を自分なりに見つけて頑張ってきたんだが、それも限界を感じるようになったのだ。

結局、それを認めてくれる人がいないと、だんだんつらくなってくるのである。

それはもう、それを評価してくれる人がまわりにいるかどうかであり、自分の力だけではどうしようもない。

いわば運でしかない。

 

自分が事業をやっていると、自分のやったことが世間に認められれば、それはそのまま売上につながる。

それが会社だと、給料だったり、昇進という形で報われるわけだが、それには会社に認められなければならない。

正確に言うと、そういう権限を持っている人に。

 

もしそういうところで限界を感じてしまうなら、もはや環境を変えるしかない。

自分を必要とするところに行った方が、自分のためだと思ったのだ。

 

ただ、次の会社も自分を理解してくれる会社かどうかは限らないわけで。

結局、転職するならそういう運の要素から逃れられない。

結果的に転職をしたわけなので、そういう限界があることを理解しながら、いまはとりあえず頑張るしかない。

 

まとめる

長文になってしまったが、いまのあっしの仕事のスタンスはほぼ前の会社で培われたものである。

そういう意味では、ものすごく有意義な5年間を過ごした。

 

当時失敗してしまったマネジメントは、いつかリベンジしたいという思いが強い。

在職中は果たせなかったが、その間自分の中でいろいろ整理して、いまはうまくやれるんではないか、という思いがある。

幸いにも、いまの会社ではそのチャンスをもらっているし、認めてくれる人も存在するので、思いっきりやってみようと思っているところだ。

 

ゴールデンウィークは終わってほしくないが。

 

 

▼シリーズのエントリ