アナログ金木犀

つれづれなるまままにつれづれする

近況

引っ越した

リモートワークが続きそうだったので、思い切って引っ越しました。 五反田から小平市というところに。 正直いいこと尽くし。

  • 部屋が増えた
  • 家賃も減って支出がガクッと下がった
  • 自炊率がほぼ100%になった
  • マンション出た向かいに24時間営業の西友があって、毎日最低2回は通ってる

身内が重症で大変になったけど回復した

もう数年会ってない2歳下の弟が今世間を賑わしてる例の病にかかって重症化してるという知らせがきました。 数日前はやばかったけど、今はもう割と回復してるらしいです。 兄弟仲は世間と比べると決して良いほうではないけど、それでもちょっと自分のストレスというか精神に来るものがありますね。

ストレス耐性低いなと自覚

上記のことや今までのことを振り返ると、自分はストレス耐性が著しく低いなと自覚しております。

今までの行動を振り返ると、ストレスに敏感がゆえにすぐにどうやったら取り除けるか、解消できるかを考えてしまうというか。 それゆえに課題発見力だったり課題解決力は伸びたというか、低い分をそれで補ってきたんだなと。

で、どうしようもない解決できないアンコントローラブルなストレス源にぶち当たってしまうと、わかりやすくしゅんとするというか、何もしたくなくなってしまう傾向があるようで。 あと、大体一日休めば回復する傾向もあるっぽいす。

仕事

なんだかんだ入社して2年6か月たったみたい。

とくに先週と今週にいろんなピークが来てマス。 評価期間だったりインターンだったり、あと新規事業立ち上げワークショップのイベントに参加していてその発表が今週だったり。 そこに弟の件が重なったのはちょっと厳しく今日のテンションは劇下がりだったんですが、一日たったのでテンションも復活してきました。

新規事業立ち上げのワークショップは、正直かなり辛くもあり面白くもあります。 信頼関係の構築もできてない初対面のメンバーで進めなきゃいけない点は特にきつい、が、徐々にまとまりつつあるので面白くもあります。 まぁ本当にやるなら、今まで一緒に仕事してきて信頼関係ばっちりなメンバーでやりたいよねって改めて思いました。 やっぱり人よね。

クラファン

これも先週なのでピークに乗じてたんですが、peaksの技術書出版クラファンプロジェクトに参画しております。 先週月曜に公開されて、無事公開から27時間後の翌日には達成ラインを突破しました。 応援ありがとうございます。

peaks.cc

1か月前くらいかな?それくらいから羊さんと横幕さんと話してきた企画なので、達成が素直にうれしいです。 なんとうか、自分が今まで仕事をしてきた中での一番考えてきたところというか、トリニティセブンでいうところのテーマ的なものなので、命を削って書いていきたいと思っております。

個人開発

だいぶ前に書いたこちらの記事。

note.com

これのアプリを作っております。一部仕様変更だったりがっつりしてるけど。 Flutterでやってます。10月に、できればクラファンの執筆が本格的に始まる前にリリース出来たらいいなと思っております。

私生活

最近めっちゃ散歩しています。 一日に3回くらい散歩してます。 あと自炊するようにもなって、だんだん痩せて健康的になってきてる。良き。

好きなYouTuber

好きなYoutuberを紹介します。見てて癒されるものが好きです。

マッスルグリル

沼から入っちゃいますよね。

www.youtube.com

PFCバランス気にしだすよね。Tシャツ買っちゃうよね。

カジサック

ファミリー系動画に癒されてます。コジサックが好きです。

www.youtube.com

エハラ家チャンネル

こちらもファミリー系動画で、すごく癒されてます。

www.youtube.com

一言

元気です

チームで育てるAndroidアプリ設計

こんにちは、kgmyshinです。 このブログではお久しぶりです。 今回Peaksさんにて、Androidの設計関連の出版プロジェクトに参加することになりました。

peaks.cc

敬愛する横幕さんと私(釘宮)の二人で頑張る予定です。今回は設計の横幕と釘宮ということでお願いします。

(初回のmtgで、おや横幕さんと自分しかいないな?なるほど?????となったのはここだけの話)

思いみたいなものは、プロジェクト概要に書いたのですが、こちらでもざっくり書いていきたいと思います。

思い

最近はAndroidの設計の話はだいぶ落ち着いたかなと思います。 カンファレンスでもみかけはするものの一時期よりも枠は少ないでし、PeaksのAndroidアプリ設計パターン入門から数年もたっているわけです。

落ち着いたし、ある程度各現場での導入は完了したのかと思えます。 導入できれば、ある程度の品質や生産性の向上が見込めそうです。 が、自分の観測範囲では実際はそうはなっておりません

導入しようにもどうしたらいいかわからず、またチームにうまく説明できずに導入時点で挫折したケース。 なんとなく導入したけど、導入者含めたメンバーの誰も何が良いのかよく分かっておらず悶々としている現場など、さまざまです。

今回、成立した場合に書く本では設計のことについて話しますが、これが唯一の正解のアーキテクチャだという話はしません。

というか、正直自分は抑えるべきポイントを抑えていればアーキテクチャなんてぶっちゃけなんでも良いと思っています。

完成形がどうこうではなくて、その抑えるべきポイントについて書くつもりです。 それはチームだったり、作るものによっても変わってきます。 そしてさらに、抑えるべきポイントを抑えたら、どうチームに浸透させていくか。 そんなことを書けていけたらと思っています。

わかりにくいかもしれない比喩

少し伝わりにくい比喩になるかもしれませんが、例えばチームで一冊の本を書くとします。

何も考えずにそれぞれが書くと、各章の構成はバラバラになってしまいます。 とある人は 「1節 , 2節, 3節」と書くのに、ほかの人は「Ⅰ、Ⅱ、Ⅲ」と書いたり。

「ですます調」で書いてる人もいれば、「だ・である調」で書いてる人もいたり。 そういった本では内容に集中できません。

プログラムをチームで書く場合にも同じようなことが起こります。 そしてそうなってしまうと、コードを読む場合も書く場合も、プロダクトに集中することはできません。

そういうことです(わかりづらいな、これ。。。)

最後に

自分は、今まで新規開発時にテックリードを担当することが多くありました。 加えて、強い人というよりも新卒だったり、普段はAndroidを書いていない人がチームメンバーだったりすることがほとんどでした。 そういった中でどうすればみんなが生産性高くなるか、実力差はあってもコード品質差をいかに少なくできるか、いかにみんながプロダクトに集中できるかを考えてきました。 最近では副業で外部からアドバイスさせてもらう機会も増えてきましたし、現職では横断組織としてより汎用的な何かを考えたり、各事業部に支援に行くことも多いです。

これらの経験を通して得ることができた自分の知見を今回の本に惜しみなくフル投入していくつもりであります。

なにとぞ、応援よろしくお願いします。

peaks.cc

興味あればぜひ買ってくださいませ!!!

改めて、SOLID(+ α)

こんにちは、kgmyshinです。

この記事は DMMグループAdvent Calendar の6日目の記事となります。 昨日は弊社新卒ありかくん( ありかくんの記事はこちら )に引き続き本日は自分の担当となります。

何かしらの技術ネタだったりを仕込みたかったのですが、時間がなかったのもありまして、今ちょうど作っているSOLID+α原則研修そのものと一部コンテンツの紹介の場とさせてください。 こういう社内研修をやろうとしてますよ、やってますよという宣伝です。

内容としては、N番どころじゃない煎じですが、それでも世間一般に出回ってるコンテンツよりもわかりやすいものを目指してたりはするのでチラ見してもらえると嬉しいです。

f:id:kgmyshin:20191202185653j:plain

本研修では 座学 -> 個人ワーク -> グループディスカッション という流れで行う予定です。

研修のスコープは「SOLID 原則 + CQS原則 + DRY原則です。 ターゲットは「これらを知りたい方、復習したい方」で、研修のゴールとしてはこれらの原則を理解してもらうことで普段の設計・コーディング・レビュー時の質が上がることとしています。

スライドは全部で130ページほどあり、ここでは一部の紹介となりますが、おいおいスライドの外部公開もするので興味ある方はもう少しお待ちください。

参考図書

参考図書は以下になります。

原則の解釈にオリジナリティが出ては困るので、自分でも改めてSOLID原則の章をいくつかの資料で確認しながら作っています。

日程感

(1.5時間~2時間)×2日間 の合計3~4時間となっています。

  • 1日目
    • SRP(単一責務原則)
    • ISP(インターフェース分離の原則)
    • DIP(依存関係逆転の原則)
  • 2日目
    • OCP(オープンクローズド原則)
    • LSP(リスコフの置換原則)
    • CQS(コマンドクエリ分離の原則)
    • DRY(Don’t Repeat Your Self原則)

SOLIDの順番にはしていません。

f:id:kgmyshin:20191202190546j:plain

コンテンツ覗き見

早速いくつかのコンテンツを覗き見してみましょう。

OCP(オープンクローズド原則)

スライド 説明
f:id:kgmyshin:20191202190037j:plain:w300
f:id:kgmyshin:20191202190111j:plain:w300
f:id:kgmyshin:20191202190318j:plain:w300 まずはよくあるOC原則違反の例を示します。
f:id:kgmyshin:20191202190328j:plain:w300
f:id:kgmyshin:20191202190336j:plain:w300
f:id:kgmyshin:20191202190345j:plain:w300
f:id:kgmyshin:20191202190351j:plain:w300 OC原則を守った場合、修正範囲が新しいクラスだけであることを明示し、この後にどうこのクラス設計を導くのかについて軽く触れます。
ブラッシュアップ中なのでスライドは省きますが、SRPやDIPに従ってクラス設計していくことでOC原則を満たすコードが書きやすくなることを説明します

DRY(Don’t Repeat Your Self原則)

DRY原則は誤解も多いのでその誤解をまず解きつつ、またやりすぎてしまう例にもしっかり触れるようにしました。

スライド 説明
f:id:kgmyshin:20191202193935j:plain:w300
f:id:kgmyshin:20191202193942j:plain:w300 誤解が多いところなのでしっかり触れておきます
f:id:kgmyshin:20191202193957j:plain:w300
f:id:kgmyshin:20191202194007j:plain:w300
f:id:kgmyshin:20191202194015j:plain:w300
f:id:kgmyshin:20191202194022j:plain:w300
f:id:kgmyshin:20191202194040j:plain:w300 コード重複の例にも触れておきます
f:id:kgmyshin:20191202194049j:plain:w300
f:id:kgmyshin:20191202194056j:plain:w300 重要なところです
f:id:kgmyshin:20191202194104j:plain:w300 DRY原則を守りすぎることで辛くなる例に触れます
f:id:kgmyshin:20191202194112j:plain:w300
f:id:kgmyshin:20191202194121j:plain:w300
f:id:kgmyshin:20191202194128j:plain:w300 SRPなどを重視しつつ、バランス見てDRYしていきましょう

その後

上記のような座学をやった後に、実際にクラス図を書いてもらったり、原則違反をしちゃってる例を修正してもらう個人ワークを行います。 その後、(なるだけ)普段一緒に働いてるチームメンバーな参加者とグループになってもらい、個人ワークの解答をそれぞれ見せ合っては解釈をチームの共通認識に落とし込んでいくという流れになっております。

所感

まだコンテンツ作り中なので、こういう例題あるといいよねみたいなのあればシュッとtwitterとかで投げてもらえると嬉しいです。

余談

自分のTシャツも登場させました

f:id:kgmyshin:20191206113631p:plain f:id:kgmyshin:20191206113635p:plain

明日は 弊社新卒 slme くんの技術ポエムがあがるそうです。 内容は聞いてないですが、私、とても期待しています。

「どれだけ近づいたのかな?」

こんばんは。

この記事は SHIROBAKO Advent Calendar 2019 二日目の記事です。 2015年からこのアドベントカレンダーを初めて今回で5回目です。続いてて良いですね。

最近は来年の映画でのエマの生活水準が向上しているのかどうかが気がかりな毎日です。(公開された動画を見る限り、はっきりとはしないけどどうやら向上してそう?)

個人で何かを作ったりみたいなものを除いた、会社で働くものとしてのキャリアパスを考えると結局は会社があなたに「どこまで何を任せられるか?」になる気がします。責任と言ってもいいのかも。

で、クリエイティブに身を置くものの場合は、大抵は次の式が成り立つような肌感を持っています。

責任 = 技術的難易度 × スコープ

他にも信頼残高とかいろんなパラメータがあると思いますが、一旦これで。

そういう自分も次のようなステップを通ってきました。

途中Androidアプリ開発以外もやってたので端折ってますが、概ねこういう感じでスコープがどんどん大きくなってきていることがわかります。 最近は次のようなことにチャレンジしてます。

  • 自分抜きでサービス開発において自立した状態をつくることができる
  • 会社全体スコープで特定領域(成長・育成等)においての課題解決できる

自分がSHIROBAKOで大好きな二人はどうでしょうか。

宮森あおい

宮森あおいは作中次のようなステップを踏んでいます。

  • 1話の進行を任せることができる
  • 最終話の進行を任せることができる
  • 制作デスクを任せることができる
  • (新入社員の世話を任せることができる)

担当スコープが徐々に大きくなっており、キャリアパスを登っていってることがわかります。 すでにナベPにはエースと呼ばれていますしね。 映画でどういったキャリアパスを進めるのか楽しみですね。

安原絵麻

絵麻はどうでしょう。

  • 動画を任せることができる
  • 原画を任せることができる
  • 作画監督補佐を任せることができる

あおいの時もそうでしたが、自分に知識があまりないためステップ数が少ないのはご勘弁を.. 絵麻も着々と、着々とやっていってます。 映画でまさか作監になるってのは...どうでしょうか。

自分が見たい5人の未来

最初の前提のところにちらっと書いた「個人で何かを作ったりみたいなものを除いた、会社で働くものとしてのキャリアパスを考えると」ですが、個人で何かを作ったりを含めるとキャリアパスはぐいっと広がります。 夢もあるあしね。 個人的には、ある程度成長した5人が、仕事の合間に集まって自主制作「神仏混淆七福陣」を作る未来を見たいと思っています。お金があれなら、クラウドファウンディングとかどうですかね。今の時代っぽいし。 でも、やっぱり時間的に厳しいのだろうか。映画での進捗が私、気になります。

「私たち。夢に飛び込んで、夢を仕事にして。でも、七福神にどれだけ近づいたのかな?」

www.youtube.com

映画で進捗はあるんでしょうか。

近況

入社してそろそろ一年半が経とうとしています。 最近霊圧を感じないと言われることもありましたし、そもそも呑み自体を減らしてるのもあって最近会ってないなぁと思う人も増えてきたので、 知り合い向けにここで近況でも報告してみようと思った次第です。

お久しぶりです。

入社した経緯

前職をやめた時に書いた記事を読み直してみました。

じゃぁなんで辞めるのか

若手に引き継いで回った結果やることがなくなったというのが大きな理由です。

自分がやるよりは若手の成長機会や実績にした方がいいよなって思ってたら (いまでもそれは正しいと考えています ) 、

いつの間にか雑務やマネージメントばかりになって技術者としての自分を維持できるかどうか不安になってしまったんですね。

ここには書いてなかったですが、自分は会社全体のAndroidエンジニアのボトムアップとかをやってみたいなぁと思ってました。 その部分に関してはある程度の自信を持っていたのもありまして、そう考えたいたらちょうど今の弊社がそういう人を探していたということで、特によそ見することなく転職することとなりました。

入って1年くらい

Androidエンジニアを探す旅

入社してまずやったことは社内でAndroidエンジニアを探すところから始めました。 外部から急に「レビューしたげるからリポジトリの閲覧権限くだされ」と言っても「だれやねん」となりかねない(少なくとも自分が言われたらそうなる)ので、 知り合いをつてに知り合ったAndroidエンジニアの方々に「困ったら声かけてくださいね」と挨拶して回るみたいな地味なところから始めた記憶があります。 自分が過去に発表した資料だったり、ブログだったり、果ては技術書典でだした本だったりを持ってくれてる人もいて、それらきっかけに逆に話しかけてくれる人もいて、嬉しかった記憶があります。 Androidエンジニアで横断の懇親会とかも開きました。またやろうかな。

アウトプット

またこの時期は「弊社にもAndroidエンジニアいるんだぞ!!!」という意気込みで、より一層ブログ記事を書いたり、登壇したりに力も入れてました。

いろんな開発チームのレビューに参加したり

ある程度弊社のAndroidエンジニアたちと顔見知りになったころらへんから、複数チームのレビューに参加するようになりました。 中のコードをみつつ、レガシーなプロジェクトなどにあたりをつけつつ、どう生産性を上げていくか考えてました。 いろいろ考えた結果、参考になるようなリポジトリを作ることにしました。 Googleの出してる android-sunflower だったり、 Blueprints的なあれです。

これがちょうど完成した頃に Google IOがあり、そこで Jetpack が紹介され全ては水の泡となりました 😇

事業部にガリッとコミット

Google IOから帰ってきてから今年の年始くらいまでは一つの事業部にがっつり入ってました。 そこでは Jetpackガリガリ使ったモダンなプロジェクトとしました。

始めはAndroid側のリードエンジニアみたいな動き方も多少してましたが、自分がいないと回らない状況は目指すべきところではないので途中からは現場Androidエンジニアにバトンタッチして、自分はクリティカルな何かが発生した場合にたまに顔を出すマンとなりました。 最後の方は自分のやることはどんどん減っていって、リリースが近づくほど僕は暇になっていきました。

今となってはもうそこの開発に直接関わってはいませんが、 そこのエンジニアは優秀ばかりで、勉強会で登壇したり、別チームからのAndroidの質問などにも積極的に答えてくれるのですごく助かってます。 そこにいたすでに他チームに移った一人の若手が、先陣切ってコンフルでクラス図書いてしっかり設計したものを、周りの技術者と議論しながら進めているページを発見して、感慨深くなったりしてます。

近況(ここ半年くらい)

とあるチームのリーダーに

ここからがようやく近況です。

最近はとあるチームのリーダーをやらせてもらっています。 自分のチームは一言でいうと「社内改善をして露出を増やして、どんどんアトラクティブな会社にする」ことにコミットするチームです。 いろんなことをやってるので抜けがあるかもですが、カテゴリ的にはこんな感じです。

  • Android(モバイル)
    • モバイルエンジニアのボトムアップ
    • モバイルエンジニアコミュニティづくり
    • アウトプットしたり、促したり
  • 人事の方々との連携
    • 採用に対する課題解決
    • 評価に対する課題解決
  • 技術広報系
    • イベント企画、開催、運営
    • 予実管理
    • アウトプット促す仕組み作り
  • 1on1系
    • チームメンバーと
  • 事業支援
    • 現場のエンジニアで回るように

細かくは話しませんが、たくさんある大きな課題にガンガン体当たりしていってる毎日です。 今までは人事の方々との連携も個別にしかできてなかったのですが、弊チームができたことでより連携もやりやすくなって、イイ感じになってきています。 これだけ見るとエンジニアやってなさそうに見えますが、コードもガリガリ書いてます。それはもう。 特に最近もろもろのピークが重なり忙しくはあるんですが、どれも自分のやりたいことのど真ん中なのですごく楽しくやれてます。 どんどん改善回していくぞ〜〜〜〜

副業

副業先では変わらずAndroid系の技術顧問的なことをさせてもらってます。 大小関わらずに技術的に悩んでるところにアドバイスするのはそうなんですが、こちらでも組織的な課題でサポートできるところを見つけていきたいなと思う今日この頃です。

また、最近はScalaを書けるお話も頂けたのでScalaやっていきなお気持ちです。

個人開発

なるべく帰ってからは少しでも良いので個人開発をするようにしています。

これをガリガリとモノレポなKotin MPPでちょっとずつ進めていっています。 なんか面白い話溜まってきたら、どっかで話しますね。

私生活

実は最近、徐々に痩せてきました。やったぜ。

おわりに

  • なんか似たような事してる人(技術広報とか横断組織とかとか)いたらご飯いきましょ〜
  • 最近会ってない人ご飯いきましょ〜
  • 弊社に興味ある人ご飯いきましょ〜