初心者が作るはんだ付け不要の #自作キーボード
まえがき
これまでいろんなメカニカルキーボードを試してきました、HHKB・Majestouch・NiZ・RealForce etc..どれもとても良い製品でした
次はどのキーボードを試そうかなと調べていると、静音赤軸なる軸があることを知りました
赤軸かつ静音が好きな私にはこれしかねぇ！！！
しかし採用されているキーボードを探るもコンパクト(60%幅)かつ見た目が気に入るやつがない....
どうすればいいんだ...
せや！自分で作ればよいんだ！
こうして私は自作キーボードにチャンレンジすることにしました
キーボードに求める条件
自作キーボードについて調べる前に、まずはどのようなキーボードを作りたいのか、その要件を明確化しました
- 赤軸くらいの軽さで静か
- カーソルキーあり
- 分離ではない
- 60%幅
- できればはんだ付けは面倒だからしたくない
これが実現できるようなものを情報収集していきます
情報収集
はんだ付け自体は良いのですが、はんだグッズを集めるのもお金かかるし、 レンタルできるスペースに足を運ぶのも初心者だからビビってしまう...
はんだ付け不要なものはないだろうか...
調べていたら、以下のブログに行き着きました
どうやらはんだ付けが不要なhotswapという基盤があるらしい、ということでhotswapを使って作ることに決定
その他に必要なものは以下
- キースイッチ
- ケース
- キーキャップ
- プレート
- スタビライザー
- ケーブル
購入したパーツたち
何箇所も見て回ってかき集めるのが初心者にはハードルが高そうだったので、全て KBDfansで購入しました
基盤
hotswapでカーソルキー付きということで、こちらの64キーのものを採用、gk64という名前の配列らしいということをここで初めて認識する
GK64 RGB 60% 64keys hot swap PCBkbdfans.com
スイッチ
静音赤軸で調べるとまっさきにでてくる、Gateron silent redを採用しました
ケース
プラスチック製のものと迷いましたが、カッコいいという理由だけでこちらに決定
KBDfansのレビューを見ると、採用した基盤はケースと合わないことが普通にあるらしく、このケースもどうか分かりませんでしたが、最悪削れば良いやろくらいの思いで買いました（結果大丈夫だった）
ミスリたくない人は、先人のブログやKBDfansのレビューを見て、確実に大丈夫そうなものを購入することをオススメします
KBDfans 5° 60% keyboard aluminum casekbdfans.com
キーキャップ
色が気に入ったので104キー用ものを購入しましたが、64キーの場合2u/1uのShiftキー等、変わったキーキャップが必要なので、基本的にはgk64対応のキーキャップセットを購入することをオススメします
今回2uのshiftはテンキーの0で、その他1uのキーは適当に余っているもので代用したましたが、見ためがいまいちなので全部塗装するか、良さげなのが見つかったら差し替えたい...
Cherry profile dye-sub keycapskbdfans.com
gk64対応のキーキャップセットの例
GK64 XD64 DZ60 PBT keycapskbdfans.com
プレート
前述の通りshiftが2uなので、それを選びました
DZ60 CNC (ALUMINUM/STEEL/BRASS) PLATEkbdfans.com
スタビライザー
これも2uが含まれていることを確認して購入（結論なくても問題なかったので付けてないのですが）
Original Cherry PCB-Mount Stabilizerskbdfans.com
ケーブル
おばあちゃんちのこたつのケーブルみたいなデザインが気にってこれを購入しました 基盤側がUSB-Cなのでそれを満たせばなんでもよいと思います
Handmade USB-C cable 1.2Mkbdfans.com
トータルコスト
$256...高級メカニカルキーボードに匹敵する価格だ... 一度思いとどまるも自作キーボードという漢のロマンに投資する想いで決行
ケースやケーブル、キーキャップはこれより安いものも沢山あるので、１万円台で実現することも可能そうです
| パーツ | だいたいの価格 |
|---|---|
| ケース | $88 |
| キーキャップ | $38 |
| 基盤 | $45 |
| プレート | $18 |
| スイッチ | $25 |
| スタビライザー | $18 |
| ケーブル | $24 |
| 合計 | $256 |
さぁ作ろう
KBDfansで発注してから１週間ほどで届きました
この動画を参考に作っていきます
【自作キーボード】このめんどくさい夏の日も...自作キーボードの作り方！
スタビライザーの取り付け
事前調査ではスタビライザーの組み立てが難関だと伺っていたのですが、組み立て済みの状態で届いていたので取り付けるだけで済みました
上下の向きを間違えないように注意です
プレートの固定
プレートと基盤を固定するために４つ角のキーキャップをまずは取り付けます
キースイッチの取り付け
残りのキーキャップをバンバン取り付けています
キースイッチの端子が基盤に刺さらずぐにゃっとなってしまうことがまれにあったので刺さっていることを確認しながら進めていきました
ここでまずは動作確認
ここまできたらキーボードとしては動作はするので、↓サイトで各キーが反応するかを確かめました
反応しない場合には、前述の通りスイッチの端子が基盤に刺さっていない可能性が高いので確認しましょう
ケースへの取り付け/キーキャップの取り付け
ケースと基盤をねじで固定します
最後にキーキャップを取り付けて完成です！！！かっこいー！！！！！！
感想
はんだ付け不要なこともあり開封から完成まで１時間くらいでできました
こんなに簡単にできるならもっと早くやればよかったと若干の公開
そしてGateron silent red最高ですね、軽い打鍵感に静音性、まさに求めていたものです
ケースはアルミ製のものでそこそこ重量があるので、安定感がありますが持ち運びには適さなそう
今後
スタビライザーのカチャカチャが若干耳障りなので、そこだけはLubeしようと思います
How to Clip, Lube, and Band-aid Mod Your Stabilizers
そして今回自作キーボードの実績解除したので、次ははんだ付け必要なものを視野に入れて作ってみようかなと思います（Mint60が気になっている）
備考：キー配列のカスタマイズ
私はデフォルトの配列で不満ないですが、一応カスタマイズもできるらしいです
Slackのtimesにネガポジ分析を掛けて1年を振り返る
１年の振り返りの意で、Slackの分報チャンネルにネガポジ分析をかければ、
この時期はつらかったなぁ、平和だったなぁというのが見えてくるのではと思いやってみました
僕はやさしいせかいが好きなので、きっと良いスコアになるだろうということを期待しています
やさしいせかいのイメージ
今回作成したソースコードはgithubに上げてます
github.com
ネガポジ分析
当初の想定では、公開されている辞書と形態素解析したコメントを突き合わせてスコアリングしようと思っていました。
ただゴリゴリ磨き込みたかったわけではなかったためお手軽にスコアリングができるものが無いかを探してみたところ、
めんどい前処理もやってくれるライブラリが公開されていたので使用させていただきました
Slackからコメントを取得する
pythonで書いていたので、公式のライブラリをサクッと入れてコメントを取得しようと思ったのですが、どうやらhistoryの取得を行うI/Fは容易されていないようで、今回はWeb APIを普通に叩いて取得しました
特に変わったことは無かったですが、呼び出しの制限、コメントの取得数制限等々あるので、そこは確認した上で利用するが良きです。
結果
コメントごとにスコアを算出し、日毎の総和を出力しています
2019年度上半期のスコアが落ち込んでますが、たしかに振り返るとまぁまぁ忙しい時期でした。
ヘイトや悪口は当然書いていないのですが、どこかマイナスな発言が多くなっていたのかもしれません。
一方で下期は穏やかに暮らしていたので、プラスの傾向がありました。
今年の振り返りはこの結果と共にやってみたいと思います
今回は自分の分報を分析しましたが、チームのコンディションを可視化してみたいケース等、活用どこがあるかもしれませんね。
コーンフレークを判別する #Tensorflow #M1グランプリ
プロローグ
今年のM-1グランプリ、皆さんご覧になりましたでしょうか？ 今年は特にどの組も面白くレベルが高かったなぁと個人的には思っています。 ちなみに私はぺこぱとすゑひろがりずが好きです。
そんな強豪集う今年のM-1、激戦を制したのはミルクボーイ。 予選では歴代最高得点を叩き出し文句なしの優勝です。
コーンフレークやないかい！
上述の歴代最高得点を叩き出したネタです
ネタの内容としては、
- オカンが好きな朝ごはんがあるらしい
- でもその名前を忘れてしまった
- それを特定すべく、色々特徴を聞いてコーンフレークかどうかを判断する
といったものです
「コーンフレークやないかい！」「ほなコーンフレーク違うか」 この幾度となく続く掛け合いが中毒になります
そこでふと思う
めでたくオカンが好きな朝ごはんが「コーンフレーク」だったとしても、 オカンに「コーンフレーク」を食べてもらうためにはどのコーンフレークかを判別する必要があります
シリアル・グラノーラも含めると膨大な種類があります。果たしてオカンはこの中から理想のコーンフレークを探し出せるのでしょうか
コーンフレーク判別機をつくる
そんなオカンのために、コーンフレークの画像からどのコーンフレークかを判別するものを作りましょう 今回は手早くやるためにTensorFlow1系を使います
参考にさせていただいた情報
ここらへんを参照してササッと判別機をつくりました
学習データ
膨大な種類の学習データを集めていたら年が明けてしまうので、 今回はオカンが好きそうなコーンフレークに絞って学習データを収集します
- コーンフロスティ
- チョコワ
- シスコーン
判別してみる
公式のパッケージ画像を判別してみます
シスコーン
https://www.nissin.com/jp/products/brands/ciscorn/
siscorn 0.99967444 cornflosty 0.00031585997 chocowa 9.703208e-06
チョコワ
https://www.kelloggs.jp/ja_JP/products/chokowa.html
chocowa 0.99898654 cornflosty 0.00064735184 siscorn 0.00036609493
コーンフロスティ
https://www.kelloggs.jp/ja_JP/products/corn-frosties.html
cornflosty 0.9479657 chocowa 0.05056956 siscorn 0.0014647491
うまく判別できましたね
もなか
ついでに最中も判別してみます
siscorn 0.80144745 cornflosty 0.12482048 chocowa 0.073732056
最中はどちらかというとシスコーン寄りみたいです
気づき
- コーンフレークの画像持ってるんだったらそれもう商品名分かってるのでは？判別機いらないのでは？
- 知らないコーンフレークに出会える
- 「コーンフレーク」という商品名のコーンフレーク
- コーンフロスト
- シュガーポン
- etc
- コーンフレークが食べたくなってくる
- コーンフレークを判別したか何なんだという悟りを開いた
結論
このように商品画像があれば、どのコーンフレークなのか、という判別は技術の力で実現することができます でも「オカンが好きな朝食が何か」という判別を自然言語から行うことに関しては、ミルクボーイを頼る他ないと思います
Tensorflowで判別機を作るのは初めてだったのですが、コーンフレーク判別機を作ろうと思い立ってからこの記事を書き終わるまで数時間しか要しておらず、 ここまで簡単にできてしまうのか...と感動しています 学習データさえ揃えばある程度の精度の判別機をつくることはサッとできそうなので、今後も活用の幅がありそうです
エンジニアだけで企画・開発・分析全てを遂行するチームを立ち上げた話
この記事はRecruit Engineers Advent Calendar 2018 - 13日目の記事です。
追記
本記事の内容にて、s-dev taksで登壇してきました speakerdeck.com
前書き
本記事は個人的な見解を示したものであり、所属する組織を代表するものではありません。内容には留意しておりますが、もし不適切な内容や誤りがあれば、私個人当てにご指摘のコメントをいただけますと幸いです。
超概要
- カットオーバーから数年経ったtoCサービスにおいて、エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイクル全てを担うチームの立ち上げを行いました
- 開発しか知らない僕らがよりよい価値を世に届けるために、企画や分析方面への染み出しを行う中での泥臭い取り組みや、やってみて分かった知見を共有します
- 経験ベースで築いてきた知見なので、理論を踏まえてなかったり、原理原則とは乖離する箇所もあるかと思いますが、温かい目で見守ってくださると幸いです
話さないこと
KPIを爆改善して圧倒的成果を挙げた話
話すこと
事業をグロースさせるための、仮説検証プロセスの装着を地道に、泥臭く行ってきた話
目次
- 追記
- 前書き
- 目次
- 仮説検証チームの爆誕
- 仮設検証型チーム構築のSTEP
- STEP1：As-Isプロセスの可視化
- STEP１.５：As-Is課題の抽出
- STEP２：Learnの質向上
- STEP３：BMLの高速化
- 終わりに
- APPEND
仮説検証チームの爆誕
企画・開発・分析全てを担うチームとは
私が担当しているプロダクトはカットオーバーから数年が経過し、そこそこのユーザー数を抱えています。
これまでは、競合と対比して明らかに不足している（競合劣位となっている）機能の装着をメインとしてきたものの、競合との大きな差分が無くなったいま「これから何を目指すべきか」「どのような価値をユーザーへ提供していくか」を模索している段階でした。
そのような背景の下、「何が正解なのか」「どこがサービスのボトルネックなのか」に対する答えが無い中で、エンジニアオンリーのチームで仮設検証を高速で回し、プロダクトの磨き込みを行うことを目的に、チームが爆誕しました。
おっしゃ！やったるぞ！！という息巻いたものの、ここから多くの課題と向き合い、時には泥臭い取り組みをしつつ、チーム自体の改善を重ねていくことになります。。。
そもそも僕らはエンジニアである
最初に集まった３人は多少経歴の差異はあるものの、皆開発を生業としてきたエンジニアです。 そこで２つの課題が浮上しました。
その１：まず開発以外のことが分からない
- 仮説を立案し、コードとしてデプロイすることで世に放ち、その仮説をどのように評価するのか、まるで分からない
- なぜなら僕らは開発しかやってこなかったのだから
その２：そもそも権限委譲されない
- 開発チームがいる一方で、企画やプロデューサー等、プロダクト改善を担ってる先人達がもちろんいる
- いきなり以下のようにはならない
- ワイ「自分で施策考えて開発して仮説検証回していきたいぞい！！！」
- 偉い人「OK！！！！！！！！」
- なぜなら僕らには開発スコープ以外の実績が無い。実績もなければ信頼もない
これらの課題にまずは取り組んでいくことになります。
仮設検証型チーム構築のSTEP
BMLプロセス
仮説検証という表現をここまで使ってきましたが、実際にはBML(Build-Measure-Learn)のプロセスを意識してプロセスの改善を行ってきました。以降、BMLになぞらえて話を進めていきます。 ここでは詳細な説明は割愛させていただきますが、 雑にWikipediaのリンクを貼っときます。 Lean startup - Wikipedia
気になる方はリーン・スタートアップあたりを読むと良いかもしれません。 http://amzn.asia/d/9ZSuzgMamzn.asia
段階的なプロセスの磨き込み
開発以外ド素人な僕らが立派にBMLを回していくために、以下のような段取りでプロセスの磨き込みや、知見の獲得をしました。
※ここでいう企画／プランナーはWebサービス／スマホアプリおける施策（機能追加／改善等）を考える人のことを指しています
それぞれのSTEPについて、以降掘り下げて説明していきます。
STEP1：As-Isプロセスの可視化
地道に紐解いていく
そもそもカットオーバーから数年経ったプロダクトなので、既にプロダクト改善の活動は当然行われています。しかし、仮説立案〜リリース・効果測定の一連のプロセスが不明瞭で、そこをまず可視化し、現状を踏襲するところから始めました。
段階的な権限委譲
結論としては、一連のプロセスを可視化した上で、１個ずつ知見を蓄え、権限委譲していくことになります。
こう図に示してみると綺麗に事が進んでいるように見えますが、実際には泥臭い取り組みの数々でした。そのうち何個かをピックアップしてご紹介します。
徹底的な競合研究
いざ仮説を立てようとしても、中々出てきません。というのも、意外と自分のプロダクトのこと、はたまた競合のことを全然分かっていなかったからです。従って、自社・競合のプロダクト研究を一番最初に取り組みしました。
１日１プロダクト、１時間の枠の中で、メンバー３人で顔を合わせて徹底的にアプリを触りまくります。その中で思ったことを共有したり、自社と他社の差分を徹底的に洗い出して、その差分がどのような効果をもたらすか、どのような意図があるのかを考察していました。
２週間で仮説１００本ノック
競合研究で知識をインプットする傍ら、こちらでアウトプットの鍛錬を徹底的に行います。
仮説立案・企画スキルの醸成を目的として、ひたすら施策を考えまくってひたすら事業責任者にレビューして貰いました。
今思うと最初に持ち込んだ施策は、仮設の筋が悪く、てんで方向違いなものばっかりでセンスの欠片もなかったかと思いますが、事業責任者やプランナーさん達のご指導の下、何回も壁打ちしているうちに、勘所が掴めてきたかと思います。
As-Isプロセスの可視化
こういった取り組みを経て、仮説立案〜リリースまでの一連のプロセスを可視化及び整備をしていくと共に、各プロセスを独力で担えるようになりました。
ここで整理したのは以下です。
- 各プロセスのINPUTとOUTPUT
- 関連するセレモニー（会議）
- そこらじゅうに散らばってる関連ナレッジ（先人達の知見が色んなところに落ちている）
これをベースとして、次はプロセスの「改善」を進めていくことになります。
STEP１.５：As-Is課題の抽出
ようやくAs-Isのプロセスを遂行できるようになった僕らは、一定期間このプロセスに従ってプロダクト改善を実施しました。そして次なる課題を発掘するために、以下に分割して振り返りを行いました。
- 僕らがAs-Isのプロセスを遂行できているか
- As-Isプロセスの課題は何か
- 各課題のTo-Beは何か
- その差分を埋めるアプローチは何か
この振り返りを経て、次なるステップに進むことになります。
STEP２：Learnの質向上
見えてきた課題
STEP1を経て、仮説立案〜リリースまでを独力で遂行できるようになりました。 しかし、BMLを繰り返し行う中でも、特にLearnが質が浅く、次なる仮説につながらないという課題が浮上してきました。
リリース後に効果測定を行って、狙った数値が改善されたものの、「良かったね！...で、次はどうする？」という状況です。
そこでLearnの質を向上させるために、３つの打ち手を講じることになります。
- KGIの見直し
- ABテスト基盤の拡充
- 分析設計の型化
チーム目標の見直し
ここまで話には出していなかったですが、チーム目標としてはLTVを置き、それを向上させるべく日々改善を回していました。（チームの目標設定に関しては今回触れませんが、数値目標を置くよりもOKRを設定し、そこから落とし込んだ方が良かったかもということを今振り返ると思ったりします。）
つまり、LTVに寄与するプロダクトの改善ポイントを探し、施策に落とし込み、それをリリースした結果から学びを得ようとしていましたが、何せLTVはKPIツリーで考えるとだいぶ上位の指標です。
これにより以下の問題が発生しました。
- 施策毎にアプローチするKPIが異なり、学び・知見が集約されない
- 短期的な利益を得る施策に落ちがち
- 大きい指標にすぐアプローチするためには、大きい施策を打たざるを得ない力学が働き、これによって仮説検証スピードが低下する
等々の問題を解消するために、チーム目標の粒度を一段落とし、フィードバック得やすくしました。
ここでは担当プロダクトの詳しいことは述べられないのですが、イメージとしては以下です。
ABテスト基盤の導入
施策の効果測定はリリース前後での各種CVRの比較を行っていましたが、前後比較は曜日や季節・広告等の影響を排除した効果測定ができず、改善されているかどうか分からないということがしばしば発生していました。
ここでようやくABテスト基盤を導入するに至ります。
お恥ずかしながら、うちのプロダクトではABテストを柔軟に行える仕組みが無く、ABテスト１回に費やす開発コストが大きかったため、Firebaseを導入しABテストを実施しやすい環境を整備しました。
分析設計の型化
仮説を考え、施策を打って、さぁ効果測定だ！と息巻いたものの、実は見たい指標が取れていなかったり、そもそも「何の数字」が「どれだけ」、「どうなったら」成功なのだろうか、と思ったことは無いでしょうか？
僕のチームではこういうことがしばしば発生していました。 そこで仮説を考え、その開発に入る前に分析設計というフェーズを明示的に置き、その中で以下を整理していました。
測定対象の整理
- Why・・・何を検証したいのか
- What・・・どの指標を見るのか
- Where・・・データソースはどこか（DBから見るのかアクセス解析ツールから見るのか、それは現在取得できているのか）
- How・・・比較方法は何か（前後比較／ABテスト等）、算出方法は明確になっているか
- When・・・いつ測定するのか（リリース直後、３日後、７日後等）
アクションの整理
- いつ
- どの指標が
- どうなったら（上がる、下がる、横ばい）
- どうする（測定を継続、切り戻す、測定終了／どう解釈するか）
STEP３：BMLの高速化
BMLを「高速」に回す
これまでの取り組みで、ようやくBMLサイクルを回せるようになりました。（もちろん回すこと自体が目的ではないですが）
次なる課題として、以下に多くの学びを得るか、学びの量を「質✕回数」と定義すると、質の面はSTEP２に示した通りのアプローチを行いました。つまり次は回数へのアプローチを行います。
定常モニタリング基盤の構築
定常モニタリングの狙いは以下の２つです。
- 分析の自動化
- 健康状態の可視化
分析の自動化
これまで効果測定における分析作業は、全て手動でSQLを叩くという苦行のような作業を行っていましたが（リアルガチで苦行だった）、ここでようやく分析の自動化を行うことになります。
健康状態の可視化
何か施策を打った際に、KPIは小さい指標から先に効果が出て、より大きい指標へと波及していきます。 それらの分析として自分が認識している範囲内であれば、これまで通り手動でSQLを叩き効果を見るということができますが、予期せぬ箇所まで影響が及んでいることも時にはあるかと思います。
もしくは施策直後には大きく影響が出ていないが、じわじわと影響を及ぼしていることも考えられるでしょう。
施策の効果測定という側面でだけでなく、仮説を立案する際に「どこかボトルネックになっているのか」を特定するためのフックとして、プロダクトの健康状態が常に可視化されていることが望ましいです。
定常モニタリング構築のSTEP
これだけで記事一本書けちゃうくらいなので詳細な説明は割愛しますが、定常モニタリングも最初は手動のSQLから初め、不確実性を排除しながら徐々に構築していきました
フロー効率を重視したプロセス構築
開発プロセスの話は欠片もしてこなかったのですが、ここに来てようやく考え始めました。
この取り組みはまだやり切れていないのと、「フロー効率」でググれば素晴らしい知見が沢山出てくるので、ここも今回は割愛させていただきます。
終わりに
長々と綴りましたがいかがだったでしょうか？ グロースハック、仮説検証、BML、最近ではよく聞く言葉になりましたが、その裏には泥臭いこういう取り組みもあるよ、という事例を今回紹介させていただきました。
ここではプロセスに偏った話をしましたが、僕らは正しい問題にフォーカスして理想のプロダクトを作り上げることでユーザーに良い思いをして貰いたいお気持ちで、このような取り組みをしています。
より良いコードを、よい良いシステムを作り上げていく一方で、正しい問題にフォーカスしてムダなコードを書かないためとも解釈できるこのような取り組みも、僕らエンジニアのやりがいなのかなと思う最近です。
APPEND
まだまだ書きたいことがあるのですが、もうキリが無いのでその他トピックに関して軽く補足して終わりとします。
既存チームとの棲み分け
僕が担当しているプロダクトでは、元々はプランナーと開発が明確に分かれており、プランナーは施策を考え、開発チームがひたすら開発する、という一般的なスタイルでした。
そんな中、うちのチームと既存のチームでどう棲み分けてやっていくべきかということを考えました。
包括的に言うと、我々のチームはSoE、既存の開発チームはSoR的な思想に基づき、棲み分けすると良いのかなと感じております。
SoEとSoRについては@i2keyさんの↓のスライドが１億倍分かりやすいし造詣が深いです。
www.slideshare.netそのような分けの中で、我々はBMLを回しながら不確実性を落としにいき、ある程度のところで大きく踏み出す施策を、既存チームにバトンタッチして開発してもらう関わり方を考えています。
プランナーとの棲み分け
「エンジニアだけでもう良いじゃん」
「もうプランナーはいらなくない？」
このようなチームをやっているとよく聞かれることです。 しかし、僕はプランナーは必要だと言うことを声を大にして言いたいです。
というのも僕らのチームでは、不確実性を落とすという側面から仮説検証を小さく踏み、結果として施策の大きさが小さくなるため、１回の施策あたりで検討することも少なく、プランナーとして求められるスキルもそこまで多い訳ではないです。（もちろん仮説の構築にあたって、目先の施策だけ見てる訳ではないですが）
一方で、前述のSoR的案チームで扱うような施策は単純に規模が大きいです。大きいというということは検討することが膨大にあります。
- マーケットをより踏まえた要件の検討
- 売上影響レベルでの効果予測
- 法務観点でのリスクチェック
- 投資決裁
- そもそも僕らよりも圧倒的にビジネスに詳しい
などなどです。これらを僕らが開発の傍らでできるとは到底思えません。 つまり取り扱う施策によって棲み分けるべきということです。
そういった理由でプランナーは必要不可欠だし、リスペクトしております。
SIerからWeb系に転職したのでこれまでを振り返ってみる
転職しました
9月いっぱいで３年半務めたSIerを退職して某Web系の企業に転職しました。
同じ趣旨の記事を幾度となく見ていますが、一旦ここまでのエンジニアライフを整理しよう！ということも兼ねてブログに書こうと思い立った次第。
SIer時代
まずは前職を振りかえってみます。
１年目
半年間のなが〜い研修を経て、配属されたPJはなんとCOBOL。エンジニア人生を詰む前に転職しようと決意。（※COBOLは良い言語です）
と思った矢先にとあるWebサービス保守案件に転属。退職するまではずっとここの案件主軸で携わっていくことになります。
PL（プロジェクトリーダー）の先輩が年末に退職してしまったこともあり、すぐにリーダーみたいなポジションにつくことに。
とはいえ知識不足、経験不足は否めず、周りの先輩方やパートナーさんに助けて貰いながらなんとかやってこれました。
２年目
正式にPLになりました。PMの先輩が別案件に移動する構想があり、徐々にPMにシフトし始める。
また、この年から社内ハッカソンが開催され、「SIerのハッカソンなんか余裕やろ」と思い参加するも惨敗
susunshun.hatenablog.com
３年目
PM（※社会的事情により体制図上はリーダ）っぽいことをしつつ、余裕が出てきたこともあり他案件に自分から飛び込んだりアサインされたりして兼務をし始める。この頃から「プログラマーよりもマネジメントやビジネス企画の方が適性があるかもなぁ」と思い始める。
そして去年惨敗したハッカソンでリベンジ成功
susunshun.hatenablog.com
既に「SIerは今後衰退してく」という確信はあったものの、転職という選択肢はまだ頭になく、SIerが生き残るためにはどうすれば良いかを考えていました。
会社の都合で受けさせられた斎藤昌義さんのITソリューション塾に３ヶ月程通い、これに影響を受けた面もあると思います。
blogs.itmedia.co.jp
４年目
会社のパンフレットにデカデカと載ったり、数百人の自社エンジニアの部署の前で講演したりと、何かと前に出る機会が多くなってきました。
講演では「イノベーションを起こすためにはどうすれば良いか」をテーマにディスカッションしました。
社員一人一人に意見を発信できる数少ない機会だったので、SIerのビジネスモデルにおける構造的問題には極力触れず、「これからはSIもサービスを打ち出していかなければ苦しい時代。せめて最新のITニュースくらいはチェックして、みんなで発想の幅を広げていこうぜ」ぐらいの、かなり敷居の低い話をしたつもりだったのですが、周りの反応では「やっぱりお前は一味は違うな、お前に任せた！」みたいなフィードバックをもらいました。
ここで「自分ではこの会社を変えられない」という確信を得るとと共に最大のモチベーションダウンを喰らいました。
またSIerは「システムを作ること」を生業にしている会社であり、「どのようなサービスを作るか」は顧客に依存しています。こういった事業特性から「自社サービス」に対する羨望みたいのが膨らんできた時期でもありました。
こうして転職に踏み切ることになります。
転職活動
転職活動を始めた矢先に友人の紹介で、最大手の外資系IT企業（日本法人）から製品サポート部隊のオファーが来ました。ゼロベースで受けたらまず入れないような企業です。
何回かの面談もつつがなく進んだのですが、入社決断を告げるメールを打っている途中で突然手が止まってしまいました。そこから「自分の本当にやりたいことって何だっけ？」を二週間もの間、自問自答し続けることになりました。（この時期は悩みすぎて情緒不安定でした。。。）
散々悩み抜いた結果、自分がIT業界に飛び込んだ理由は「一般消費者の生活をより楽しくするサービスを作ること」と原点回帰し、オファーされている職種とは乖離していたこともあり、二度と無いチャンスではありますがオファーを断りました。ここが人生の分岐点だと思いますし、今後もそうあり続けると思います。
といった経緯を経てWeb系に絞って転職活動を始めたわけですが、私はかなりの安定志向です。本当は転職もできれば避けたい所です。前職に不満があり転職に踏み切ったものの、給与が高ければ不満をごまかして残っていた可能性も充分に考えられます。
なので転職するからにはそれなりの企業に入らなければ、という無駄なプライドがあり、ベンチャーは視野にありませんでした。結果的に自分が魅力的だと思えるWebサービスを最も多く提供しているとある企業の面接を受け、採用いただいた次第です。
ちなみに私はほぼ開発未経験なのですが、運良く希望していた内製開発部隊に入ることができました。
今振り返って見ると、ここで不採用だったらまだ前職で働いていたかもしれないですね。。。
これまでの業務から得た知識、スキルを最大限に活かすならば他の部署の選択肢がありましたし、面接でもそのポジションをゴリ押しされましたが、敢えて未経験領域（※）である開発へ飛び込んだ理由は後述します。
※家で勉強したりはしていましたが、仕事で開発した経験はほぼ皆無でしたので。。。
何故開発に飛び込んだか
これまで家でアプリを作ってみたり、ハッカソンでプロトタイプを作ったり、と開発の真似事はやっていたものの、業務として開発（コーディング）を経験したことはありませんでした。
将来的にはPMに戻ることを視野に入れていますが、良いPJ運用をするためにはその中身を知っておくことが私の中で重要度が高く、最大の理由であります。
（開発を経験せずに、マネジメントやディレクションに特化したタイプもいますが）
あとは適性は無いと分かっていてもプログラミング楽しいしね、自分がコーディングしたシステムを一度で良いからリリースしてみたいよね。
転職して２ヶ月が経ち。。。
プログラマーということでほぼゼロからのスタートです。最初に行われたスキル評価を行う面談でも、「新人と同等レベル」という評価を下されました。
配属されたPJで開発が始まりましたが、足を引っ張ってばかりの毎日です。
でも後悔はしていません。数年間という短期間ではあるものの、プロジェクトマネジメントに従事してきた手前、いま自身がプログラマーとして行っている作業がPM時代の経験とリンクし気付かされることが多く、今後PLやPMに戻った際に従来よりも良いPJ運営をできるだろうなぁ、と思います。
あとやっぱりプログラミング楽しい！
最後に
転職はしないに越したことはないです！
たまに「転職した俺マジ上昇志向」みたいな安直な人を見かけますが（これをファッション転職と呼んでいます）、転職は成功を約束されたものではないです。当たり前のことですね。
付け加えると、完全に一人で仕事している人（もしくはそう思い込んでいる人）ならば良いですが、環境を変えるということはリスクになります。
その界隈の有名人でも無い限りは社内で築いてきた人脈、信頼関係がリセットされるためです。
エンジニアは開発歴からスキルを明確化しやすく、次の職場でもそいつはどういうスキルを持っているのか、を理解されやすいので他の職種よりは幾分マシかもしれませんね。
私はそういったリスクよりも、自分のやりたいことが上回ったため転職に踏み切りました。
最後に、転職活動自体にメリットはあったか、というと「あります」。
転職活動を行う際に自分のスキルセットを整理したり、自己分析をしたり、これまでの自分を棚卸しをしました。これは今後転職しないにしても定期的に見直すべきことだと感じています。
また、自己分析の一貫ですが「自分のやりたいこと」を改めて振り返ることができ、今後の身の振り方にも影響を与えていくと思います。
いまは勉強の毎日ですが、一段落ついたら転職後のことについてまた、書きたいと思います。
それでは、皆さんも良いエンジニアライフを！
CodeIQ夏の陣に行ってきたメモ
CodeIQ夏の陣に行ってきました
僕はプロジェクトの都合で平日は抜けれないことが多いので、勉強会やセミナーに行きたいと思うものの行けてなかったのですがビッグなイベントが土曜にあるということで行ってきました。
以下メモ書きをほぼそのまま書きますが、内容に多少のズレがある可能性はご承知くだされ。
エンジニアサバイバル
・生き残る上で大切なこと
- ゴールを設定：漠然としてると運任せにせざるをえない
- ルールを理解
- 本当のルールを把握する：騙されてない？前提を履き違えてない？
- 問題解決：エンジニアの本懐
・エンジニアの問題解決プロセスは他分野にも応用できる
ex)憲法改正はプルリク的な
・許可を求めるな謝罪せよ！！
やってもいいですか？という問いは上司的には辛い（責任が伴うので許可を求めて欲しくない）
やっちゃおう！！ダメだったら謝ろう！
・生産性が高いと大抵の問題は解決する
とはいえそれを実現するためにはある程度の裁量権が必要。組織としてそういう仕組みが必要。
パネルディスカッション
お題を以下から拾ってディスカッションする形式ですか
github.com
印象に残ったお題をピックアップして書きます。
勉強会に参加することを是とするか
・勉強に行く時間あるなら勉強しよろ、という意見もある
・自分の関心に火を付けに行く
・自分の達しているレベルが相対的にわかる
僕としては勉強会は知識のインプットの場ではなく、刺激を受ける場所であったり、
今回の夏の陣みたいにお祭りに乗っかっとけわっしょい！的な認識が強いので
「勉強」という捉え方はあまりしてないです。
それは技術力の低さや勉強を怠ることへの言い訳に聞こえてしまうかもしれませんが、エンジニアの技術力は知識量だけでは測れないと思っていますし、もっというとエンジニアの有能さは技術力だけではないと思っています。
ディスカッションの中でもスパッと結論が出てる訳ではなかったので、これは個々で定義して認識しておくことでしょう。
技術をどこまで追うべきか
・サービスの会社はテクノロジーオンリーの会社ではないので、新しい技術をどこまで追うべきか
・とはいえ技術の相対的な敷居が下がった
・デザイナーがエンジニアの領域に、その逆もしかり
・コモディティ化するのでハイレベルを求めた方がよい？
・新しいもの楽しそうだし追いたいじゃん？
これは難しい。。。
定量的な答えは出ないとおもうので「ちょうどよい」線引きをしてバランスを取ることが大事ですね。
生産性ってどう？
・残業して成果をあげることが褒められる文化よくない
・日本企業はそもそも生産性を上げる取り組みをしていない
・最初から作り込まずに、抜くところは抜こう（海外のサービスはそこがうまい）
・生産性とクリエイティブは二律背反
・第二のビルゲイツはビルゲイツじゃないし、日本のシリコンバレーはシリコンバレーではないからそういうのやめよう
・クリエイティブな時間を持つために生産性をあげよう
とはいえ”筋肉”
・筋肉こそ最強
・SoftSkillsにも書いてある
・そこでアニメヨガ（from きゃんちさん）
筋肉は陳腐化しないしね、間違いないね。筋肉こそ唯一にして絶対的な答え。
最近気に入ってるフレーズは「生産性が高いと大抵の問題は解決する」だが、こないだ聞いた「筋肉はたいていの問題を解決する」もなかなかインパクトあるな。
— Yukihiro Matsumoto (@yukihiro_matz) 2016年7月18日
とはいえ筋肉は単なるネタではなくて、ハードワークを良い状態でこなすためには健全な肉体が必要ということです。
参加してみて
今回はCodeIQですので、転職イベントという側面もあり既に転職先が決まっている僕としては申し訳ない気持ちはありましたが、著名人方の話を直接伺えたり、他社のエンジニアとお話しさせていただいたりと、普段イベントに参加できていないので良い刺激を受ける場でした。
転職後はある程度は自由が利く身になる（はず）なので、積極的にこういった場に顔を出していきたいと思います。
いつかこういう場でLTをやってみたい。。。そしてきゃんちさん可愛い。。。
Web SQL DatabaseでexecuteSqlした後に何か処理する
前回の記事の続きでWeb SQL Databaseを使ってみた。
が、executeSqlでselectを実行する際、その結果はコールバックで受け取る必要があるのでここもネックになってます。
不都合があったのでその対応メモ。
monacaアプリの中でAngularJSを使ってます。
対応
1,2が非同期処理なので、何も考えずに書くと1→2の処理順が担保されません。
なので1,2はpromiseを使って同期しちゃう。3は2の中に入れちゃう。
module.controller('AppController', function($scope) {
// DB生成
var createDatabase = function(){
return new Promise(function(resolve, reject) {
// タイムアウト値の設定は任意
setTimeout(function(){
console.log('Start createDatabase');
var db = window.openDatabase("Database", "1.0", "TestDatabase", 200000);
if(db.version == ""){
console.log('not exist db');
// DB無いので作ります
db.transaction(
function(tx){
tx.executeSql('DROP TABLE IF EXISTS TestTable');
tx.executeSql('CREATE TABLE IF NOT EXISTS TestTable (id unique, name)');
// テストデータを叩き込む
tx.executeSql('INSERT INTO TestTable VALUES (1,"てすとでーた")');
},
function(){
// 失敗時
},
function(){
// 成功時
}
);
}else{
console.log('exist db');
}
console.log('End createDatabase');
resolve();
},100);
});
};
// 検索
var selectDatabase = function(){
return new Promise(function(resolv,reject){
setTimeout(function(){
console.log('Start selectDatabase');
var db = window.openDatabase("Database","1.0","TestDatabase",200000);
db.transaction(
function(transaction){
transaction.executeSql('SELECT * FROM TestTable', [], querySuccess, errorCB);
},
function(){
// 失敗時
},
function(){
// 成功時
}
);
console.log('End selectDatabase');
},100);
var querySuccess = function(tx,results){
console.log('Start query');
// *************************
// クエリ成功時の処理をかく（results → testdata）
// *************************
// scopeの更新と反映
$scope.testdata = testdata;
$scope.$apply(); // ★
console.log('End query');
resolve();
};
var errorCB = function(err) {
console.log("Error occured while executing SQL: "+err.code);
}
});
};
createDatabase().then(selectDatabase);
});
やりたいことその２
- CRUD処理はfactoryでまとめたい（controllerに書きたくない）
- select処理の後、$scopeに値をセットし、$scope.apply()をしたい（上記★の箇所）
つまりselect → 結果をセット → 反映の順番を担保したい
ということでCRUDはfactoryで書こうと思ったのですが問題が。。。
問題箇所
いろいろ試した結果、factory経由で$scopeの値をコントローラ間で引き継ぐことはできるが、factory内で$scope.apply()が効かなそう（合ってるのかな？）
とはいえ、factoryの処理(ex. select処理)完了を待ってcontroller側の処理($scope.apply())を行えれば良いので、factory側の処理とcontrollerで同期したいところですが、うまい方法が見つからず(›´ω`‹ )
機能的にはlocal storageでも問題無いのでそちらに移行しようか検討中
