技術書典5に参加しました
techbookfest.org に行ってきました 数日経ってテンションが落ち着いてきたので、参加レポートとして投稿します
サマリ
- 技術書典に並んでいた本のクオリティは十分に高い
- 実際に現地に足を運ぶこと自体も有意義(モチベーションアップなど)
- 技術書典は素敵なイベント。ありがとう、次回もよろしくお願いします
やったこと
前日まで
- twitterでなんとなく情報を見る
- 勉強会で情報収集 omotesandorb.connpass.com togetter.com
当日
- 技術書典アカウント作成
- 並びながらサークルチェック
- 買う(会場2周ほど)
- 著者や参加者と話す
後日
読む・感想を書く・推す
成果
昨日の成果。あと2冊くらい電子書籍オンリーのものを買ったはず。
— ngmt (@ngmt83) October 9, 2018
薄めの本（写真2枚目）は適度にライトで職場でポケット六法のように使用する予定。#技術書典 pic.twitter.com/9beBIcI09V
事前にぼんやり想定していたよりは買いすぎて驚いたけど後悔は一切ない
所感
- なんかよくわからないけど、乗るしかないこのビッグウェーブに感があった
- 事前のサークルチェックはなくても楽しめる
- 小銭はなくとも技術書典アプリでQRコード後払いができて便利
- 後払いすると購入のリストにもなるのでおすすめ
- 迷ったら買ったほうが後悔は少ない
- 昼過ぎの落ち着いた時間帯のほうが著者と話しがしやすくてオフラインのイベントの醍醐味を味わいやすい
- 既知のエンジニアと久しぶりに会う口実としても非常にいい機会となった
- 著者と話して本買えるって最高だ
- ある程度知っている人が書いた本は読んで血肉になるまでが早い
- 後日BOOTHで販売開始したりするので売り切れはあまり心配しなくてもいい
- やる気スイッチを押してくれる
- 著者・サークルがみんな楽しんで生き生きしてた
最後に
非常に楽しく・実りあるイベントでした。運営・サークル・一般参加者みなさんに感謝します。 次回も絶対参加します。
落ちた企業を名指しで褒める記事
タイトル通り、企業を名指しで褒める記事です。
経歴的にジョブホッパーな筆者が実際に見聞きした企業のうち、
選考で落ちたにも関わらず賞賛したいと思った企業様を褒めています。
本気の「御社の益々のご発展を応援申し上げます」を伝えたいレベルです。
諸注意
- 当記事において意図的な皮肉表現はなく、ただただ褒めているつもりです
- 落ちたくせに褒めるって偉そうだなという印象を受けたらすみません
対象企業について
- 筆者が選考に落ちた・見送られた企業
- 当然ながら実際に働いたことはない
- 選考フロー・媒体は様々
素晴らしい企業
- 株式会社CaSy
- ラクスル株式会社
- 株式会社フクロウラボ
- BizteX株式会社
株式会社CaSy
ざっくり特徴
- エンジニア側との面接、ビジネス側(経営陣？)との面接両方行う
- 面接で被選考者と対等に深く向き合う
- 抱える課題と、これからどうしたいか、どうコミットしてほしいか具体的な共有がある
- 見送り理由が具体的で納得感がある
良かった理由・所感
エンジニア側・ビジネス側どちらの面接も形骸化しておらず、それぞれ独立して判断しているように感じた。
（「最終面接は顔をあわせるだけ」みたいなことはない）
面接においては、選考するもの・されるものどちらが偉いわけでもなく、対等に向き合い、お互いが腹を割って話せるように意識しているように感じた。
腹を割って人と話すとある程度疲れると思うし、実際私はどっと疲れた。面接担当者も同様に疲れただろうし、それくらい力を入れているようだった。
入社した場合に、どう働いてほしいか、どう期待しているかを具体的に共有され、働いている自分をイメージしやすかった。
後日結果とともに共有された見送り理由は、面接においてより深く話し合った内容に関与していて、自分の何が不足していたか、今後改善するための材料となるものだった。
BizteX株式会社
ざっくり特徴
- 面接担当者が面接をお互いにとって有意義なものにするというポリシーを持っていた
- 回答が簡単ではない質問には、どういった意図で聞いたか、自分はこう考えているがセット
- 抱える課題と、これからどうしたいか、どうコミットしてほしいか具体的な共有がある
- 見送り理由が具体的で納得感がある
良かった理由・所感
面接をお互いにとって有意義なものにするというポリシー
これが非常に素晴らしいと感じた。お互いが大切な時間を面接に使用しているという前提で、少しでも実りのある時間にしようとしているのを感じた。
簡単ではない質問は聞きっぱなしではなく、フォローを入れたり、どうして聞いたのかを共有された。
また概念・設計思想などについては、面接担当者自身の考えも聞かせてもらえた。
これらのおかげで、そもそも回答しやすいし、自身の回答を反省できるし、単純に学びがあった。
現在どのレベルでどのポジションの人材を探しているか、どういう働きを期待しているかを具体的に共有されたことで、自分がこれから経験したい領域であるかを判断できた。
また、見送り理由として、あるスキル(領域)に関して期待値に未達であることを具体的に共有を受けられたのがよかった。
自分がやりたいことを任せてもらうために、今何が不足しているかを知ることができたのは非常に大きかった。
株式会社フクロウラボ
ざっくり特徴
- 綺麗事ばかりでなく、応募者の志望度が下がるかもしれない情報も開示する
- 選考速度が早い
- 抱える課題と、これからどうしたいか、どうコミットしてほしいか具体的な共有がある
- 見送り理由が具体的で納得感がある
良かった理由・所感
具体的には記載しないが、綺麗事ばかりを述べるのではない正直な情報共有が非常にいいと感じた。
面接者が選考をお互いにとってのマッチングだと認識しているのだろうと思った。
選考速度が早いものの、なげやりな回答ではなく、具体的で納得感のあるものだった。
ラクスル株式会社
ざっくり特徴
- 技術試験がある
- 抱える課題と、これからどうしたいか、どうコミットしてほしいか具体的な共有がある
- 見送り理由が具体的で納得感がある
良かった理由・所感
技術試験は面接同様に会社に訪問して現地で取り組むタイプで、試験時間はコンパクトにされつつも、いろんな要素が凝縮された試験内容だった。
試験周りのフローもよく練られているように感じた。
（開始前の質問時間や回答後の面接(なぜそう回答したのか?の確認等)など）
筆者は試験時に相当テンパっていたが、フォローしてもらったり、考慮してもらったりありがたかった。
(テンパるテンパらない含めて実力だと思うので、もっと雑に扱われても仕方ない自覚はあった)
採用中のチーム・ポジションが複数あった中、それぞれどういう状況でどういった人がほしいか共有された上で、どこが向いてそうかまで提案があった。
入社後をイメージしやすかったし、具体的な提案があることでテンプレの説明でなく、しっかり見られていると感じた。
気付き
- 抱える課題と、これからどうしたいか、どうコミットしてほしいか具体的な共有がある
- 見送り理由が具体的で納得感がある
はすべて共通していた。
(これらは当たり前に感じるかもしれないが、当たり前を当たり前にできるのはすごいこと)
具体的な課題と期待を共有した上で、納得感のある判断ができると良い選考なのだと感じた。
また、そういった良い選考からは学びが多く、成長の糧を得ることができた。
そして、その場合には仮に残念な結果になったとしても、
「見送られたことが悔しい以上に良い選考だったし、成長の糧を得ることができたし、いい企業だな！」
と感謝と尊敬ができると気付いた。
総括
当記事に記載した企業は素晴らしい選考を行う、尊敬できる良い企業
「表参道.rb #38 〜Railsアンチパターン〜」 レポート
表参道.rb #38 〜Railsアンチパターン〜 - connpass
こちらのイベントに参加してきたので、レポート書きます
※遅刻参加だったのと自分でLTしたのでメモとか少なめです
イベントの雰囲気・参加者
穏やかな雰囲気で非常にいい
LTの前に軽い自己紹介などして場づくりをしていたらしいです
素晴らしい取り組みですね
(遅刻参加だったのでよくわからないですが)
参加者はruby, Rails界隈で超有名人が複数人と
新米エンジニアを卒業したくらいの人と熟練者とどちらもいた気がします
会場提供の株式会社ビジネスバンクグループ様ありがとうございます
LT
質疑や口頭など気になったところをメモとして追記しています
※発言者≠発表者
xxx
途中参加＆メモ不足です
クエリビルダークラスを作ったみたいなお話をしていました
発表者の方にはぜひ資料あげていただきたいです！
Form Object へ捧げる気持ち
メモ
- 複数の責務を持たせられがち
- ARから離れたのに複数の責務持ったclass作らなくてよくない？
- 小クラス主義
before action setter いる？
メモ
- 関心がわかりにくい
- before actionを書かせない方法としてカスタムrubocopで弾く
- rubocopはなぜNGかの理由が伝わりづらいので、wikiなども併用する
default scope
「表参道.rb #38 〜Railsアンチパターン〜」の発表資料 (1枚絵) です。 #omotesandorb pic.twitter.com/sw4mh8KInX
— Koichi ITO (@koic) 2018年9月6日
メモ
- default scopeと削除フラグはズッ友
- メリットはないこともない
- DBの特性に対応させるために用いたもので、本当にdefaultである良い例はあった
レールに乗った開発 (※うろ覚えです)
待ってます！PCが不調だったので、後でブログで簡単にまとめる（たぶん #omotesandorb
— 神速 (@sinsoku_listy) 2018年9月6日
メモ
- 「LT枠しか空いてなかったからLT枠で参加」
- Railsが難しいのではなく、WEBアプリが難しい
- Railsを開発している特定会社の知見が汎用化されたものがRails
- 特定会社以外で動くのは運
- GitHub - rails/rails: Ruby on Rails見よう
- version up対策として、動向チェックしよう。公式が難しいならサマリもいいよ*1*2
- version upを見越して、メモ書き・拡張して先回り実装・cherry-pick
ActiveRecord scopeアンチパターン
わたしです
^o^
speakerdeck.com ※発表資料ブラッシュアップしました
メモ
- Arelはアレルって読む
- DBパフォーマンス改善はARでない箇所で別のアプローチを検討したほうがいい
- scope命名難しいけど、一意性のある名前を頑張って考えよう
ActiveRecordで複雑なクエリを書くのは間違っているのか
www.slideshare.net *3
メモ
- 4MBのSQLを投げたら、デフォルトだとエラーになる
- SQLを丁寧に考えた
- find_by_sqlはRelationが返らないのでNG, scopeは実現がきつい、Arelも推奨されてはいない
- Arelで書いてみた・・・やっぱ読むの難しい
- whereに配列を入れるのはINで展開されるから要注意
所感
初LT楽しかった
— ﾅｶﾞﾓﾄ@Glideエンジニア (@ngmt83) 2018年9月6日
LTすると話しかけてもらえるから、LTは人見知りのソリューションになりうるという知見を得た
運営さんありがとうございましたm(_ _)m#omotesandorb
- OneTabというエクステンション教えてもらったのありがたかったです
- 話盛り上がったけど、名前聞いてなかったせいでフォローとかできないのは失敗
*2:https://www.pixiv.net/fanbox/creator/7127248
*3:9/10 資料を公開いただいたので、追記・編集しました
私はこんなやつです
何か意見を述べるときに、自分がどういうポジションか明らかな方がいいな
と思ったので、自己紹介的な記事を書きました
一言で言うと
田舎出身の転職回数多めなエンジニア
出自
- 田舎者界のサラブレッド
- 大家族
- 島人
新卒・就職まで
パソコン好きだから情報系
留年しそうで就活する暇なくて大学院進学
よくある大学の推薦で大手SIer
なあなあな進学就職の典型
社会人としての今まで
大手SIer -> web系 -> 上場済みweb系 -> web系
前向きな転職・逃げのような転職色々
1つの転職を捉えても両方の要素があった
引き止め・お叱り・忠告などの言葉は間違ってなかったし、自分が考えた辞める理由も間違ってなかった
転職すると年収が上がるバグ*1にのっかったジョブホッパーの典型
目標
高い水準で技術力•人間力•ビジネススキルを備える人材
有り体に言えばCTO
理由
自分が天才ではないと知っているため、スペシャリストの道は選ばない
技術面ではT字型人材を目指す
ときおり高い能力・技術を活かせない人をみる、それが惜しいと感じるため、
それらを生かすチーム・仕組みを作り、ビジネスに社会に貢献したい
尊敬している人
- カック@カカカカック/吉田慶章 (@kakakakakku) | Twitter
- willnet (@netwillnet) | Twitter
- Takuto Wada (@t_wada) | Twitter
- Junichi Ito (伊藤淳一) (@jnchito) | Twitter
所感
事実ベースで書くと我ながら迷走してるけど、どんな選択もそれが正しかったと言えるように努力すればそれでいいかなと思う
あと過去を振り返る際に、高校時代に運営していたブログを久しぶりに見たら、総アクセス数が50万を超えてて、
「過去の俺捨てたもんじゃないな」と思えたからこの自己紹介記事書いた意味があった
*1: 転職すると年収上がるバグがあるせいで意欲がなくても転職せざるをえない現実よなエンジニア年収800万の壁
b.hatena.ne.jp
「Meetup in Tokyo #44 -Agile2018 Conference 報告会-」にいってきました
line.connpass.com
こちらのイベントに参加してきたので、まとめました
横文字が多く、自分自身ハラオチさせるため、私の解釈・所感も含みます
※誤っていればご指摘ください
タイトルにある通り、イベント内容はAgile2018 Conferenceの報告会でした
詳細はconnpassのページに記載されています
全体の傾向・サマリ
OutputよりもOutcome
プロダクトを高めるのみではなく、
市場へ提供する価値や、ビジネス的インパクトこそを最大化すべき
ブレイクダウン
ビジネスのスピードを高めるため、
- 経営層までAgileを適用していく
- CI, CD(Continuous Delivery)対象を試行錯誤しながら増やし、価値を生み出すことに集中する
- 多くのMetricsが確立され、選択に有用な実践データが集まりつつある、それを利用する
Agile Conferenceへの誘い
- Agile Conferenceはタフだけど楽しい・おすすめ
- 開発側からビジネスのAgile化に踏み込む余地がある、滾るでしょ！
- 実践例なかったし、実践して輸出しよう、牽引しよう、セッションに応募しよう
- セッションの倍率は5倍。いけるやん！みんな応募しよう
- 次はAgile2019 Conferenceで会いましょう
- そういえば年1回海外カンファレンスに行ける会社があるらしいな〜（宣伝）
スライド
This is a flash report of Agile2018 by The HIRO!
@hageyahhoo さん
Data & Metrics in Agile2018
@martin_lover_se さん
※追記: 参照すべきスライド間違えていたので、訂正致しました
Make Work Visible in Agile2018 #LINE_DM
@PoohSunny さん
speakerdeck.com
How can this change you? Agile2018 report
@ykmc09 さん
※追記: スライドを公開いただいたので、追加しました。また、正式なタイトルを確認できたため、更新しました
気になった箇所・所感
- 納期遅延はいつもスタートが遅いせい
- 依存によって指数的に遅れが生じる
- Conferenceにいって1 on 1してもらうのおすすめ
- Agileの価値観・原則を教えるのは難しい
- 人によって効果的な学び方が違うため、いろんなワークショップを試し、よりよいワークショップを見つけよう
- カイゼンジャーニーいいぞ
- VARKで自分の傾向を知ろう
- アトラシアンが無料公開しているTeam playbookがチーム状態を可視化してくれる
- Conferenceに真新しいことはなかったが、粘り強くやっていくことに価値があると感じた
-> チームやメンバを否定しないように比較するの難しそう
- Devチームとしてagileにうまくやったと思っていたが、ビジネス視点ではそうでもなかった
- 開発のみでないリードタイム、フロータイムを計測しよう
-> 視野が広い。まずはDevチームとしてうまくやることが当面の目標だけど、いずれ挑戦するために頭にいれておく
- Training From the Back of the Room!みんな読んでるらしい *1
-> 英語版しかないんですかね。。。日本語情報求む
- チームの条件によるパフォーマンスの定量比較
- itaration length: 2週間がよいバランス(長いと品質が高く、短いと生産性が高い)
- controlling wip: 基本的に減らした方がいい
- team size: 7±2人がよい(小さいチームは生産性が高いが、品質は低い)
-> 初心者なのでスクラムを実践する際には大いに参考にしたい
今後やること
- 一押しされていたセッション資料*2を読む
- @ChristophLucian さんのブログを（探して）読んでモブプロについてざっくり学ぶ
- Metricsの理解がふんわりしているのでこの資料*3をハラオチさせる
- VARKアンケート*4で自分の傾向を知る
- Team playbookを一人でやってみる
- カイゼンジャーニー*5 読む
おわりに
LINE株式会社様が会場提供してくださいました
つい呟いてしまった通り、素敵なオフィスでした
https://t.co/8RHbe82uBe
— ngmt (@ngmt83) 2018年8月28日
綺麗ですごいオフィス（こなみかん）#LINE_DM
omoiyari.fm おすすめです lean-agile.fm
「超スピード文章術」を読みました
勝兵は先ず勝ちて而る後に戦いを求め、敗兵は先ず戦いて而る後に勝を求む
孫子の一説です 「超スピード文章術」を読み、 著者が伝えたいことは、この有名な一説と概ね同じだなと感じました
読んだ本
読んだ理由
勉強する前に、勉強法の勉強をするのと同様に、 アウトプットを継続させるために、文章を早く作成する方法を勉強しようと思い、この本を読みました
本の内容
サマリ
書く目的を理解し、読者を定め、魅力的な素材を集めた上で、一気に書いてしまうと早く書ける
目的と読者設定
表面上の目的ではなく、真の目的を理解する 読者となるペルソナを決める（難しければ知り合いで1人設定する）
目的の理解と読者の設定ができると正しい素材集めが捗る
素材集め
素材とは、独白の事実・エピソード・数字のこと 多く集めてあとで削るが基本 単純にひらめきをメモする
自分の感覚も素材となる 自分が体験したことは完全にわかっていることだから、スラスラ書ける
一気に書く
素材が揃っていることは大前提 推敲する前提でまず書ききる 細かい確認は後回し 書きながら途中で止まったら一気通貫に読める文章にはならない 多く書いてあとで削る
所感
書ける状態を作ってから書く この一言集約されていて、勝つべくして勝つという孫子の一説と似ているし、システム開発でいうウォーターフォール的な書き方だと感じました
全体的に、うすうすわかってはいたことをしっかり解説してくれた本でした それゆえにどんどん頭に入ってくるし、サクサク読めるので、いい本です
個人的ポイント(引用ではないです)
- かっこつけないでいいし、構えなくていい
- 伝えたいことが、伝えられればいい
- 完璧主義がスピードを落とす
-> 身に覚えがありすぎる スピードを落とすどころか投げ出すことすらありました（Qiitaの下書きが溜まっている・・・）
- 自分にとってのいい文章を定義する
-> @jnchitoさん、@kakakakakkuさんでしょうか おすすめです give IT a try kakakakakku blog
- 素材のストックはメールの下書きが最強
-> 私はgoogle keep派です！
- 誰も積極的に文章を読みたがっていない
- 書き出しがつまらないと読まれない
- 書き出しだけは作家に学んでもいい
-> かっこつけないでいいのではないのか・・・ ぐぬぬ、書きながら学びます
- 子供の作文を幼稚に感じるのは形容詞ばかり書いてあるから（楽しかった、嬉しかった）
- 形容詞は伝わらないばかりか、思い浮かばないことすらある
- 形容詞を使わないと決意すると素材に注目できる
-> 確かにと衝撃を受けました 形容詞には注意して、本質である素材に目を向けたい
- 目の前に読者がいるとして、喋るように書く
- 喋るときは自然と結論から話してるよね？
- 目の前の相手のために組み立てると、その人への最も良い論理が生まれる
-> なるほど、ラバーダッキングとも似てる気がする
- 文章が堅いは意味がわからないと同義
->難しい言葉知ってるぜ、どやぁ とか思ってました、反省します
最後に
もっと納得がいく解説があることはもちろん 素材集めのコツや、一気に書ききるために気をつけること、書くことへの苦手意識を克服できるようなアドバイスも本書には書いてあるので、 書くのが遅かったり、苦手意識を持っている人はぜひ読んでみてください
第20回 Scrum Masters Night! 参加レポート
第20回 Scrum Masters Night! に参加してきたので、そのレポートです。 https://smn.connpass.com/event/94001/
※スマホでざっくり書いたメモをベースにしており、精度は低めです
イベント概要
- 参加者がディスカッションテーマを持ち寄り、投票をする
- 各ファシリテータ（ありがたい存在）が投票数の多いものを選択する
- テーマ別に各会議室でディスカッションする
今回は7個くらい？のテーマでディスカッションを行いました
ディスカッション
自分が参加したグループでは、テーマの掘り下げ・解決が難しかったこともあり、テーマにこだわりすぎず、発散した議論をしました
テーマ
実力に差がある場合のスクラム運用 （だいたいこんな感じ）
実力が低いメンバをいかに引き上げるのか？ という意図
テーマを挙げた背景
- 5人チームで1人実力が不足しているメンバがいる
- 4人だけでやるほうが成果があがる程度には、フォローするコストがかかっている
- 歩み寄る努力はしているつもり
- 歩み寄り、ヒアリングした結果、そもそも仕事にやる気がない、向上心もないと本人が吐露
テーマに対する回答
- スクラムには向き不向きがあるが、「やる気・向上心ないです」は向き不向き以前の問題で、打ち手がないのでは・・・
- メンバ間の実力格差問題は、モブプロが効果的（体験談）。下を引き上げることに成功した
モブプロに関して
- 下を引き上げることに効果的
- 1ストーリーがなかなか終わらないときに、モブプロを実施することで、当該ストーリーを短時間(全体での工数は大きい)終わらせることができる
- モブプロをする中で、自然とタスク分割が行われることが想定外に起きたメリット
ヘルプを求めにくい理由
- 能力不足の露見を恐れる
- メンバ同士が仲良くない
- メンバ間に上下関係のようなものが存在する
ヘルプを求めやすくする工夫
- ヘルプ用のチャットルーム(上司とか入れてない)を作る
- times_xxのような個人チャットルーム
- リーダ？シニア？層が率先してわからないをあえてラフに発信する
- 昼食時に顔が向かい合うようなレイアウト
- チームランチ
- slackなど自作アイコン・画像の落とし穴でキャッチーにはまっていることを表現できるようにする
- 朝会で雑談を推奨する(ローテで好きな話題を軽く話してもらう)
- 今日は隣で作業していい？といってオフラインの距離を近くする
技術的スキル(のみ)が高いメンバについて
- 声が大きいとメンバ間に上下関係を生じさせうる
- ジュニア層が発言を萎縮する
- 意思決定がスキルのあるメンバに集中し、責任も偏重する可能性がある
- 改善するために、上司(明確に上の立場の人)の協力もほしい
- 取り返しがつく範囲で、地雷を踏み抜いてもらい、メンバがフォローするという体験をさせるのもありかもしれない
- 正論は理解してくれるので、googleの例などを持ち出し、心理的安全がいかに重要か理論的に説明する
- 1人チームとして扱うことで、他チームとの協調となると協力的になったりする
パワープレイについて
- 炎上し始めて自然とパワープレイになることはあった（体験談）
- パワープレイ時に上下関係が形成されてしまう
- ジュニア層は伸び悩む
- 意図的にパワープレイした経験は参加者にはなかった
スクラム向いていない人とその対応
- 過去の成功体験に縛られて新しいやり方を受け入れられない人は向いてない
- スクラムは即効性がないから考えを変えるのが難しいが、根気よくやるほかない
- 本当に向いていない人は、組織内で異動するなどがいいが難しい
大きな組織で上からスクラムをみる
- 複数チームをスクラム的要素で比較することは難しい
- ベロシティはチームごとに1の基準が異なる
- 人月ベースでチームの期待値が設定されるのもやむなし
- 上に報告する際は、ビジネス・PJ的な指標に変換するのは当然
