taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

「7つの習慣」読了

完訳 7つの習慣 人格主義の回復

完訳 7つの習慣 人格主義の回復

 何年も前から存在は知ってたけどなんとなく避けていて、ここ最近になって急に「読むべきだ」という気持ちに変わったので通勤中にコツコツ読んでいた。
 やはり、読んで良かった。
 昔から自己啓発系の本は斜に構えている事が多かったけど、これは本の中で書いてある通り、「小手先のテクニックではなく、原理原則に基づいて生きていくにはどうすればよいか」という観点に忠実だった。この観点は、自分が常々「小手先ではなく、根本的なスキルを身につけたい」と思っていた自分の感覚ともマッチした。

 読みながら、心に留まったことや記述を受けて考えたことを手帳に書いてた。くれぐれも、これはサマリでも新解釈でもない。つまり、誤読した結果もここに書くことになると思う。

4/1

人との接し方や生き方について「個性主義」と「人格主義」の大きく2つのパラダイムがあって、
7つの習慣では「人格主義」の方に強く焦点を当てている
4/3

一方的な依存ではなく、自立し、その上でお互いに「依存」しあえるような関係になる

(第一の習慣について)
主体性とは、インプットに対して反応を自分で選択すること。そしてその反応に責任を持つこと。
4/5

(第一の習慣について)
主体性の本質とは「決意」し「約束」し、それを「守る」ことだ

(第二の習慣について)
「終わりを思い描くことから始める」というのが、
アジャイル開発におけるDoD(Definition of Done)と通じるものがある気がする
4/10

(第二の習慣について)
イメージを膨らませてあるべき姿やゴールを想像することを「知的創造」と名付ける。
これは具体的に現実世界に反映させる「物的創造」と名付ける創造活動より先に行われるものだ。
この知的想像を文章に変換したものが「ミッションステートメント」と呼ぶ宣言文となる。
(つまり、ミッションステートメントを遂行することは第一の習慣である「主体性」に紐付いていく)
4/16

(第三の習慣について)
時間のレバレッジを利かせる。
重要かつ緊急なタスクに追われるだけでは疲弊していく。
重要だが緊急ではないタスクの時間を確保できるようなスケジューリングを行う。
スケジューリングの際、自分が被っている帽子(=ロール)に応じて第二領域の時間を確保することを念頭に置くこと。
重要でないタスクに時間を割かないように、振る舞い方を工夫する。
「ロール」は、自分作成したミッションステートメントと関わっている
4/20

(第四の習慣について)
信頼口座を潤沢に
4/22

(第四の習慣について)
「信頼の預け入れ」とは
- 誠実さを示す
- 小さな気配り
- 約束を守る
- 理解する
- 期待を明確に
- 悪かったら心から謝る
4/24

(第四の習慣について)

内的な思考パターンと外的な行動パターンは採用の方法が少し違う。
思考パターンは原則を重視し、行動パターンは相互の関係が良好になるように動く。

リーダーシップとは何か、というと、Win-Winの原則に忠実に、
議論やコミュニケーションを恐れない、そして妥協点なり第三案を受け入れる、ということだろう。
5/1

(第一〜第三の習慣を振り返って)

行動を変える→どうすれば行動が変わるか考える→考え方を変えるにはどうすればいいか考える
みたいに読み替えられそう

(編注:このメモは精度が粗くて、
当時は第三の習慣に向かうにつれてどんどんインナーに向かっているイメージがあった。
今はそうは思ってなくて、自立の為の心技体のようにイメージしてる。
第一の習慣は主体的な行動なので「体」、
第二の習慣はDoDをイメージするので「心」、
第三の習慣はDoDを遂行するための取捨選択なので「技」、
とそれぞれ言えると思う)
5/7

(第五の習慣について)
傾聴の話、自分は果たしてできてるのか?
共感することでお互いに冷静になれる。
感情的なやり取りには、自分が寄り添う
5/10

(第六の習慣について)
シナジーは、自分の意見を取り入れてもらうことではなく、
互いに思いもしなかったアイディアにお互い納得することだろうか

(第七の習慣について)
(乳幼児の)子育て中の人って、運動の時間をどうやって確保してるのか?
5/11

(第七の習慣について)
肉体:
運動して鍛える
精神:
心の動きをある程度コントロールする術を身につける
またレジリエンスを高める
知性:
日々勉強。。。?
社会・情緒:
外部とのつながりや共感

 あとがき的なセクションで、著者ですらすべてを完璧に実践し続けることはできない、と書いていたのがとても印象的だった。身につけることがゴールではなく、より良い人生になるように自分のあり方、振る舞い方をほんの少しでも変えていくように日々考え続けることに意味があるのだろうと腹落ちした。

このGW中に読んだ本

 このGW中は、なんか「チーム」というのがキーワードになってたように思う。
 最近特に、個人で取り組むことにある種の現界や物悲しさを感じるようになってきて、自分の意識や取り組み方を(先ずは)少数の集団構成である「チーム」にどうやって押し広げていったらよいかを考えることが増えてきた。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 Team Geekは実は読んだことがなくて、HRTという言葉しか知らなかった。読んでみて、

  • 個人に対して
  • チームに対して
  • 上司(チームリーダー)に対して
  • 不和のチームメンバーに対して
  • 組織(チームより大きな括り)に対して
  • ユーザに対して

 HRTを軸として、それぞれボトムアップで、誠実に対応しながらやるべきことを進めていくための実践集だと感じながら読んでいた。一般的な組織論ではなく、もっとプリミティブなレベルでのプロトコル集と言ってもいいかもしれない。敢えて突っ込んだ言い方をすると、良くも悪くも、ソフトウェアエンジニア一辺倒な人が手っ取り早くチームや組織と歩調を合わせる為のhackishな手法ではある。が、右も左も分からない自分みたいな人にとっては、形だけでもそこそこな振る舞いができることが期待できるので、とても有用に感じた。特にグッときたのは第4章で、有害な人を排除するのではなく、有害な振る舞いを排除する、という趣旨を読んでハッとした。自分の視座が低いせいもあり、ついつい振る舞いとその行動を起こしてる人間を繋げて考えてしまうことが多いので、絶対にこの思考は改めなきゃ、と自分に対して危機感を感じた。
 5章以降、読み進めるのにだいぶ心理的な負荷が高かったが、多分それは自分がこの視点まで上がってないんだろう、というのが何となく分かる。
 そういえば、個人レベルから段々視点を上げていく構成は、「エンジニアリング組織論への招待」でもそうだったな。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

 THE TEAMは、単純に広木大地先生がオススメしてたので読んでみることにした。
 チームが成功するのに必要な要素をA,B,C,D,Eの5つにうまくまとめた上で、その各要素は手法がいくつかあり、それぞれトレードオフがあるので一概に特定の手法に対して否定ないし肯定するのを断定すべきではない、というのがよくわかった。チームの特性や事業フェーズによって、どの手法を採用するかは様々に変わるだろう。
 これをある程度読み進めたところで、いざ自分の所属チームはどういう手法が合うんだろ、と考えたとき、そもそもチームの分析がある程度できてないと何もできないな、と痛切に感じてしまった。が、チームの分析が出来て理解が進めば、それだけでもチームにとって大きな前進になることは間違いないだろう。そしてまたTHE TEAMに立ち返り、to-beを明らかにした上でどの手法を取捨選択するのが自分たちのチームにとって最も効果のある手法なのかを確かめればよさそう。

 GW明けに、早速実践できることや試してみたいことが色々見つけることができた。

育休をもらっていました

 2/13に娘が産まれ、翌週から1ヶ月育休をいただいていました。 控えめに言って、娘がめっちゃかわいい。よく泣き、よく眠り、よくミルクを飲み、日々少しずつ成長しているのを感じます。
 SmartDriveというベンチャーに入社して半年も経ってないですが、育休を快諾していただいた社長に感謝したいです。また、自分が抜けている間にタスクの肩代わりや分散をしてくれたチームメンバーにも感謝します。

育休所感

 産院からの退院に合わせて、僕も妻の実家にしばらく居候させてもらうことにしました。事前に友人たちから様々なアドバイスをもらったり、インターネット上の記事を読んだりしたので、少なくとも最初の一ヶ月でどれだけ妻と同じことができるかというのが重要っぽいのがわかったので、ひたすら率先して娘の面倒を見ていました。おかげで、最初は抱っこから始まり、おむつの交換、ミルク作り、寝かしつけ、沐浴と、多分母乳をあげる以外のことは一通りスキルが身についたように思っています。これでようやくスタートラインかな、と。
 また、妻の実家にお世話になったので、僕ら夫婦は妻の体調の回復と娘の世話にある程度集中でき、特に食事面については義理の両親にサポートしてもらえたのはとても助かりました。

 よく聞く話として、授乳を3時間おきに行わないといけないので夫婦ともに寝不足になる、というのがありますが、娘はもともと大きめに産まれてきてくれたというのもあり、夜中はよく眠りますね。ただ、生後一ヶ月以内は4時間以上間隔が開くと騒ぎ出していたので、そのタイミングで妻ともどもむくっと起き、オムツ交換をした後、妻は母乳を含ませ、僕はミルク作りを行う、という分担作業をしていました。夜は22~23時頃布団に入り、朝は8~9時から活動を開始していたので、5時間以上連続した睡眠は取れないものの、あからさまに寝不足でフラフラするということはありませんでした。ただ、じわじわと体力が削られてる感覚はありました。ただ、単に僕がほぼ24/7体制で部屋の中にいたので、体力が落ちただけなのかもしれません。

仕事との距離のとり方について

 育児に専念すると当然ながら仕事する時間がなくなる、という話を聞いていたので色々覚悟していたのですが、いざ産まれてみると、寝かしつけに成功すれば多少時間的な余裕ができるので、そのタイミングでできることはあるなと感じました。が、これはあくまで娘が(いい意味で)思ったほど手がかかってないというだけで、もっと要求レベルの高い赤ちゃんはいるはずですので、この感覚を一般論にするつもりはありません。
 育休期間全体を通して、会社のSlackは遅くとも1日以内に追うことができ、おおよその動向のキャッチアップはできていたと思います。育休終盤では、オムツ替え、ミルク、沐浴のタイミングでなければほぼリアルタイムに追ってました。最初の2週間くらいの間は、仕事するのもアレかと思ったので、会社のプロダクトの開発環境を改善するためのツールを書いてました(GitHub - taiyoh/toyhose)。これ結局育休期間中には完成しなかったなぁ。。。Clean Architectureを意識して書いてる分にはよかったけど、トランザクションを分割してsagaパターンとか段々細かいところに目が行き始めるあるあるパターンに陥ってますね。とりあえず「エイヤッ」と作るだけ作らねば。最後の2週間は会社でリリースしてる機能の一大リファクタリング構想を練っていて、コンテキストマップやコンポーネント構成を決めたり、ロバストネス図を書いてました。これでよりリファクタリングの際の方向性が鮮明になったはず。また、この期間中にパフォーマンス絡みの障害が発生してたのですが、原因はすぐに特定できたので、そのためのPRをサクッと作ったりしていました。

普段使っているミルクやオムツについて

 ミルクやオムツは、実は産院が用意してくれていたものからあまり変えていません。
 ミルクについてですが、もともと母乳育児にこだわるつもりはなかったのですが、特に生後1ヶ月までの間は母乳よりミルクを欲しがっていたのと、特に産院側で用意されていたビーンスタークで嫌がる素振りもなかったので、継続して自分たちでも購入しています。

 これ、Amazonよりも赤ちゃん本舗の方がずっと安いですね。使い続ける理由は割と消極的なんですが、そもそも他の粉ミルクも試供品もらってるのに、全然試してませんでした。ただ、ビーンスタークより味が濃かったり甘いものは、いくら安くても選択しないかも。
 オムツは、産院側で用意してもらっていたのはメリーズでした。その後一時的にパンパースにしていたのですが、新生児サイズからSサイズに切り替えるタイミングでメリーズに戻しました。正直なところ、メリーズとパンパースで比較してどちらが肌触りがいい、みたいなのはわからないです。夫婦揃って感覚が鈍いだけなのかも。ただ、この2つが他にためしたオムツより使い勝手やおしっこサインの視認性がよかったと感じました。  哺乳瓶は、当初はピジョンのスリムタイプを使っていましたが、生後三週間を過ぎて、ニプルの穴が新生児用だと小さすぎて授乳に1時間かかるようになってしまったので、慌てて1ヶ月用のニプルがある「母乳実感」のシリーズに切り替えました。  このシリーズのボトルは、プラスチックもガラスも耐熱性が高いのか、スリムタイプより冷ましづらくなっていますね。ただこれは仕方ないか。
 一応、スリムタイプ用のMサイズのニプルも買っているので、どこかのタイミングで試してみたいなとも思っています。

育児本について

 多分妻は当初からあまり育児本関連を買う予定はなかったと思います。が、元同僚のバズった記事をみて、「これは買おう」と説得しました。

srdk.rakuten.jp

 この本は妻も時々読んで娘の状態を確認したりしてるようです。
 あと実は、僕は以前から「考える生き方」という本を読んでいて結構感銘を受けたものがあったので、「シアーズ博士のベビーブック」も出産直前に購入しました。

考える生き方

考える生き方

完全版 シアーズ博士夫妻のベビーブック

完全版 シアーズ博士夫妻のベビーブック

 育児本を2冊も持っていてどうなんだ、という気持ちもなくはないですが、カラーでハウツー的に何かを知りたい時は「はじめてママ&パパ」の方を読み、もうちょっと科学的というか、数字を使って詳しく知りたい時は「シアーズ博士」の方を読むようにしています。これに加えて産院の助産師さんや保健師さん、妻の友人である先輩ママ達から色々なアドバイスももらえるので、育児方法については網羅的ではないにせよ、ある程度俯瞰的に見ることができる環境にあると自分では思っています。

育休明けのお役立ちグッズ

 育休明け前から自宅に戻り、徐々に自分たちだけで回していく生活がスタートしました。多分このフェーズで要求されてるのは、娘にかかりっきりにならず、娘が満足しつつ自分達も自分の時間を確保するためにできることを探すタイミングなのかな、と捉えています。
 まずは一番時間を占める抱っこについて。我が家では、僕が妻の友人から借りたスリングを使い、妻はErgobabyを使っています。

 ちょっと外に散歩に出る時は妻がErgobabyで抱っこすることがほとんどです。妻はこちらの方が慣れてるらしい。僕は自宅作業する時にスリングで娘を抱っこしています。

 あと、自分の親から「バウンサーは絶対あった方がいい」と言われたので、買ってもらいました。

 使ってみて感じたのは、始終抱っこしなくても、自分たちが食事をする時や用足しをする時に置いておけば、娘も誰がどこにいるのか把握できてちょっとだけ安心できるみたいです。

 我が家は全体的に壁紙含め白っぽい内装なのと、特に動くものがないので、よく娘が暇そうにしてるなと感じていました。なので、電動のメリーを買いました。

やすらぎふわふわメリー No.5820

やすらぎふわふわメリー No.5820

 IPものではなく、ベビーベッドに取り付け可能なものを探した結果これにしました。オルゴールは必ず鳴らなくても良かったかな。このメリーは効果てきめんで、電源を付けて回り始めると娘が食い入るように眺めてるので、これは買って良かったですね。ただ最初の2日間くらいは、興奮しすぎて夜中まで眠ってくれませんでした。。。

 そういえば、聞くところによると弊社内で育休を取得したのは僕が初めてだったようなので、今後も他の社員が気兼ねすることなく安心して子供の成長を見守れるような環境が維持できるように、自分も努力したいと思っています。

DDDとClean Architectureの対応関係について

 まず何より、DDDとClean Architectureそれぞれの指向性の違いを把握しておいた方がいいと思う。
 DDDはアプリケーション層(Clean Architectureでいう「UseCase層」)の内部、つまりドメイン層の表現を豊かにするための手法だと僕は捉えている。ドメイン層の独立性の担保のために仕方なく他のレイヤも大雑把に分割している、くらいに思っておいた方がいい。特にインフラ層とプレゼンテーション層にドメイン層ほどの厳密な説明がないのは、DDDが採用される多くのケースはある程度ドメインが見えてきているほどシステムやビジネスが成熟してきている時が(エヴァンス本執筆当時)多かったので、プレゼンテーション層を作り直すようなリファクタリングはドラスティック過ぎるので、アプリケーション層とドメイン層の再分析・再設計に多くのリソースが割かれたからではないだろうか。
 一方のClean ArchitectureはUseCase層(DDDでいう「アプリケーション層」)の外部、つまりFrameworks&Drivers層とInterface Adapters層までいかにユニットテストが書けるくらい責務を分割するか、というところに焦点が当たっていると僕は捉えている。なので、Entities層の独立性や表現云々ではなく、それぞれの責務に応じて機能の分割を行えば、必然的に各レイヤは独立するだろう、くらいのニュアンスではないだろうか。

 僕は上記のような捉え方をしているので、アーキテクチャや実装方針を話す時にDDDの言葉だけで進めると不明な点がたくさんでてくると思うし、業務を正確に理解する時にアーキテクチャに拘ってClean Architectureの言葉でしか話せないと、深い理解にはつながらないと思っている。それこそ両者は似てるとはいえコンテキストが違うので、似た単語が中にあったとしてもあまり緻密な対応付けをしても双方の理解には大きくは貢献しないんではないだろうか。

 因みに僕はDDDとClean Architectureをどう区別しているかと言うと、機能実装をする時にユースケースはDDDの手法を使って分析・記述して、その外側はClean Architectureを意識した実装になるように心がけている。これなら双方のいいところを残せる上に不明瞭な箇所をカバーしあえるので、精度の高い設計や実装を目指すことができるんではないか、と僕は勝手に信じている。

以下は蛇足。

自作キーボードとDvorakと私

この記事はSmartDrive社員が綴るアドベントカレンダー「SmartDrive Advent Calendar 2018」の13日目の記事となります。

qiita.com

Agenda

  • きっかけは転職から
  • Ergo42を組んだ
  • Dvorak配列へ

きっかけは転職から

9月1日付けで株式会社スマートドライブに入社しました。よろしくお願いします。

smartdrive.co.jp

6月(前職中)、退職の諸々の連絡をして僕の視点からは各方面から割とあっさりと了承してもらったので、意気揚々としておりました。退職はなんだかんだ言って一つの区切りなので、何か自分へのご褒美を買おうかなと考えていたところ、ふと「分割キーボードが欲しいな」と思いつきました。
同時に、転職先のSmartDriveはIoT関連のスタートアップでありデバイスを扱ってることを思い出し、折角なら以前からtwitterのTL上でたまに目にしていた「自作キーボード」なるもので分割キーボードを自作するのが一番エキサイティングではないか!?と思うに至りました。

Ergo42を組んだ

この辺のドタバタはブログ記事を書いてました。

Ergo42を組み立てています(そしてどうやら失敗しています) - taiyoh's memorandum

Ergo42が遂に組みあがりました - taiyoh's memorandum

(本当はHelixも組もうとしていたのですが、ハンダ付けでかなり色々なところをミスってたことに気づき、その後の自作キーボード作成の際の反省とさせてもらいました。すいません><)

実はこの後Fortitude60も組んだのですが、macbook proのキーボード(QWERTY)・Ergo42(Dvorak)・Fortitude60(QWERTY)と3つ平行して使ってみたら頭の中がだいぶ混乱してしまったので、今はメインはErgo42を使用し、ミーティング等で席を離れるときはmacbook proのキーボードを使用しています。
Ergo42はかなり使用感がよく、キー数はがっつり減ったとはいえ必要に応じて追加できる余地があるので、かなり気に入ってます。
また、これを作ったときは僕のハンダ技術がたりなかったために時々接触不良を起こすので、「開腹手術」をしてすぐに直せるのもよいですね。

Dvorak配列へ

10年以上前からDvorak配列自体は知ってましたが、以下の理由から大人しくQWERTYを使っていました。

  • 多くの市販PCやキーボードはQWERTY前提のキー配列となってることが多く、そこを無理やり変えてまでDvorakを採用するモチベーションがなかった
  • ソフトウェア的に配列を変えて、キーキャップに印字されてる文字と出力される文字が違うのは抵抗があった
  • MXキースイッチのキーボードを買っていたので試してみたが、列ごとにProfileが違うため、QWERTY以外の配列に並べるとちぐはぐになった

が、自作キーボードというか同じProfileのキーキャップを使える環境なら、自由に自分の思い通りのキー配列が設定できるため(これはqmk_firmwareの存在も大きいですね)、8月の夏休み期間(有給消化とも言う)に思い切って乗り換えることを決めました。
夏休み中は小さなGo製のアプリケーションを試しに作っていて、そこでGoでのプログラミングの勉強をしていたのですが、Go自体もあまり慣れてないしDvorakもおぼつかないので、かなりストレスフルでした。
が、最初は0.5key/secくらいだったのが徐々に1key/secになり(よくそれで仕事回してたよな、というツッコミはありますが)、最近はやっと内容によっては3〜4key/sec(肌感)くらい出せるようになりました。が、まだ配列に慣れてないっぽく、特に日本語入力時のミスタッチはかなり多いのでそれは改善したい。。。

8月からDvorakを使い始めたので4ヶ月以上経ってるので、Dvorakの感想を。

  • QWERTYでのタイピング時の変な指の移動に気づけるようになった
  • Dvorak自体は英語向きの配列だと思う
    • 英語は -tion , -er , pro- のようにある程度決まった接頭辞・接尾辞の組み合わせが多く、これがDvorakだと打ちやすい
    • プログラム言語は英語ベースのものが多く、打ちやすい。が、日本語は若干打ちづらくなった
    • QWERTYでも高速に打ってる人が多いので慣れの問題はありそう

まとめ

2018年を振り返る

この記事はカヤックOBが綴るアドベントカレンダー「ex-KAYAC Advent Calendar 2018」の11日目の記事となります。

qiita.com

この一年何してたか

  • Lobi Tournament @ KAYAC(〜7月)
  • IoT device platform @ SmartDrive(9月〜)

本記事は技術エントリではなく、一年の振り返りと今更転職報告を兼ねたものです。

Lobi Tournament @ KAYAC

前職で最後に関わっていたのは、PvPタイトルでの大会作成・運営を支援するLobi Tournamentというプロダクトでした。このプロダクトでは2017年3月頃から僕の鶴の一声でドメイン駆動設計の勉強と実践に取り組むことを決め、開発メンバーで当時思いつく限りの手法を試しまくるDDDの大実験場と化していました。

敢えて機能単位でサブコンテキストの分割を行い、コンテキスト間の繋ぎ込みのためのACLの実装方法を試したり、集約を跨ぐが結果整合性が伴えばよい処理はドメインイベントとしてアーキテクティングしてみるとか、IDDD本内の付録以外のことは曲りなりにも手を出してみたつもりです。
プロダクトはLL言語Perl!)なのに同じチームの後輩がinterface的な役割を持ったクラスを定義したことがあり、流石にそれはtoo matchだとは思ったんですが、おかげでオニオンアーキテクチャについて理解が深まったという一面もあります。

あとLobi Tournamentは前年からGraphQLの採用も始め、GraphQLのtype定義とDDDにおける集約はだいぶ親和性高いなぁ、と使いながら思ってました。GraphQLはqueryだけでなくmutationも使っていて、普通にRPC的に使ってました。subscriptionは構想まであったけど手が出せなかった(その前に僕が転職した)です。

何故か最終出社後に「最後に何か話してくれ」と言われたので、Lobi TournamentでDDDやGraphQLを採用した経緯なんかを話しつつ「まず先人たちのレールに乗っかって、その上で自分たちなりの手法や取捨選択をすればいいのでは」という話をしました。
僕自身、DDDに触れるまでソフトウェア設計の守破離の「守」すら知らなかったようなものなので、DDDやClean Architectureのような「前提知識」があると、アーキテクティングや設計時に何かを判断する時に本当に助けになる、ということを身を持って知ることができました。

ただ、何でもかんでもうまくいってたなんてことはなかったです。特にレイヤードアーキテクチャはある程度事前知識がないとキャッチアップが難しく、いくら「ここでこう書いてるようにやればいいよ」と言ってもなかなか思うように進まなかったということは何度もありました。また、僕と周囲のDDDに対する温度感も違っていたりして、独りよがりだということを指摘を受けて今では反省しています。

なお余談ですが、DDDの勉強を始めて半年くらいの時点の知識というか思いの丈を以前エントリにまとめてました。

taiyoh.hatenablog.com

この記事で触れてる某Mカリに行った後輩(というか自分にとっては先生ですね)には今でも感謝してます。
DDDを勉強してある程度自信がついたことで、「この会社でまだ学ぶことがある」から「学びたいことはどこでも学べる」という気持ちに切り替わったというのは、転職に至る大きな原動力になりました。
(転職活動中にとあるDDDを実践してる会社さんに伺って話をしていて「DDDのこと、結構分かってそうですね」と言ってもらえたり、4月に開催されたDDD交流会にて、結構いい感じで他の参加者と話が出来たのが自信になった)

IoT device platform @ SmartDrive

何年か前くらいからぼんやりとゲームや広告とは無縁の事業に関わることに関心を持ち始めていて、IoTもそうした「別の関心ごと」の一つでした。
カヤックだったら何でもできるじゃん」みたいな意見はあるとは思いますが、そろそろ事業部間異動はいいかなー、外の世界も見てみたいなー、という思いが強くなって転職するという道を選びました。去年末からいくつかの転職サイトでの活動を少しずつ始め、お声がけいただいた会社の中から興味の湧いた会社何社かに話を聞きに行き、そのなかで一番お互いに手応えが良く9月に転職したのがSmartDriveでした。

smartdrive.co.jp

SmartDriveではGo(Gin)とRuby(Rails)で事業が展開されています。が、僕はどちらも業務でまともに書いたことがなかったので、正直よく入社できたよな、と我ながら関心してしまっています。

使える言語はマジでこんな感じだったけど見送られなくてよかった〜〜〜〜😂
面接等は終始和やかだったと思っています!

実際のところはオファーを提示される前に体験入社を一日行っていて、そこで実際に動いているコードを触らせてもらってました。そこで出されたお題に対してPRを作るというものだったので、実際のコーディング能力も採用時に把握されています。
体験入社の制度はいいですね。採用側が相手の能力を見ることができるだけでなく、エントリーした側もどういうコードで実装されているのかを確認できるので、入社後に初めてコードを見て「なんじゃこりゃあ!」という事態を避けることができると僕は思っています。そういえば、SmartHRさんでも体験入社の制度が整備されているそうですね。
エンジニア向けの体験入社制度ができました - SmartHR Tech Blog
現職は正直なところ、ここまで至れり尽くせりではないですね。。。ただ、「体験入社」という仕組み自体はもっと広まってもいいのかな、と思っています。

因みに、カヤック時代と比べて生活がどう変わったかと言うと。。。

  • 通勤時間
    • めっちゃ伸びた(1時間半〜2時間弱)
    • 暇なので本読んだりポッドキャスト聞いたりする時間にあててる
    • 早く帰ろうと思ったら満員電車に重なり、遅く帰ると妻にも迷惑がかかるというちょっと板挟み的な状況
  • オフィスアメニティ
    • WeWorkさまさまです!
      • 空調はちょっと残念かも
      • ドリップコーヒー、ティーパックが(ほぼ)飲み放題
      • 蛇口から出る水が恐らく浄水
      • 昼になったらビールサーバーが解禁になる
        • 帰り際に一杯飲んでから、なんてことができる
  • 飯事情
    • そこそこ美味く、そこそこ安い店が多い
    • ただ、僕は普段は弁当。。。
    • 弊社では毎週水曜日はケータリングサービス使って社員数人でのグループランチを美味しく戴いてます
  • 周辺環境
    • 自然が少ないのはもう目を瞑る
    • 会社最寄り駅の御成門駅から見える東京タワーはキレイ
    • 高度成長期以降に建てられた建物が多く、正直あまり面白くない
    • 歩いて10分かからないところにボルダリングジムがあるので、忙しくなければ夜立ち寄ってる
  • 職場の空気
    • 口調が穏やかな人が多いからか、近くで会話しててもそんなに気が散らない
      • 多分、僕はうるさい。。。
    • times文化が強い

いつぞやのグループランチ www.instagram.com

現職でもDDD関連の勉強というか情報収集や実践は続けています。
最近新機能開発に携わっていたのですが、既存実装に影響がないことを条件にClean Architectureの採用をシニアエンジニアに許可もらったので、ドメイン層はDDDを意識してモデリングを行い、RepositoryやUseCase等の層はClean Architectureをだいぶ意識して実装しました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

この新機能実装については、折を見てどこかで触れる予定です。
また、とりあえずこれでGoでドメインモデリングを伴う実装に対して実績が出来たので、まず社内で知見を共有していきたいと思います。

Ergo42が遂に組みあがりました

承前↓

taiyoh.hatenablog.com

問題点の絞り込みと対処法について

twitterに細かく情報をのっけて行く形だとちょっとあれだな、と思ったので、一旦ブログに現状をまとめてみたところ、作者のBiaccoさんに読んでいただくことができました。

実際のワイヤリングはどのようにやったか

f:id:sun-basix:20180727171857j:plain

当初はこのようなワイヤリングで導通させていましたが、いざケースのネジを締めて少し使ってみると、部分的にスイッチの半田が圧迫されるのか、キーが効かなくなってしまいました。 あれこれ考えて、もっと簡素化できる方法を思いついたので、バージョン2のワイヤリングをやってみました。

f:id:sun-basix:20180727172202j:plain

これなら圧迫もなく、無事に全部のキー入力が確認できました!因みにこの黄色いワイヤは、元々はブレッドボード用の硬いジャンパーワイヤですね。持っててよかった。

akizukidenshi.com

そして。。。

慣れないながらもちゃんと打つことができて、感動ですね。。。

キーマップについて

デフォルトのキーマップは、初めて分割キーボードに手を出した自分にとっては結構使いやすかったです。
でもやっぱり、自作キーボードに手を出した以上はもっと自分の好みを反映したいな、と思ったので、以下のキーマップを作成しました。

gist957d0e08b81c69d0c1cdda621f7debc4

当初は7列をフルに使うことを想定していて、妄想ではこういうキーマップを当初想定していました

f:id:sun-basix:20180727211141p:plain

が、いざこれを書き出して打ってみると、1列目と7列目のキーを押すのはだいぶしんどいと気づき、あえなく撃沈。
しばらく色々試していて見えてきたのは、特に僕の場合、意識せずに伸ばせる指の範囲は6列分までだということでした。
これを踏まえ、以下のようなルールを作ってみました

  • Tab, Ctrl, Shiftは内側に、そして左側に1つずつあればいい
  • ESC, LGUIは使用頻度が低いか、Tab, Ctrlとの組み合わせで使うことが圧倒的に多いので外側でいい
  • Dvorak配列も試してみたいので、Dvorakで明確に配置されているキーは必ず上3行の中に収める
  • META / SYMBで記号が打てならそちらに任せる
    • 無理にデフォルトキーマップの全キーを埋める必要はないだろう
  • 矢印キーはvimキーバインドに倣って「←↓↑→」の並びに
  • 手首に近いところにはよく使うキーは配置しない

これらを実際の配列に落とし込んだのが上記のキーマップです。
backspaceを右手親指で扱うというのはだいぶイレギュラーかも。でもまあ、しばらく使っていたら段々慣れつつあります。

qwertydvorakを共存させるにあたり、2点ほど気を付けたことがあります。

  • META / SYMBよりレイヤ番号を低くする
  • config.h#define PREVENT_STUCK_MODIFIERS をつける

hrhg.hatenablog.com

の記事より、定数を定義しておくことでmodifierキーのロックを防ぐことができます。また、dvorakのレイヤ番号をqwertyを配置しているdefault layerの次に低くしておくことで、default layerのキーを引き継げるだけでなく、上のレイヤのキーを利用することができます。なお、上記キーマップではqwertydvorakへの変換ですが、dvorakqwertyに戻す際は、METAからソフトウェアリセットをかければいいようにしています。

ファームウェアへの書き込みについて

自作キーボードを組み立ててる方々はMac使いが多く、Windowsでの情報が少ないように感じたので、自分のやったことと所感を載せておきます。
始めに書いておくと、僕はWSL(Windows Subsystem for Linux)とqmk toolboxを併用しています。
なぜMingwでの環境構築がおススメされているかというと、makeコマンド一発で(make ergo42/rev1:<keymap>:avrdude と入力すれば)ファームウェアへの書き込みまで行うことができるからです。
ただ、僕は諸々の開発環境をWSL上で既に作ってしまっているので、今更Mingwで環境を作り直すのが面倒くさく、こういう方式を採ることにしました。
その場合、 make ergo42/rev1:<keymap> とmakeの引数を調整すれば、WSL内でビルドまではやってくれます。あとはqmk toolboxでのhexファイルの読み込み先をビルド先に指定すればよいです。

最後に

特に僕みたいに初めてまともな電子工作をする人にとって、既製品を買うのに比べてだいぶお金も労力もかかってしまうのは間違いないです。
が、作りきった時の達成感は尋常じゃないですし、自分にとって必要なものだけがまとまっているキーボードというのは格別ですね。
因みにこのエントリは当然ながら、Ergo42+上記の自前キーマップで書いております。書いてるうちに少しずつキー入力の速度が上がってるのがなんか面白い。
いやそれにしても、キースイッチの押し心地はいいし、キーキャップの色は自分で好きなように変えられるし、配列に不満があれば変えればいいし、分割キーボードは肩回りの負担が確かに少ないし、これはちょっとハマりそうですね。。。!