Developerを目指すエンジニアが有用そうな技術記事や、ポエムのようなよしなしごとを投稿するブログです。転職透明化らぼ-技術ブランディング編」参加レポート先日、転職透明化らぼに参加してきました。rtlabo.connpass.com第1回から気になっていましたイベントでしたが、やっと初参加することができました。参加した動機は私自身ジョブホッパーなので、自身のこれまでの行いを省みるため。現職ではエンジニア採用にも積極的に関わるつもりのため、改めて勉強しておきたかったためです。イベントは異なる視点・ポジションのパネラーが3人呼ばれており、それぞれの発表とパネルディスカッション。イベントスポンサーの3社のLTが行われました。冒頭にコール&レスポンスで会場を味方につけつつ、個人の印象を残すという戦略を実行しつつ、ブランディングをテーマにプレゼンしているところで説得力を感じました。メディアの編集者だけあってとても理解しやすいプレゼンでした。Deckを見ましょうという感じです。技術ブランディングについてなんとなく理解した気になっていることを丁寧に言語化し、目標とする状態とそのモデルとなる会社も認識して目標・ゴールを具体化しているところが素晴らしいと感じました。組織としてのやっていきと、それを支える個人レベルでの工夫を合わせて紹介されていて、ためになりました。背中を見せることと、いい意味でそそのかすこと、ぜひやっていきたいです。「プレイヤー目線の技術ブランディング」エンジニア個人(特にマネージメントではなく技術職として)の視点からの技術ブランディングに関するプレゼンでした。「発信することで信頼の初期値が上がる」「最近のいい会社は採用にエンジニアが関わるからブランディング時に人事を意識する必要はない」はしっかり覚えておきたいと思いました。「まずは自分の活動透明化から始めよう」とプレゼンを綺麗に締めくくったところに、ソフトスキルも備えていてすげえなあと思わされました。ご本人のブログを見るとより理解が深まると思います。2019年11月25日スポンサーLTスポンサーであるゆめみさん、うるるさん、プレイドさんからも技術ブランディングについてLTいただきました。会社紹介だけでなく、知見を共有してもらえるのはとてもいいですね。内容とは一切関係ないですが一番印象に残ったのはこちら。2019年11月22日パネルディスカッション参加者から寄せられた質問に対してプレゼンター3名とモデレーターgamiさんがトークを繰り広げました。ネットラジオをやってるだけあってモデレーターに安定感があって聴きやすかったです。以下、ディスカッションの内容メモです。発言者がないものは発言者を覚えていなかったり、誰かが重要でない(全員同じ意見など)ものです。ブランディングを主導するのは誰?どの部門?旗振り役、リーダは組織によるが、エンジニア全員が関与する。人事だけ、エンジニアだけということは基本ない。発信の最初の一歩が難しい、どうするかmottoさん「先輩にLT枠に申し込まれたことがきっかけだった。きっかけはなんでもいい。小規模な受託案件のAWS運用といった抽象化したノウハウ。受託開発は露出がすくないからこそやると差別化できる。技術ブランディングで効果が出た施策ありきたりだけどブログ。採用するとき個人のアウトプットどこまで見る?飯田さん「めっちゃ見る。アクセスできるものは全部見る。実務経験がなくともブランディングになるか?mottoさん「なりうる。独学だからすごい、すごくないじゃない。ツイッターに技術以外どの程度書いていいの?自由でいい。gamiさん「自分を毀損してしまわないか。近藤さん「ブログのPVをKPIにするのは危険(炎上へのインセンティブになる)。飯田さん「巨大なモノリスRailsアプリに立ち向かう会社は多いが、どう立ち向かったかのアウトプットは差別化できるのではないか?」mottoさん「深みのある話ができるならそれをやる。深みのある話は個人では難しいが会社ブログならできそう。期待していた通り、ブランディングに関する学びとその整理ができました。最近サボりがちな自分に喝を入れることもできてよかったです。懇親会で人事の方から「面接やカジュアル面談後の【湯上り感】を大事にしている」という話を聞きました。自分の過去の経験からも【湯上り感】はとてもしっくりきたし、いい言葉だと思いました。2019年あと1ヶ月と少し頑張っていこう。2019に参加してきました。2019のために島根入り。出雲空港から松江行きのバスでSanSanさんのエンジニアと相席。Conferenceは初参加でしたが、参加してよかったとはっきり言えます。感想を一言にするならばタイトルの通り「RubyWorldはエモ良い」になりますが、せっかくなので参加してきた感想をもう少し記事に残しておきます。Conferenceは全体の印象としてテクノロジー寄りではあまりありません。開催趣意書を見ればわかると思いますが、人間を無視しないプログラミング言語であるRubyが非エンジニアも無視せず、巻き込んでいく、繋げていくためのカンファレンスのように感じました。技術的な内容のセッションもありましたが、頭が疲弊するような難易度の高いセッションが続くことはありませんでした。想像以上のエモさ前述のRubyKaigiとの違いや、エモい話が聞けるというのは事前に知り合いから聞いていました。事前に聞いていても驚くほど想像以上にエモかったです。正確に言うと想像以上に心にくる、刺さるスピーチをいくつもあったという感じです。2019を受賞した糸柳さんのスピーチを聞き、相当な熱意と共に情熱的に難しい問題に取り組んでRubyを進化させているのだと感銘を受けました。糸柳さんのスピーチに限らず、全編通してRubyとそのコミッター、そしてコミュニティへの感謝の気持ちを再認識させられました。感情が溢れたツイートたち。Rubyの進化・未来を語るときのMatzとても楽しそう。こんな風に楽しみながらテクノロジーに関わっていたい。地元にもCoderDojoがあってほしいなあという気持ちになった。自分で始めるのは当然楽ではないんだろうけど、とりあえず調べてみる。自治体の理解・後押しがすごいオープニングセレモニーでは知事、市長、官庁ら来賓からの挨拶がありました。その内容がよくある当たり障りないお偉いさんの挨拶ではなく、Rubyという言語とその利用シーンをある程度理解した上で、今後にどんな期待をしているか、どんなサポートをしていくつもりでいるかを示してくれました。なんと頼もしいことでしょうか。地方では京都や福岡に勢いがありますが、松江にも可能性を感じさせられました。2019年11月7日プログラミング教育・エンジニア育成への取り組みがすごいセッションの中で数も多く、個人的に目立っていると感じたのは教育・育成をテーマにしたものです。Japanさんの全国的な取り組みなどのお話を聞けました。低い敷居でほとんどの人に平等にチャンスがあるというのはプログラミングの長所だと思いますが、さらに平等に、さらに敷居を低くする活動・環境整備を進めている人がこんなにもいる。社会が良くなっているように感じました。CoderDojoの継続的な活動によって、次世代の育成にいろんな企業も協力してくれてる。世の中がよくなってる感がすごい。2019その他個人的ハイライト屋台っぽさがいい味出してるラーメン屋で同僚としじみラーメンを食べました。井上副委員長によるクロージングセレモニーがはじまりました。Codeでモデリングする環境構築の記事を書きました。ngmt83.hatenablog.com先月新しいパソコンに同様の環境構築をしようとして詰まったので、異なる方法をメモとして残しておきます。Kitのダウンロードにアカウント登録が必須になっていたためです。有料というわけではなさそうですが、アカウント(Oracleプロファイル)作成のフォームで心が折れました。Oracleプロファイル作成フォーム必須項目を表す*が全項目にありますね...ツールを使わせてもらうのですから、私の個人情報なんて安いものだと思いますが、勤務先の情報になると話は別です。JDK巷では「Javaが有料になった、Javaはオワコン」なんて騒がれましたが、Java全てが有料になったわけではありません。ありがたいことに無償で利用する方法も用意してあります。感謝しながら使いましょう。JDKはこちらから該当のVersionをダウンロードしましょう。Releaseを例に進めます。13をインストールこの章についてはわかりやすい記事があったため、そちらを参考(ほぼ同じ)にしています。Releaseをダウンロード・解凍します。するとjdk-13.0.1.jdkというフォルダが作成されるのでそれを適切な場所*2へ移動させます。私は標準的な配置・設定を好むのでよく用いられる/Library/Java/JavaVirtualMachinesにおきます。シェルからの操作例は次の通りです。13が認識されているか確認できます。-Vそしてjavaコマンドで実行されるようにPATHを通します。13`これでjavaコマンドが実行されるようになりました。下記のコマンドでversionまで確認できます。このエクステンションはとても便利なのでぜひインストールしましょう。「option+d」でプレビューを見ることができます。P」からPlantUMLコマンドを検索すると「ダイアグラムをエクスポート」できることがわかります。png画像での出力などを簡単にできます。JDKといった形で無償で利用できるのはとてもありがたいです。diagram)に落とし込んでわかりやすくしています。モデリング言語を扱えるように勉強しててよかったなと噛み締めています。version)Tweet広告を非表示にするもっと読むコメントを書く2019-10-16見積もりって難しい。過小見積もりをやらかしたので省みるポエム9月半ばに新しい会社に入社して、初めてそこそこ大きめの機能をメインで実装することになり、そこで目一杯やらかしました。やらかしたのは過小見積もりです。見積もりは完璧にできるわけはないし、完璧を目指してはいないのですが、今回は特にひどすぎました。リアルタイムなツイートがこちら。2019雑に例えると「ストーリーポイントで8ポイントと見積もったにも関わらず、実際やってみたら34ポイント相当だった。」「予想の3倍以上労力がかかった。こんなことを繰り返すのはまずいので何故これほどの過小見積もりが起こったか振り返り、原因・要因など心当たりをブログに残しておきます。私がいるチームは1ヶ月前は3名程度だったのが、今は5名程度*2になり、これからチーム開発するための態勢を整えていくという状況。メンバー全員が1人で大抵のことをできる中、みんながやりやすいようにプロジェクトの進め方を手探り中。委託でコミットしてくれているメンバーはそれぞれ拠点があるため、複数拠点のリモートチーム状態。見積もりはいくつか基準となるIssueがXポイントであると軽い共通認識を作った上で、実装担当者が取り組むIssueに相対的なポイント設定をする。今はベロシティを厳密に追っているわけではない。上記の前提で原因をざっくり技術面・メンタル面・他にわけて心当たりをあげます。技術面エンジニアリングの見積もりなので、当然ですが技術的な原因には心当たりがありました。以下のような原因が思い当たりました。採用されている技術を正しく織り込めていない類似実装部分の読み込みが足りない基準となるIssueのXポイントをAさんのY時間に置き換えてしまう採用されている技術を正しく織り込めていない私は前職ではAngularを用いていわゆるSPAとAPIサーバという構成でアプリのフロントを実装していました。今関わっているサービスはサーバーサイドのフレームワークにフロントも含み、複雑でないJavaScriptで実装されています。誤った前提で見積もってしまいました。フロントの実装中に大変すぎると感じてやっとこの過ちに気づきました。類似実装部分の読み込みが足りないアプリの改善や機能追加では既存の機能で使っているモジュールやライブラリを転用できることがよくあります。私はドックフーディングを通してどんな機能がどの辺りにあるか概ね理解できているつもりでいました。甘々な見積もりをしてしまいました。似てるように感じても実際には違っていたり、追加機能のほうがより高度なライブラリの知識が必要だったり、膨らむことが多いです。類似実装の読み込みと実際に書いてみるのは大事です。基準となるIssueのXポイントをAさんのY時間に置き換えてしまうストーリーポイントは工数ではありません。Issue同士の比較による相対見積もりです。これを理解していても油断すると勘違いしてしまいます。XをAさんは半日で終わる。」という情報から無意識に「Aさんは10ポイント/日」と誤認してしまうと危険です。半日で終えられるのはサーバーサイドで完結するIssueだけかもしれないし、仮にサーバーサイドについてAさんと私が同じような生産性だったとしても、フロントはそうではないはずです。ポイントは工数ではなく、Issue間の相対見積もりでしかない。習熟度を加味して締め切りに間に合いそうか考えましょう。「自分にとって時間がかかりそうな部分がある」程度の共有でも周りにとってはありがたいはずです。自分の気の持ち方が見積もりを見直す機会を潰してしまったと感じたことがありました。以下のような考え方によくないところがあったと思います。できるかどうかじゃない、やるんだよ。履き違えたポジティブこのくらいはできるはず、活躍してやるぜ。期待に応えたがりできるかどうかじゃない、やるんだよ。根性ポジティブ過小見積もりに気づき始めた時、メンバーから「間に合いそうですか?」「大丈夫ですか?」「(期日までに)できますか?」*5といった声をかけられました。冗談半分に返していました。辛い辛い言いながらやるより、暗くならないし捗るからこうやって言うのですが、この言葉・考え方のせいでもっとよいリカバリの機会を逃していたのではないかと思います。やるしかないことは楽しく、勢いよくやったほうがいいですが、もっと良いやり方があるはずのときにポジティブを履き違えた考え方をするのはもはや思考停止でした。このくらいはできるはず、活躍してやるぜ。期待に応えたがり人は第一印象で決まるとよく言われますが、仕事においては入社後すぐにインパクトを与えらえるとその後がとてもスムーズになるでしょう。自身のキャリアが5年になり、リードエンジニアへとステップアップしたいと考えている私は焦りすぎていました。その焦りが実力を過信させたかもしれないし、チームに入った直後に普段通りの成果をあげられないという普通のことを見落とさせたのかもしれません。当たり前のことばかりな上にまとまりがないですが、ブレスト的にあげると次の通りです。環境を変えたらオーバーヘッドがあるのは当然だという話と、リモートワークではコミュニケーションがより重要になるという話です。対策するのか?対策は思いついてないです。あったらぜひ教えて欲しいです。仕組みには至らない気をつける程度であれば次の通り意識していきたいです。実際に30分くらい手を動かして見積もるわからないかもしれない・時間がかかる可能性を早く共有する認識できていない不慣れもあると考える見積もりに少し時間を割くことでずれを小さくできます。早い共有で見積もりの更新やリカバリする機会を作れるかもしれません。わからなくなってから、時間がかかってから共有するよりも心理的ハードルが低いというのも良い点です。不慣れについては認識できないものもあります。認識できない不慣れが影響を及ぼしていることを理解していれば、差異がでたときも冷静に対応ができそうです。最後に完璧な見積もりはありえません。完璧がないからこそ、完璧に近づける努力をしていきましょう。*1:当然チームでの振り返りもします*2:フルタイムでない業務委託の人など1人とカウントするか判断が難しい*3:みんな委託とか社員とか関係なく、主体的にどんどん進めてくれる人たちでありがたい*4:現段階においてこの選択はとても正しいと思う*5:「Issue分けましょう」などの具体的なアドバイス、助力も受けました。08:30見積もりって難しい。先日エンジニアリングが関係ない初期設定の記事を書きました。この記事ではエンジニアの環境構築について備忘録的に書き残します。色んなエンジニアに勧められる初期設定を終えた状態。DBを扱いやすい状態です。特定のプログラミング言語などの具体的な開発環境については記載しません。toolsもついてくるので、特に意識せずインストールするだけでいいです。*1iTerm2は下のリンクからダウンロードして使用します。www.iterm2.comHomebrewをインストールします。サイトに記載されている通りのコマンドでインストールできます。shellをHomebrewを利用してインストールし、デフォルトのシェルをFishに設定します。HubログインDockerインストールサイトの通り、ダウンロードしたインストーラの指示通りに操作するだけなので、特に説明はありません。email設定ターミナル上での操作は次の通りです。メールアドレスGitHubへの公開鍵登録はWEBページに従ってください。fish化コンフィグ共有VSCodeエクステンションDockerPlantUMLエディタは各々が好きなものを使えばいいと思います。VSCode以外にメインエディタがあっても、利用者が多く、ペアプロにも便利な機能を持つVSCodeをサブとして使用できるようになっている方が望ましいです。こちらからVSCodeをインストールして、コンフィグやエクステンションを設定しましょう。code.visualstudio.comコンフィグVSCode内のターミナルで利用するシェルとタブで挿入される半角スペース数、半角スペースの可視化を設定します。"all",}エクステンション便利なエクステンションはいくつもありますが、より汎用的なDockerを扱いやすくするものと、設計で活躍するUML作成に役立つものをインストールします。marketplace.visualstudio.comngmt83.hatenablog.comPlantUMLの動作環境構築については次の記事を参照ください。MySQLと接続するサイトからダウンロードするだけのため非常に簡単です。composeなどで設定済みであれば、開放されているポートを設定してください。DB接続用のユーザ名やパスワード設定もしましょう。最後に今回はさらに効率的で理想的な環境はおいておき、多数にとってベターな共通設定にのみ目を向けました。設定漏れに気付くのは大抵後のことなので、気づけばこの記事を更新するかもしれません。toolsをインストールする方法もあるそうです。Proの環境構築をしたので色々忘れないようにここに書き残しておきます。この記事ではエンジニアリング環境については触れません。Macを使う人ならほぼ全員が使えるものばかりです。(向き不向き、好き嫌いがあるのでおすすめは特にしない)設定は大きく3つにわけられます。箇条書きにすると次の通りです。指を置くだけでロックが解除されるのは非常に楽です。IDログイン購入したアプリや、iCloudを利用する場合に必要です。Dock設定変更デフォルトだとDockがずっと表示されたままです。画面を無駄に専有されている感じが嫌いなので、自動で出たり消えたりするように設定します。使わないアプリを使用した後、Dockに常駐するのも好きじゃないので、非表示にします。Dock設定画面あとは、デフォルトでDockに表示されているアプリから使わないものを削除します。SafariとかメールとかPagesとかいらないです。Barをほぼ使いこなせていないため、タイピングに便利なFキーに変更しています。Stripを表示するようにしています。Bar設定トラックパッド周りの設定変更トラックパッドの右下や左下のクリックが下手なので指2本のクリックを副ボタンクリックに設定します。トラックパッド設定また、簡単に画面をロックするために右下にホットコーナーを設定します。セキュリティの関係上ちょっと離席をする場合もロックしたほうがいいですし、実際にそういったルールが存在する職場もあるのでけっこう重宝する設定です。IDを設定していればロック解除も楽ちんなので、PCから離れるときは画面ロックする習慣をつけましょう。ホットコーナー設定キーボード設定ライブ変換をストレスに感じるならオフにしましょう。Googleの日本語入力をインストールしましょう。キーボード設定www.google.co.jp便利アプリ設定パスワード管理アプリとウィンドウ整列アプリは個人的に必須だと思っています。パスワード管理アプリのためにDropbox*1も入れます。この記事では最小限のDropbox、KeePassX、Magnetの3つを設定します。Dropbox設定Mac用のアプリのインストールとログインまでしましょう。Finderで確認できるようになれば設定完了です。finderKeePassX設定アプリをダウンロードして、Dropbox等の自分が使用しているクラウド上のデータベースを開きましょう。www.keepassx.orgMagnet設定Appストアからダウンロードしましょう。カーソルキー」で上下左右半分になるようにします。commandとoptionはキー同士が近いのでおすすめです。Magnetの環境設定Chromeエクステンション設定Safariは即座にDockから消してChromeを入れましょう。便利に使うためにエクステンションを設定しましょう。おすすめのエクステンションを紹介します。Screenshot名前から分かる通り、スクリーンショット撮影のエクステンションです。無料で十分な機能が使えますし、機能が多すぎて使いにくいわけでもなく、おすすめです。chrome.google.comOneTabブラウザで開いているページをリンク集としてまとめてくれるエクステンションです。ウィンドウやタブを開きまくる人には特におすすめです。WEBページとして公開することもできるので、複数のページをスマホ実機で見たいときや知人にメッセージで共有したいときに重宝します。chrome.google.comesareaMarkdown記法*6をアシストしてくれるエクステンションです。esaを使っていなくても便利に使えます。GitHubのIssueやPRにMarkdownで書くときもアシストしてくれてとても便利です。MarkdownMarkdown記法でリンクを書くときに、[リンクテキスト](URL)の形式に手打ちするのはそこそこ面倒です。このエクステンションはそれを簡単にしてくれます。chrome.google.com例えば先ほど紹介したesaのページを開いたタブで使用すると次のような文字列をクリップボードにコピーしてくれます。自律的なチームのための情報共有サービス](https://esa.io/)最後にまっさらだったパソコンが自分色に染まるというか、手足として馴染んでいく感覚は少し気持ちがいいですね。みなさんのおすすめ設定があればぜひ@ngmt83に教えてください。弱小エンジニアbooth.pmつい黒歴史になりそうなポエムを書いてしまいましたが、「個人開発がやりたくなる本」はいいぞ!ってことが言いたかっただけです。「個人開発がやりたくなる本」ってどんな本?サブタイトルにある通り「個人開発者13名によるエッセイ集」です。執筆者それぞれが思い思いの構成で、ある人は熱く、ある人は淡々と、またある人は享楽的に綴っているのです。技術要素もあるし、学びはたくさんありますがエッセイ集という表現は適切でしょう。それがいい!なんで読もうと思ったの?個人開発したいと思いながら行動に移せない私は技術書典6でこの本をチェックしていましたが、物理本を完売で手に入れられませんでした。電子書籍を買おうか悩んでいたところに@dala00さんの「本の予備?があるのあげます。Crieitに感想でも書いてもらえたら嬉しいです」という主旨*1のツイートを見かけたのですぐにDMして送っていただきました。本は4月にもらってGWには読み終わり、既に2周以上しています。*2感想がこんなに遅くなった(すみません)のは「この本を読んで私もアプリが作れました(ドヤ)」をやりたかったからです。アプリは作れたの?自作アプリを3つ!作りかけて凍結しています......本を読む前はリポジトリ作成すらできていなかった私にとってこれは進歩です!読んでなければ1つも着手できていなかったでしょう。作りかけて凍結した理由はプライドが無駄に高かったり、あれやこれや機能を詰め込もうとしたりでゴールできなくなったためです。ちなみにこれは7章で作り終わらない原因の1つとして紹介されています。おすすめは何章?全部です。十人十色の個人開発者達なので「わかるうううううう」と感じる章も「そういう考えの人もおるんやな」と感じる章もあります。仕事の流儀や情熱大陸を彷彿とさせる章があるかと思えば、文字通りのクソアプリ*3が紹介される章もあります。章ごとに全然違うのです。この違いはとてもためになる違いだと思っています。人によって好みはあるでしょうし、仮に1章しか響かない人もいるかもしれません。その分、その1章はハマるでしょうし、1章のためだけに買う価値もあるでしょう。内容紹介薄くない?引用したい箇所は多すぎて冗長になるし、感じることは人それぞれだと思うのであえて触れていません。自分の目で確かめてくれ!ということです。いえこのままでは書籍紹介記事としてあまりに不親切なので参考になりそうなリンクを以下に貼っておきます。Kindle版この商品を含むブログを見る(多分BOOTHで買った方が執筆者に還元されやすいです。)最後にもうすぐ技術書典7だけど技術書典6の本を読んだっていいじゃない!むしろ技術書典7の戦利品で学んだ知識・技術を生かし、個人開発がやりたくなる本を読みながら自作アプリを作り上げましょう!*1:元ツイートは削除済みのため記憶は曖昧*2:ところどころ読み返したくなる本です。version)見積もりって難しい。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。