カテゴリー : Work

確定申告を e-Tax で済ませるまでに参考にした情報まとめ

たった今、国税電子申告・納税システム e-Tax (イータックス)で確定申告を完了しました。

確定申告をするために参考にした情報を忘れないように書き留めておきます。

確定申告のやり方

誰しも最初は「確定申告って何からやればいいんだろう?」と考えるはずです。

確定申告する前に読むべきオススメ本

まず、確定申告にはどういう作業が必要なのかざっくり把握するために本を2冊読みました。

確定申告する前に読むべきオススメ記事

次に、実践編として e-Tax で実際に確定申告をする流れを e-Tax サイトのスクリーンショット付きで説明しているサイトを読みました。

e-Tax で確定申告

e-Tax で実際に確定申告を進めていくための情報として、「SiGT Web Studio」の確定申告手順がわかりやすくまとまっていてオススメです。

おまけ 収益元の企業と住所情報

グーグル株式会社
東京都港区六本木6丁目10番1号 六本木ヒルズ森タワー

アマゾン ジャパン株式会社
東京都目黒区下目黒1丁目8番1号
https://ja.wikipedia.org/wiki/Amazon.co.jp

楽天株式会社
東京都世田谷区玉川一丁目14番1号 楽天クリムゾンハウス
http://corp.rakuten.co.jp/about/overview.html

株式会社もしも
東京都新宿区西新宿3-5-1 新宿セントランドビル8階
http://www.moshimo.co.jp/information/move.html

まとめ

1年に1度、確定申告は必ずやってくるので、大変な作業にならないように日頃の準備が肝心要は好奇心ですね。

学ぶための質問方法

自画自賛ですが、我ながら良いメッセージを伝えられてたんだなと思ったので、忘れないように記事に残しておきます。

学ぶための質問方法

本当にどうしていいのかわからず、そのたびに社内のエンジニアの方に質問を繰り返す日々。当時の私はgrepの存在すら知らず、いま思うと「よくこの状態でインターンに応募したな」と我ながらあきれるほどです。質問をするときに私は「答えそのものを聞く質問」をしていたようで、「答えそのものを聞くんじゃなくて、答えを得るための方法を聞いたほうがいいよ」とアドバイスされたことを覚えています。

そして、この記事をよんだ同僚のデザイナーさんが Facebook にコメントしていた内容もとてもよかったので引用させて頂きます。

これは凄く良い事をいっていると思います。解っている人に答えを聞くは目の前の作業を素早く終わらせる事はできるでしょうが、長い目で見ると自分の為には全くならないし、何が解ってないのかが判らないままで終わってしまう。
それに加えて答えそのものを聞くって事は”自分は考える気ありません”って言ってるようなものだしね。もし答えの選択肢が沢山あるようなものなら考えさせるってコストを押し付けてることにもなると思いますですし

「自分で考えて、分からなかったら人に聞く」という基本的なことですが、適度なバランスで質問できるといいんじゃないかなと思ってます。

開発チーム体制の振り返り(2015年1〜5月)

6月から自分の所属する Front&Contents チームの体制が変更になるので、2015年1月〜5月までの体制を振り返ってみました。

* Front&Contents チームはユーザ側の機能全般を開発しています

開発チーム体制

チーム体制は下記の図のような感じでした。

team-2015-01_05

Product owner

  • Marketing
  • UI/UX
  • (COO)

Development team

  • Programmer (Lead) ← 自分
  • Programmer
  • Programmer
  • Programmer (Partner)
  • Designer

Product owner (PO) が COO も含めて3人、Programmer 4人、Designer 1人のチームでした。

良かったこと

  • 売上を伸ばすためのマーケティングの施策とユーザ体験を向上させる UI/UX の施策を同じチーム内で取り組めた
  • 開発とデザインのリソースが揃っており、チーム内だけで仕事が完結できた

悪かったこと

  • Programmer (Lead) が単一障害点 (SPOF) になりやすい
  • PO が多いので優先度を PO 同士で調整してもらうのが大変だった

これからの開発体制

6月からは PO (Marketing) 1人、Programmer 2人の小さなチーム体制でメール機能の開発に専念します。

これまでと比べて機動力が上がるので、開発サイクルを速く回していきたいです。

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

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

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

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

と思うこともあれば、

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

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

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

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

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

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

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日が終わりました。

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