最近の仕事の振り返り
Posted on Sat 31 October 2015 in blog
最近、仕事のやり方について考えている(悩んでいるに近いかも)ことが多いので、
頭の中を整理するために、文章にしてみようと思う。
なので、技術的な内容は一切ない。
目次
- スケジュール調整と突発案件
- エンジニアの成長パス
- 愚痴とポエム
スケジュール調整と突発案件
前置き
どんな仕事にも突発的な仕事は大なり小なりあると思う。
自分としては精神的に負担が大きいし、元々やっている仕事との切り替えの負荷が高く集中力が削られるので、減らしたいと思っているのだけど、それ自体は無くせないし、仕方ないと思う。
一方で、(これはどこの会社も同じかわからないけど、)基本的にサービスの目標リリース日は、開発とか検証をする前に決まっていて、マイルストーンが後になればなるほど、リリース遅延が発生した場合の調整の難度が上がる。
特に、営業が社外でプレセールスして良いという段階をすぎると、顧客からの信頼にも関わることなので、営業の人は絶対に避けたいだろうし、僕も避けたい。
そうなると、できる限りリスクを把握して、リリース遅延が発生しうるなら、すぐに周知してマイルストーンを変更する必要があるのだと思う。
(全部完成してから、というのがもっともリスクが少ない方法だけど、実施されていない理由として、スピード感が失われるし、投資回収が遅くなって良くないのだと思う)
実際に困った状況
実際に最近困ったシチュエーションは以下のようなものだった。
体制的には、だいたいマーケティングする人と、開発リーダーと僕を含む開発エンジニアでサービスを作りつつ、プレセールス中は営業の人がフィードバックしてくれる、という体制だと思って読んでほしい。
- 複数のプロジェクトに参加。
- 優先度最高とされた進行中のプロジェクトは2つ
- プロジェクトAは2人で分業, Bは1人で開発
- 同じ開発リーダー
- プロジェクトAで開発以前の遅延があり、大きくずれ込む
- Aのリリース日を延期
- 問題があり、プロジェクトAのリリース日をさらに延期
- Aのリリースがずれ込んだ結果、AとBのリリース日がほとんど近接
- おそらくこの辺りで、プロジェクトBのリリース時期が営業に伝えられていた
- 突発でプロジェクトCが舞い込んでくる
- マネージャー権限でプロジェクトA, Bよりも優先して実施することが明言される
- プロジェクトCの全体スケジュールはまだない状況
- プロジェクトBのリリース日が変わる様子がなかったので、「やだやだ、開発間に合わないし、絶対無理ですぅ」とリーダーに泣きついて、延期調整をしてもらう
- プレセールスを実施している営業の方から、当然どうにかならないか相談を受ける...悲しい
- プロジェクトAはリリース日を変えられないと言われて、「やだやだ、たぶん開発間に合わないし、絶対無理ですぅ」ともう一度泣きついて、別の人をアサインしてもらう
- "たぶん"がついているのはプロジェクトCのスケジュールが来ていなかったから
悩んでいること
どうすれば良かったのかが謎。
自分としてできることは、次はもっと早い時期に、「リリース日遅らせてくれ」って言って行くしかない。
でも、それでも限界があるし、余裕を持ちすぎたスケジュールを作ってしまって、スピード感がなくなっても困る。
開発し始めて、「リリースは来年な」とか言えないし、どうやって複数プロジェクトを並行して開発しつつ、各プロジェクトの遅延とか、突発的なプロジェクトによる差を吸収するのか、本当に難しい。
自分が他部調整を直接やって、プレセールスする時期を遅らせると、もう少しマシなのかもしれないけど、開発に割ける時間が減って、開発期間長くなるしで、悪循環しかない。
追記: 2015/11/01
プロジェクト管理の手法としての、リスク管理を学べばヒントがわかるかも、と気づいたので、以下を読んでみようと思う。
エンジニアの成長パス
前置き
http://r-kurain.hatenablog.com/entry/2015/10/28/090554 という記事が話題になっていたのもあるけど、最近自分のスキルセットについて考えることが多かった。
この記事では、プライベートを大切にしつつ、仕事中に成長できるようにしよう、と言っていると思う。
自分もそういう派というか、「自分がプライベート中に勉強するのは良いけど、他の人には強要できないよね。だから仕事中にできるようになろうね」派なので、共感できる。
悩んでいること
そういう立場だと、仕事中に触れるものは、どういうものなんだろう、と考えることになる。
自分の会社は、割とインフラをサービスにしていて、かつ、特化型に近いのだけどその中で広くやっている。
そのため、人によるのだけど、自分の場合は1つのことをやっている期間が短くて、広く浅くやる感じになる。
その中でエンジニアとしてどういう成長ができるんだろうか。
そして、特化してやっている人もいるのだけど、そういう人に対する成長はどうやったら仕事中に実現できるんだろうか。
特化していると言っても、今やっている仕事に最適化されているだけ、という状況が生まれやすいので、それをどうやって回避して良いエンジニアの成長に繋げられるんだろうか。
(ジョブローテは僕では実施できる権限がないので...。)
最近やっていること
最近、部内勉強会をやっていて、いろんな理由にかこつけて、普段と違うことをやってもらえる準備をしている。
今のところは、徒弟制度でやっていて、1ヶ月以上は準備期間が用意できるようにしている。
ざっくり言うと、詳しい人を選定してマスターになってもらい、その人と違うチームの人を選んでパダワンになってもらうスターウォーズ制度にしている。
勉強会も仕事中にやってもらってるし、準備もできる限り仕事中にしてもらえるようにお願いしている。
準備には知識の伝達と習得の時間がかかるので、1ヶ月以上前からお願いするように心がけている。
現状は、まだ試験実施の段階だけど、上司の理解があるおかげで継続はできているし、もう少し形になってきたら、詳しく書こうと思う。
愚痴とポエム
配属されて結構経って、少しずつ仕事の領域が広がってきたからか、仕事をしていると仕事のやり方について、一緒に仕事をしている人の「悪いやり方」みたいなのが目につくようになってきた。
属人化して自分の仕事を守っているエンジニアとか、それを今まで放置してしまっているマネージャとか、社外とやり取りしている人からの要求に対して文句を言い続けるエンジニアとか、それを一緒になって言ってるエンジニアとか、問題を隠そうとするエンジニアとか。
(もちろん、そんな例は少数だから最近まで気づかなかったんだけど。)
たぶんどんな会社にでもいると思うんだけど、自分は「もっとサービスを良くして、世界で勝てるサービスにしたい」と思っちゃってる人なので、邪魔だな、と思うし、仕事中だけは最低限をこなそうぜ、と思う。それで、それができない人がいるんだったら給料を下げるなり解雇してよ、ってマネージャーに対して思う。人が足りないから穏便に、って思うならメンタリングするなりしよう。
悪い雰囲気が一回広がっちゃうと立て直すのは難しいと思うし、どうにかしたいなー。
最近は仕事で悩みが多いので、地元に帰ってゆっくりと仕事したい。