カテゴリー : Work

エンジニアは何でもできる魔法使いじゃないんだよ

タイトルで完結していますが、エンジニアの職種を最近やってる仕事を通して考えてることについて書いてみます。

まず IT エンジニアはざっくり下記のような職種がありますよね(順不同)。特にウェブ業界のエンジニアについて書き出してみたので「ここに書いてないけど◯◯エンジニアもあるよ!」という情報があったら、コメント欄で教えてほしいです。

  • Web エンジニア
  • UI/UX エンジニア
  • Android エンジニア
  • iOS エンジニア
  • ネットワークエンジニア
  • インフラエンジニア
  • データベースエンジニア
  • カスタマーエンジニア
  • セールスエンジニア
  • テストエンジニア
  • 分析エンジニア

「他にエンジニアの職種ってなにがあるんだっけ?」と思って調べてみると “ITエンジニアの職種と人材 | IT Job Gate” が細分化して書いてあったのでスクリーンショットで一部引用してみたのが下記の画像です。

ITエンジニアの職種とスキル

ITエンジニアの職種とスキルの一覧

改めて「エンジニア」という言葉で一括りにできないぐらい、様々な職種があります。これはエンジニアをやったことない人には分からないと思うので、例えていうと大学受験の5教科7科目ぐらいそれぞれの職種が違うと言っても過言ではないと思います。

この例に当てはめると、死語としてよく求人情報で使われる「フルスタックエンジニア」は全科目できる優等生になりますね。そんな優秀な人、ゴロゴロいるわけないのは明らかですよね。だいたいは、何かに秀でていて、何か苦手教科があるはずです。

そんな優秀なエンジニアを社内では「ツチノコ」と呼んでいます。

さて、自分の話になるんですが、上記の職種でいうと普段は Web エンジニアの仕事をしています。数年前は、Android や iOS アプリ開発もやっていました。最近は今週末にオフィス移転があるのでネットワークエンジニアみたいなこともやっています。

この記事で伝えたかったのは「エンジニアは何でもできる魔法使いじゃないんだよ」ってことです。Web エンジニアでネットワーク構築のこと分からない人もいるし、モバイルアプリ開発やったことない人もいます。

エンジニアという職種で一括りにして「IT や Web のことだったら何でもできる」という認識はしてほしくないなと考えてます。期待値コントロールは適切にしないと割を食うのは僕たちエンジニアです。

今の職場はいろんなことできて楽しくやってるので特に不満はないのですが、「なんだかなー」と思うことが最近よくあったので文章にしてみました。まあ、社内で浮いてる仕事は全て拾ってやっていくつもりなんで、結局は仕事が好きで「やります」って言ってるんですけどね。はい。

実績がない人の提案は、アイデアはあるけど実行できない起業家みたいなもの

定期的に日報で鋭い提案をしてくれる同僚に向けて返信したメールを一部編集して掲載しました。

以下、メール本文

先週でしたっけ?
Foo さん (仮名) と商品レビュー機能についての話をしていて、考えていることについて概ね同意だなと思いました。

個人的には、あとは「やる」or「やらない」の問題だと思っていて、開発チームだけで完結するものについては Hack day (Google の 20% ルールみたいな時間) 制度ができたのでドンドンやっていいと思います。

あとは他チームへの提案ですね。この部分は難しいですよね。僕もよく悩みます。
自分としては良い提案をしていても、相手が受け入れてくれないとそのチームのメンバーはなかなか動いてくれません。

ちょっと違うかもしれませんが、例えて言うと「アイデアはあるけど、実行できない起業家」とかでしょうか。

提案するのは1つアクションを起こしているので、何もしていないことにはならないですが、「誰もやらないなら自分がやるぐらい」の気持ちじゃないとたぶん実現されないと思います。

最後に「いろいろ言うけど、自分の仕事ちゃんとできてるの?」ってブーメランは必ずくると思います。
ぐうの音も出ないぐらい自分の仕事はしっかりやって、それをベースにして他チームの仕事に首突っ込んだり、提案していかないと発言に説得力がついてこないと思います。

Foo さんも実績を出してない人の話を特別参考にしませんよね?
そういうことだと思います。

お互い頑張りましょう。

確定申告を 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 が仰っていたそうです。

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

決めきれないという負債

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

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

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

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