カテゴリー : Work

モチベーションが全く上がらない開発案件

モチベーションが全く上がらない開発案件が浮上したという話をエンジニアの友人から聞かされました。

ざっとダメな点を列挙してみると、

  • 事業規模が見えない
  • 事業内容が既存のECサイトとシナジーが無い
  • 市場調査ができていない
  • 収益の試算ができていない

というような内容です。

話を聞く限り、開発リソースを割くのに値しないのでやらないのが懸命な判断と感じました。既存の顧客のニーズをヒアリングしていなかったり、数字だして考えてない段階で事業案として提出しているのはお粗末すぎるので、もうちょっと頑張って欲しいですね。

久しぶりにモチベーションが全く上がらない開発案件が浮上してきて、とても残念な気持ちでいっぱいと友人は言っておりました。エンジニアが参加する段階の MTG で自分の口から「この開発、やる意味あるんですか?」っていわないといけない時点でどうなのという・・・。

「社内のエンジニアが納得できないような事業案を出してる時点でダメだよね」とその会社の CTO が仰っていたそうです。

事業の発案者にはエンジニアに開発工数を出してもらう前に、自分でも数字出すとかやるべきことをちゃんとやってもらいたいですね。

決めきれないという負債

意思決定がスムーズにできないと、工数としての時間やスピード面で圧倒的に不利になる。

意思決定をするのは「誰か?」、「権限が曖昧」というのが問題としてあげられる。

それにより、決めきれないという負債が溜まっていく。

これはスタートアップにとって致命的である。

「チームメンバーとの信頼関係を築く:定期個人面談の薦め」を読んで 1on1 実践してみたらとてもよかった!

チームメンバーとの信頼関係を築く:定期個人面談の薦め – クックパッド開発者ブログを読んでみて、1on1 を実践してみたらよかったという事実を忘れないように書き残しておきます。

面談という名の雑談を30分ぐらいしました。意図的に30分ぐらいの時間を確保しないと、日々の業務に忙殺されてよくないなと面談を終えて改めて感じました。普段、話さないような話題もできたので、無理やり会話する場を作ってみて正解でした。

これからも、隔週ぐらいで 1on1 の面談を継続していきたいです。あとはチーム内のエンジニアだけの MTG の時間もとってなかったので、こちらは週1回ぐらいのペースで行うと捗りそうな気がしております。

長期休暇明けのキャッチアップ

新婚旅行で一週間ほど休暇を頂いてました。7日間も休んでいると復帰後のキャッチアップを効率良くやらないと、日々の業務量に溺れてしまいそうだったので、どういう手順で不在時の仕事内容を把握するかまとめて、実際にやってみました。

キャッチアップの手順

1. リリースノートを読む

Devチームが週次で全社員向けに作成しているリリースノートを読んで、どんな機能がリリースされたかを把握します。まず、機能開発・変更の概要をざっくり掴みます。

2. 大きな仕様追加・変更などをDevメンバーに確認する

知らないとハマりそうな仕様の追加・変更などのポイントを、開発チームメンバーにチャットツール Slack 経由で教えてもらいます。これで無駄な開発の手戻りを減らします。

3. Github の issue や pull request をチェックする

特に自分に mention があるものを重点的に目を通します。ざっと終わったら、次は Merge できる pull request を1つずつマージしていきます。それが終わったら、未レビューな pull request をレビューしていくという流れになります。

まとめ

実際にやってみて、一週間分の変更を1日だけで”全部”キャッチアップしようとするのは、とてもじゃないですが無理でした。

現実的には、「リリースノートを読む」「大きな仕様追加・変更などをDevメンバーに確認する」の2つをやって、あとは残りをやりつつ、質問や差し込みのタスクなどが入ってきたら、それをやるという感じであっという間に1日が終わりました。

全て把握するのは無理でしたが、現実路線でその日に依頼されるタスクをこなしつつ、空いた時間はキャッチアップに使うのがよさそうでした。

”つくりたいものを、つくれる環境を、つくる”

中田ヤスタカの記事を読んで、思うことがいくつかあったので今の気持ちを忘れないように書き残しておきます。

Changemaker | Changemakers of the year 2012 次の日本を、世界をつくろう。

つくりたいものを、つくれる環境を、つくる

繰り返します。

つくりたいものを、つくれるような環境に自分を置く。
実はこれが一番難しいことです。特にプロとしては。
だからこそ、つくっている人が一番頑張るべきところも、ここです。

つくりたいものを、つくれる環境をつくる。

最近、仕事に対して悶々としていましたが、この記事を読んで2つのことを決めました。

  1. お金貰ってコード書くエンジニアとして、枠の中で成果を出す
  2. 最近、ほとんど取り組んでなかったプライベートコードを書く時間を増やす

仕事への考え方を変えていきます。