カテゴリー : Work

”長時間労働” は最終手段にとっておく

ここ最近、自分の働き方について見直す時間をとれていませんでした。

そんな中、考えさせられる記事がいくつか話題にあがっていたので取り上げるついでに自分の意見も書いてみたいと思います。

「スタートアップにいるんだから寝る時間以外、働こうぜ!」

と思うこともあれば、

「なんでこんなに働いてるんだろう・・・?」

というような燃え尽き症候群みたいな感じになることもあります。

そんな状態だとアウトプットの量や質にブレが出てくるので良くないなあと考えるようになりました。

これからは一定の時間内に高水準の成果を継続して出していけるように、もっと仕事を効率化していきたいです。

そして、”長時間労働” は最終手段にとっておきます。

それが心の余裕に繋がりそうです。

Rettyオフィス移転パーティー

Rettyの移転パーティーにおじゃましてきました。

retty-1

retty-2

築地市場から届いた鮮魚で握ったお寿司がとても美味しかったです。

Retty さんにはこの寿司の美味しさの勢いで、引き続き頑張っていただきたいですね。

[EC] 離島の定義と送料の判定処理

以前、配送料を決定する処理を実装する際に、離島の定義が分からなかったので色々と調べたメモを公開します。

ECサイトで下記みたいなよくあるやつ
・本州一律 500円
・北海道、九州、四国 700円
・沖縄及び離島は 1000円

ヤマト運輸のサポートからの回答

平素はヤマト運輸をご利用いただき誠にありがとうございます。
お問い合わせをいただきました件でございますが、弊社では
「離島」の別料金はいただいておりません。
何卒よろしくお願い申し上げます。

ヤマト運輸は「離島」で別料金を取っていないみたいなので、都道府県だけで送料を判定できるから楽そうでした。


参考情報

離島とは(島の基礎知識)

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

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

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

  • 事業規模が見えない
  • 事業内容が既存の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. 最近、ほとんど取り組んでなかったプライベートコードを書く時間を増やす

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

HipChat, Slack, Sqwiggle を常駐させるとメモリ不足で死ねる

社内のチャットツールを HipChat から Slack へ移行中というのと、リモートワークのトライアル期間ということで今日から Sqwiggle を導入していて3つのアプリ常駐させています。

Private group chat, video chat, instant messaging for teams – HipChat

Slack: Be less busy

Online Collaboration Software for Remote and Virtual Teams | Sqwiggle

MacBook Air(メモリ 8GB)だとメモリ不足でツライので、さっさと Slack へ移行してしまいたいです。(自分のためにもやります)

そして、メモリ 16GB 積んだ MacBook Air の登場を心よりお待ちしております。

良いチームを作るノウハウを知りたい

ちょっと前に、元楽天のメンバーがジョインしました。ECビジネスを”知っている”ヒトがやっと社内に入ったという感じです。

一度、ECビジネスを経験しているというのは本当に大きいです。現在、各部署のオペレーションやシステムにメスが入りまくっていて、どんどん効率化されていってます。「ヒト1人ジョインしただけで、こんなにもスピードアップして変わっていくのか!」という驚き、そして経験は宝だなと改めて思いました。

今までは、社内に誰もECビジネスをやったことのない手探り状態でやってきました。それが、EC経験者の加入で進むべき道がより明確になって、無駄な失敗が減らせるようになりました。「失敗は成功のもと」とか言いますが、既に失敗しやすいポイントが分かっているならそこは失敗せずにスキップできるわけですしね。

経験という話でいうと、自分には20人ぐらいのチームでの開発経験が無いというのが最近の悩みです。というか、エンジニア4年目でずっと初めてだらけのことで今に至るので悩みは尽きないのです。

ここ1年半ぐらいは、4人ぐらいの少数でのチーム開発をずっとしてきました。しかし、最近メンバーが増えてきて、開発パートナーの方々を含めると20人ぐらいのチームで1つのプロダクトを開発するようになってきました。少数チームでの開発はチームビルディングという概念が不要でしたが、20人ぐらいになるとチームビルディングが開発スピードに与える影響が大きくなってきます。

このような状況なので、開発メンバーも増えてきてチーム体制を変えたのですが、やるんだったらベストプラクティス的なものを知りたいなあと最近、思うわけですよ。何回も良いチームを作ってきた成功体験を持っている方に、アドバイスを頂きたい。そんなことは思っても、適任者をすぐにリクルーティングできるわけではないので、自分たちで何とかするしかないのです。

というわけで、社内で試行錯誤したり他社のエンジニアさんに相談してアドバイスもらったりして、コツコツ良いチームを作っていってるってのが近況でございます。