はじめに
ここ最近、エンジニア向けの社外イベントを聞いてみようと思い、いろいろ参加してみました。
株式会社ラクス主催のLT会二つとQiita Conferenceです。
いつもは自分で勉強したことをまとめることが多いのですが、今回はイベントレポのような形でまとめたいと思います。 業務に関係のあることを中心に勉強している日々が続いていたので社外のイベントに参加して刺激をもらうのもたまにはいいなと感じた週でした。 特に印象に残った部分についてまとめと言及をしたいと思います。
ラクス フロントエンドLT会 6/15
Nuxt3の公式ドキュメントを日本語に翻訳して気付いたこと
- 公式ドキュメントの翻訳という形で技術貢献するというアプローチが新しかった。
- 技術的によくわからなくても翻訳することでわかるようになることもある。
開発速度を5倍早くするVSCodeの拡張機能を作った
- タイピングを止めると数秒後に爆弾が爆発してVSCodeが強制終了するという恐怖のネタ系拡張機能のお話
- 自分が面白いと思ったものを作れるっていうエンジニアの楽しさみたいなものが伝わった
- 手を動かすことで思わぬ学びを得られるって話は身に染みた。
Vuetifyにコントリビュートした話
- OSSへのコントリビュートとしてissueを探してバグを修正する流れを説明
- OSSにコントリビュートする発想が自分になかったなあという気づきがあった
- 簡単なバグ修正でもコントリビューターになれるというのも敷居が下がってよかった。
suppress-ts-errors を使って TypeScriptの型チェックを漸進的に強化する
- プロジェクト全体にTypeScriptを導入する際に構文エラーをコメントに差し替えて一時的にエラーを回避するツールのお話
- これを使うことで既存コードのCIは通して新しいコードには厳密なTypeScriptを適用できる。
ラクス アジャイルをゆるく語りたい 6/16
アジャイルを支える心理的安全性の守破離
- 心理的安全性とは...対人関係のリスクを取っても安全だと信じられる職場環境
- 成果を出すための土台になる心理的安全性が必要
- 「守」...価値観を共有することで事象や人に向けてではなく共通の価値観に向けて議論ができる
- 「破」...安全レベルを引き上げるために振り返りやコーチングを行う。意見が言えるということは成果に向かって行動しようとしている姿勢があること。
- 「離」...安全を忘れる。安全を意識しすぎるとチームとしての成果を見失ってしまう。
視座とアジャイル
- 視座...どのレベルの課題まで当事者でいられるか
- チーム内に解決策の実行までできる人数を増やすことがハイパフォーマーなチームにつながる
- 視座を上げるには
- 上長からの権限移譲
- 抽象と具体のトレーニング(書籍)
Qiita Conference
今週行われたQiita Conferenceも聞いてみました。
無駄なことを考えるためのアウトプットと発想法
藤原さんのアイデアの作り方は気になっていました。 こういうのってどういう生き方してたら思いつくのか、って毎回思ってました。
アイデアの拡散思考と収束思考
まずは拡散思考から。 ここでは数多くアイデアを出すために、といった目線で以下のような方法が挙げられていました。
- 無駄なことを考えるには、一旦頭を悪くする
- 言葉から考える...目の前にあるものなどなんでも言葉を組み合わせてイメージを膨らませる
- 想像力が膨らんだものを大切にする
- 役割を与える。...組み合わせた言葉から想像力が膨らんだものにはどんな役割があるのかを考える。 例: スマホマグカップ...温度を測れるIotスマホマグカップとか。
- 修飾語をくっつけて変な言葉を作る
- シチュエーションを限定して考える
この言葉遊びをお笑い芸人のハライチさんを例に出してました。 お笑い好きとしては結構しっくりくる表現だったかも。
思考パターンから逃げる
普段通りの思考パターンだと似たようなことしか考えられないのでパターンから変えてみるという手法。
- 逆側はどうなっているのか
- 開き直って考えるとどうなるのか
- 問題をもっと複雑にさせるとどうなるか
ロールプレイ
実際に誰か使用者になりきってアイデアを膨らませる。 エンジニアとしてもユーザー目線が大切だと言われるのと同じことかなと思いました。 エンジニアもユーザーというロールプレイをすることでUI/UXを向上させることにつながると思っています。
無駄の大切さ
これはエンジニアとして仕事していると感じます。 何もしない大切さ。 ジョークAPIだったり、遊び心のあるものもあったりするのでエンジニアは結構無駄なものを作ることもあるよな気もします。ジョークRFCとかもありますしね。
生活の豊かさや余剰がいかに人類の歴史において重要だったかというお話もありました。(無駄の正当化)
アウトプットする場所、方法について
- プライベートなアウトプット
- パブリックなアウトプット
パブリックなアウトプットは周囲に影響を与えられるが、批判もある。 自分のためのアウトプットなのか、他人のためのアウトプットなのか、考える必要があるなと感じました。
世界を加速させるアウトプット
この講演はクリーンアーキテクチャとGoogle検索すると一番にヒットする 実装クリーンアーキテクチャ という記事の著者で、 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 という本の著者の方である成瀬さんの講演です。
技術者としてのアウトプットについての講演でした。
成瀬さんがどんなアウトプットしてるのか?
- Qiita
技術ブログ
カンファレンス
- 2021年 50回
- 2022年 38回
- 書籍
特にカンファレンスの数がすごいですね、、、。 そもそも一年は52週間なので週一ペースということになります。(このブログと同じペースってことか、、、。)
パブリックなアウトプットとの向き合い方
アウトプットを始めたきっかけ
- 怒り...新卒研修を近くで聞いて「そうはならんやろ」という怒り駆動開発()
- 教育の軽視...新卒2,3年目が研修を担当することが多い
- 自ら研修を担当したり、社内勉強会をしてみたら楽しかった。
ということでした。怒り駆動開発
は確かにいい言葉かもしれない。
ミノ駆動さんも怨念駆動開発
という言葉をおっしゃられてましたし、エンジニアが外に向けてアウトプットする動機はマイナスな感情がきっかけになることはあるのかなと思います。
マイナスな感情が発生するということは技術的に問題が起きていて、それを簡単には解決できないから発生していると思うので。
上記の問題から自分の技術の知識を広げるには技術書を出版することを考えついたそうです。
そこで、出版社から本を出すために必要なものは以下の三つ。
- 書ける証明
- ある程度の地位
- 影響力
書ける証明について
本に書こうと思っているものを書いてみる。ということで書かれたのがこの記事です。8万文字あるそうです。期間は一週間ほどで書き上げたらしいです。
僕はこのブログの記事での目安として5000文字くらいとしていて、2~3日で書き上げることが多いです。 8万文字となると構成やまとめ方も変わってくるのかなと感じました。
ある程度の地位、影響力
技術書というのは誰が書いたかがとても重要です。
- 個人セミナーをconnpassでやって人が集まる
という経験から需要や影響力の実績となったらしいです。(100人ちょっとくらい集まったらしい) 確かに、イベントに人が来るということはそれだけそのテーマについて悩んでいるひとが多いということで、技術書においては一種市場調査とも言えるかもしれません。
アウトプットへのスタンスとコツ
質と正しさを重視
良いアウトプットとは
- 想定読者が求める情報が網羅
- まだこの世に存在しない
- 前提知識が網羅
- 正しい(重要)
正しさを求めることによるメリット
- 正しさを求めることでインプットが加速する。
正しい情報をアウトプットしようとすると、情報のソースであったり、実際にコードを書いて動作を確認したり、インプットの質の向上が見込めます。
大事なのは、
人は誰でも間違う、が 誤ってもいいやではなく 正しさを追い求めた上で誤る
ということとおっしゃっていました。
技術文書に関するアドバイス
- 想定読者が必要な知識を得ているか
- 必要な知識が先に説明されるような構成にする
- 具体と抽象を行ったり来たりする
アウトプットは誰かの時間を節約すること
本講演のまとめであり一番伝えたいことはここなのかなと感じました。
アウトプットの一番のメリットは他人の時間を節約する
ということです。
自分が詰まったところや技術に対して理解するのにかかる時間をより少なくすることがアウトプットのメリットです。
まとめ
今回は記事自体がまとめのような形なのでまとめは割愛します。
所感
エンジニアとしての経験が浅く、ほかの企業のエンジニアの考えみたいなものを聞くことがこれまであまりなかったのでいい機会になりました。
Web系に転職してこういったイベントへ参加すると自分の業務に活かせそうな部分が多く、有意義に感じる時間でした。
ラクスのLT会ではラクス社以外の人も発表されていて、手を動かして色々作ってみた話や、技術に関して困っていることがエンジニアはみんな興味があるんだなと感じました。
Qiita ConferenceもLT会もコメント機能があり、参加者のコメントも楽しく拝見していました。みんな似たようなことで悩んでいたりするのでヒントは色々転がってそうだなと感じました。
いろんな発表を聞いてみて感じたことは結局エンジニアとしての勉強はインプットよりアウトプットに重きを置いた方が良いなということでした。
パブリックなアウトプットに限らず、コードを書いてより多くの失敗をすることがエンジニアとしての経験値になり、実力になると思いました。
いろんなことを考えてコードを書くきっかけとしてイベントに参加していくことはこれからも続けていきたいと感じました。