インフラ勉強会は時間と場所を飛び越える
これは #インフラ勉強会 Advent Calendar 2018 の12月2日のエントリーです。
インフラ勉強会とは、有志が立ち上げ、運営している 日本最大級のオンライン勉強会&コミュニティ です。 そこで得られたこと、繋がり、可能性、感謝と僕なりの思いなどを書き綴ってみたいと思います。
インフラ勉強会はいいぞ。
はじめに
いろんなところで言っているのですけれど、僕は知識と経験が結びつかないままバラバラに進んできてしまってるところあるんですよね。
有り体に言うと色々足りない。
で、アプリケーションを作ることは、全てを知ることだと考えたんですよね。 ミドルウェア、OS、メモリ、CPU、ネットワーク、DNS、etc、全てが関わってくる真ん中にいるんじゃないかなって。
では、アプリケーションの周辺を知るにはどうすればいいか。独学には限りがあるし…。 そんな時、 #インフラ勉強会 を知ったんです。
有志が立ち上げたオンライン勉強会、しかも内容がすごく濃密。初めてみたときは結構衝撃を受けました。
インフラ勉強会とは
有志が立ち上げ、運営している 日本最大級のオンライン勉強会&コミュニティ です。 特徴を箇条書きにすると以下のような感じかな?
- Discordのチャットと音声を利用する
- 画面共有やスライド共有を利用する
- 実際の環境構築もコマンドをみながら話を聞ける
- 参加者は数千人
- セッションの聴講者は多い時だと100人以上
- Discordに登録して音声をONにするだけで参加できる
僕なりのいいと思うところ
いいなと思うところはたくさんあるんですが、パッと思いつくところを列挙してみます。
とにかく、 通常のリアル登壇とは違う良さがある と思います。 あと、とにかく登壇への敷居が低いです。
電車での移動中でも聴講できる
Discordというアプリを入れてオンラインで参加すれば、ネットワークさえあればどこでも聴講できるんですよね。しかもだいたい録画してくれているので、後から聴講も可能だったりします。
これがことさらに素晴らしい。イヤフォンで音声、画面でチャット、画面共有でスライドも見れるんです。
質問があれば Q
をつけると質問botが拾って溜めておいてくれる
大抵のセッションに聴講者とのコール&レスポンスがあります。 登壇者にもわからないところがあれば、わかる人がサクッと補足してくれたりもする。しかもチャット&音声で。
初心者でもチャットの反応をみながら話を補足しつつ進めてくれるので、すごくわかりやすいんですね。
時間制限を緩くすることでセッションの持ち帰りを多くしている
1時間枠でも実際に話すのはだいたい30-40分が多く、先にも言ったようにコール&レスポンスに丁寧に時間を使っています。 なので、質疑応答、実際のデモ、余談など様々なバリエーションがあって、周辺知識も知りつつ進むことができることが多く、通常のリアルセッションと違って多角的に知識を得られます。
また、オンライン参加なのでどんな格好しててもいいし、何を飲んで食べていてもOKってところもいいですよね。
初めての登壇
インフラ勉強会を知った直後くらいに、定期的に LT大会があることを知ったんです。そこで個人的に「やってみたいなー」って呟いたんですよね、確か。 そしたら たけし さんに拾っていただいたんです。あれよと言うまにエントリーが決まり、LTの内容でもないし、テーマに即しているわけでもないのにトークさせていただくことに。
その時のNaccoさんのアナウンスがこちらでした。
本日4/8の #インフラ勉強会 は
— Nacco@ボロちゃん (@climbing_nacco) 2018年4月8日
20:00~
インフラ勉強会LT大会「わたしの環境紹介LT」 後半戦
スピーカーは@barson_4 さん@sakuraba_nemu さん@nagashi_ma_w さん@andesm さん@dozonot さん@mamy1326 さん
22:00~
@ts03511 さんの
「新旧CentOS比較」
お楽しみに😆https://t.co/lNvnOsr5ZB
スライドは作らず、esa-pagesで登壇しました。
敷居が低い
ほんと異常に低いです。むしろ「教えてくれ」という時間で何十人もの知見が集まることもあるくらいです。登壇という概念が良い意味で覆された瞬間でした。
カンファレンスなどの登壇とは違って、不特定多数の技術スタックを持つ人がカジュアルに集まれるオンラインという場ならではだなって思いますし、知見が集まって聴講者の知識が1段上がる。
そんな場が作れるのもすごいなって思います。
どんなことにも技術がある
また、輪読会や技術以外の話も多くて、例えばカレーの作り方、健康について、などなど、 どんなことにも必ず技術が存在する ってことの気づきをもらえたのは、インフラ勉強会という場所からでした。
時間と場所に縛られない
赤ちゃんを抱っこしたままトークする人もいらっしゃったりで、この後に書きますが 多様なワークスタイルの発信 にもなるんじゃないかなって思っています。
可能性の最大化に繋がっているんだな、っていつも感じます。
可能性の最大化
数多くのセッション、出かけなくとも、何かをしながらでも聴講できるんですよね。育児しながらトークもできちゃう。
育児しながらのおかーさんだってすごく苦労して時間とタイミングを合わせていると思うし、自分も少なからず育児に参加しているのでわかるところ多いのですが、とにかく 技術を持つ人すべての可能性を最大化している場所 だなって思います。
なによりインプット、アウトプットをしやすいし、自分の興味のある話題だけチョイスできるのもありがたいですし、なんと毎日何かしらのセッションがあるんですよね。本当に毎日続いてるっていうのは、僕が個人で行なっている学習と共通するところがあるんですが、それを組織単位で実行しているのがすごい。
AWSの先生など、各分野の専門家が必ずいますし、そんな人たちが集まって自発的にセッションを重ねていった結果なのはわかるんですけど、それにしてもすごいことだと思います。
働き方を変える
僕は(原則的に)フルリモートワーカーです。家族との時間も家事も育児も大事だし、移動時間は無駄なことも多いと思っています。
また、生き方と仕事が多様化している現在、働き方だけ多様化に対応できていないって思うんですよね。取り組んでいる企業も個人も数多いし、成功しているところがたくさんあるのもわかっているんですが、それ以上に 本来の目的を見失っている ケースってすごく多い。
つまり時間と人材を無駄にしていることってまだまだ多いと思うんです。
インフラ勉強会は オンラインコミュニティ ではありますが、そんな 働き方を変えるモデルケース になって行くのではないかな、と感じてもいます。
リモートでも登壇してコミュニケーションできるを学んだし、僕自身の現在のリモートワークにも活きていることたくさんあります。
しばらく離れていたけど…
DNSの話トークさせていただいたあと、しばらく離れてました。本業で色々思うところあったり、この頃から毎日の学習を続けるようになったり、環境の変化が多い時期でもありました。
まあ、いろいろあったんですよねー…。
でもそろそろ再開します!僕が見れていなかった間にも色々あったようだけれど、みんなにお世話になったのは変わらない。なら 恩を送っていく しかない。自分の持つ情報、技術を共有していく。
そんな気持ちで、2019年から色々やっていきます!
さいごに
そろそろ発足1周年、イベントの準備を進めてくださっているとのこと。
自分でもイベント主催側にいるので、その知見も含めて、雰囲気づくりにも貢献したいって思っています。
具体的には、今後カジュアルに登壇していくし、参加している人の背中を押したいし、みんなも登壇しよう!ってことも話していきたいなって思っています。
技術を持つ、これから持とうとする人、すべての可能性の最大化につながれば良いなと思っていますし、僕自身もそういう人たちの背中を押すことを人生目標に掲げています。
インフラ勉強会は時間と場所を飛び越えます。
今後は積極的に参加していこうと思います!
誰かの背中を押していくこと
これは エンジニアの登壇を応援する会 Advent Calendar 2018 の1日目のエントリーです!
僕は エンジニアの登壇を応援する会 という勉強会・イベントの主催をしています。主催といっても、情熱的にコアスタッフをやっている、ということなのですが、それこそが主催であるということだと思うので、主催してます!っていつも言ってます。
実はちゃんとイベントや勉強会、カンファレンスの 主催をやる ということは今までなくて。
そんな僕がどう関わり、何をみて、何を考え、どんな行動をしていくのか。それを綴ってみようと思います。
ちなみに12月27日に エンジニアの登壇を応援する忘年LT大会 というイベントを開催します。
登壇を応援する今年最後のイベント。どんな風に応援されるのか、LTの敷居など、イベント会場で体験していただけたらなー、と思っています。ご都合の合う方はぜひ!
関わるきっかけ
builderscon tokyo 2018 というカンファレンスがありまして、そこで1時間話すことになっていて、事前にスピーカーが集って飲食しながら交流する スピーカーディナーというイベントがありました。
そこで、発起人の ariaki さんに「一緒にスタッフをやりませんか」と声をかけてもらいました。このかたは OSの中身などをきっちり知ってるすごいエンジニア。
全てのエンジニアに知ってもらいたいOSの中身について という内容で登壇することは知っていましたから、そんな人が僕になんだろう?と思ったのを覚えています。
図らずも これからの人の背中を押したい と思っていた矢先。2つ返事で引き受けることに。
そうして直近のイベントである 登壇の技術を勉強する会 #1 で登壇させていただくことに。
ここから、僕の エンジニアの登壇を応援する会 での活動が始まったのでした。
情熱と優しさ
エンジニアの登壇を応援する会 に最初に僕が感じたのは、ただただ情熱的である、ということでした。 しかも発起人だけじゃない。スタッフも登壇者も情熱的なんです。
そして何より、 エンジニアの幸せを全力で支援する というポリシーに心から共感しました。なんの打算も(いい意味での)計算もなく、ただただ支援したい。
関わる人、1人1人によって情熱の根源は違うかもしれません。 働きすぎて潰れていった人をみたからだったり、階段を昇れなくてしんどい思いをしている人がいたからだったり、アウトプットへの1歩を踏み出す勇気が出せなかったり。
そしてそれらを、おそらく自身で体験しているからだったり。
関わっていくうちに、その情熱の根源は 優しさ でできている。そう気づくまで長い時間はかかりませんでした。
今までの自分
ここで今までの自分を振り返ってみます。 僕は流されるまま、開発現場を転々としてきました。フリーランスで仕事を取っても、SESで現場に入っても、常にそうでした。 上昇志向がまるでなかったんですね。
結果として、何一つ深く身につかなかったんです。 それが焦りとなり、焦りが きっといい仕事、マッチした仕事があるはずだ という行動に繋がり、悪い循環が回り続けていました。
また、オブジェクト指向?設計原則?なるほど全くわからんって状態でしたし、勉強会に行っても理解できないことが多かったです。
正直、わからないことが辛くてエンジニアを辞めようと思ったこともあったんですよね。 周りのエンジニアが超えていく階段がとてつもなく高かったんです。僕に取っては。 とっかかりさえ見つけられず、出てくる言葉や略語1つずつを聞くたびにまるでわからず、話についていけず、ただただしんどい日々を過ごしていたのを思い出します。
しかし、転機っていきなり訪れるもんなんですよね。
転機
2016年、もう案件ベースではなく、何か1つのサービスにコミットし続けたい。そこで自分を鍛え直したい。経験を積みたい。
そう思っていたので、転職(というか15年フリーランスの後なので就職かな)活動をしてました。 とはいえ今のような恵まれた人の繋がりを持っていたわけでもなく、勉強会に積極参加していたわけでもありませんでした。
見知らぬエンジニア同士で飲んで意気投合するなど考えられない。
そんな時に、以前フリーランス案件で現場が一緒だった人からのリファラル(声かけ)で、とある会社に入社することに。
その会社がどうだったかはもう話す気もありませんが、そこで得られたのは MySQLをゼロからチューニングして好きにしていい というチャンスでした。
結局 my.cnfをゼロから調べて設定して検証する ということをし、それをQiitaに書いて いました。
ここですでにアウトプット欲が芽生えていたのを思い出します。
ここからです。勉強会にどんどん参加するようになったのは。 忘れもしない 第111回 PHP勉強会@東京、主催者のかたからLTに誘っていただきました。
そこで恥ずかしながら登壇デビューをすることになったんですよね。 そんなデビュー作はこちら。
もうね、完全にトークというものを履き違えてますよね。笑いを取らなくてはならない、という間違った認識で一人突っ走っている。いやー恥ずかしいw
とはいえ、僕の人前でのアウトプットはここから始まり、Twitterでも発言するようになったのでした。
2017-2018年の自分
上述のMySQLのLTを皮切りに、20分枠、Y8、builderscon、などなど、様々な登壇を経験させていただきました。
どんな登壇をしたかは昨年末に こちら で振り返っていたりします。
MySQLの深掘りを業務でやらせていただくという機会に恵まれましたし、そこで見つけた自分なりのとっかかりを語る機会もいただきました。
結果として、僕と同じような悩みを抱えている人が結構いるんだ…という妙な安心感と、使命感のようなものを抱いたのを覚えています。
これを機に、自分のエンジニアとしての人生目標が 隙間を埋める、背中を押す ということに定まっていくことになります。
これからの自分
目標は定まりました。何をみて、考えて、行動するか。
その行動先をどうしよう。登壇だけなのか?
そんな風に思っていた時に、エンジニアの登壇を応援する勉強会の主催としてイベントをやっていくというご縁をいただきました。
イベントを通して背中を押していく。登壇を通して背中を押していく。技術書を何かしらの形で執筆していく。階段と階段、行間の隙間を埋めていく。そして自分へのインプットアウトプットを続けていく。
それらのインプットアウトプットの輪廻を作り、その中に身を置きながら、誰かに勇気や安心を提供できたらな。 技術と技術、例えばブログの1行目と2行目の行間を読み解く技術につまずくとか、同じ悩みを抱えている人の助けになりたい。
僕が生涯で触れられる技術には限りがありますが、それを最大化するにはどうしたらいいんだろう。
その答えは、 より多くの人が集まる場を作る ことなんだなと今では考えています。
何かを始めるのに「遅い」ということはない
僕が登壇デビューしたのは43歳です。 日々の学習とアウトプットを始めたのは44歳です。
それからというもの、超えられなかった壁、階段を少しずつ超えることができてきました。そして、知っていく楽しさを得る、楽しさのその先がわかる、時間が濃密になる。
得難い経験と楽しさの中に僕はいます。 エンジニアとしてこれ以上の幸せがあるのだろうか、とも考えます。 幸せの定義は人それぞれなのでこれは僕の考えではありますが、 楽しい思いこそが幸せにして、技術を発展させる という強い思いがあります。
もし「もう遅い」とか思っている人がいたら、大丈夫です。sftpアカウントの作成方法を懇切丁寧に解説する記事でもいいんです。大きな技術の1部分を切り取って5分間、情熱的に話すだけでもいいんです。
そんなあなたのトーク、待ってる人が必ずいますので、背中を押したいなって思っています。
不安は確信に変わる
最初は 自分のアウトプットが求められているのか不安 でした。でもやってみなくちゃ始まらない。
そこで続けてみたら「年齢関係なく」反響をいただき、一気に人の繋がりが増えていったんですよね。その繋がりの中にいると、自然と 次何を話そうかな って思考になってるんです。
つまり、背中を押しているはずが、気づいたら押されていたんです。押して押される輪廻の中にいたんです。
ああ、僕は この活動をしていくことで間違えていない という確信を得られた瞬間でもありました。
仲間に恵まれる
エンジニアの登壇を応援する勉強会 に関わる人たちは、みんな優しいです。人の痛みを知り、それを優しさとして発露している人がほとんどだと思います。
僕は11月半ばに転職をして、環境も仕事も変化しました。 おかげさまで自分が活躍できる最良の場にいられていて、すっごく充実しているし、コミットメントできている実感が得られている。
それはすごくいいことなのですが、知らず知らずのうちに疲れちゃってたんですね。
で、エンジニアの登壇を応援する勉強会のSlackにまともにリプできない状態になってました。buildersconのコアスタッフもやっているのですが、そちらへのリプも返せない。
やばいな、これは何か行動を起こさないとな。迷惑かけちゃうな…
そんな時に発起人の ariaki さんからDMをもらったんです。 勝手にその一部を掲載しちゃいます。
たまにはゆっくり休んで!まみーさんはインプットしすぎですよ。 少しは休養する時間をとりましょ。 環境と季節で今辛いだろうなーっていうのは想像してましたw まずは新しい仕事に慣れるまでそれに集中して、リフレッシュしてから戻ってきてください。 特にSlackは分報とか多いんでミュートしておいて大丈夫ですからね。 進められる所は進めて、後からまみーさんも見返せるようにesaとかはちゃんと更新しておきますから。 来週末にリフレッシュしてるの待ってます。
今読み返してもちょっと泣きそうになります。 本当はこれに続くあったかい言葉ももらったし、他のメンバーからも優しい声をかけてもらったし、僕のことをちょっと離れたところであったかく見守ってくれてるのがわかるんですよ。
最高の仲間じゃないかって思うわけです。それに応えられていない自分を不甲斐ないなと思う反面、完全にへたり込んでしまう前に気づかせてくれて、自分にブレーキをかけられた。
ああ、恵まれてるんだなあ。人生捨てたもんじゃないなあ。大げさでもなんでもなくそう思いました。
buildersconのコアスタッフの方も、 Kumi TM おかーさんにフォローしていただいたりして、あーやっぱあったけえなあ、なんなんだこの最高の人たちは…って思いながら、自分をリビルドしてるような感じです。
そろそろ実行形式も出来上がる感じになってきましたので、そろそろリスタートしていくぞ。
エンジニアの登壇を応援する勉強会の活動紹介
そんな最高のメンバーが集う勉強会。どんなことをしているかの紹介をさらっとしてみたいと思います。
その1:登壇を応援する
登壇は、緊張するよ、最初はね(575)
そんなわけで、1歩を踏み出すための応援をしてます。
- 登壇資料のレビューを実施
- 登壇のリハーサル会を実施
- スライドを書く技術を共有
- スライドのデザイン相談
- テーマ選定相談
- 技術相談
めっちゃいっぱいチャンネルあるんで、ぜひ Slack へJOIN!
その2:執筆を応援する
エンジニアたるもの、一度は本を書いてみたいはず!(個人の見解です)
そこで実際に執筆した人からも色々な情報を得ることができますし、なんなら共同執筆してくれます(?)
- 技術書典での執筆者からアドバイス
- 具体的に執筆していく手法を共有
- 定期的に勉強会を開催
こちらも専用チャンネルあるんで、ぜひ Slack へJOIN!(2回目
その3:技術書の読書の技術
読書の技術を勉強する会 #1 で実施する予定です。
技術書を効率よく読むのも一つの技術。積ん読、ありますよね! そしてできれば一刻も早く消化したいし、自分のモノにしたい。
そんな読書の技術も学べたりします。
その4:初心者が参加しやすいLT大会
様々なテーマでトークできるLT大会を定期的に開催しています。11月だと 秋の夜長の自由研究LT大会 を実施しました。
エンジニアリング関係なく、自由なテーマで思いの丈を5分に詰める!そんな場を定期的に作っていますので、興味持ってもらえたらいいなと思いますし、ただただ楽しむために来ていただいて、感想などもらえたらスタッフ一同小躍りします。
次の開催だと エンジニアの登壇を応援する忘年LT大会 になります。 年末で様々な忘年会がある中、もしご都合が合えば、参加してみていただけたら嬉しいです!
その5:賑やかなSlack
個性豊かな人からROM専(古い)な人まで、たくさんのかたに参加いただいています。
レビューやリハだけじゃなく雑談も豊富で、毎日ぴよぴよ言ってる人がいたり、もはや人ではなく枝豆の妖精だったり、属性も種族も様々だったりしますが、みてるだけでも楽しいし、会社のSlackなどと違い、息抜きもできたりします。
一度のぞいてみてもらえたらなあ、と思います。
ぜひ Slack へJOIN!(3回目
さいごに
とうわけで、僕の エンジニアの登壇を応援する会 への思いの丈を好き勝手ポエムにしてみました。
アドベントカレンダーの1日目にふさわしいかどうかわかりません!w
が、しかし。情熱や思いは多少は伝わったのではないかな、と思ってます。
エンジニアだけでなく、仕事をして未来へ何かを繋げていく生き物である以上。インプットアウトプット、すなわち成長を続けていかねばなりません。
成長を辞めた時、それは召されるときなんだろうなって思います。
僕自身、70歳まで現役でいられるには、を常に念頭に置いて考え、周りをみて、行動しています。
現在45歳。業界に入った年数から言えば、70歳までの折り返しあたり。
これからも、僕の行動原理である 行間を埋める技術 をずっとアウトプットし続けていけたらな、と思っています。
この思い、行動、情熱。誰かに届いて、1人でも多くの人が楽しく幸せに思ってくれたらな、って心から思っています。
ときには今の僕のように息抜きしつつ。
一緒に頑張ってみませんか?
奥さまのイラスト集
時間と気持ちに余裕があったら、大量のスケッチをトレースして掲載してみようかなっと思ってます。僕が癒されるので。
記事とは直接関係ないことが多いですけど!
学習記録:12月1日(土):はじめよう!要件定義 Chapter-01&02
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の1日目のエントリーです。
勢いで作ったからには勢いで走りきるしかない!
ということで、今日の学習記録としてのインプットアウトプットです。
はじめよう!要件定義
僕が所属している 合同会社ねこもり のボスでもある @NEKOGET さんからの紹介の書籍です。
これから仕事を進めていくにあたり、僕自身が、要件定義を効率的かつ体系的に実行していく必要がありました。 そこで相談したところ、課題図書に設定された感じです。
まだChapter01と02しか読んでいませんが、ごくごく当たり前のことだけど、できてない人が本当に多い。そんな内容を立て板に水を流すように丁寧かつだんだん噛み砕いて解説されていく。
本来の要件定義とはなんなのか。クライアントの要望を形にするってことはどういうことなのか。
何かをやりたいと思う気持ち、こんな風だったらいいなという情熱、それらを形にするために技術者が最初にやるべきこと、それが要件定義なのだと思います。
ほぼ手のひらサイズで、かつコンパクト。しかし、僕のように雰囲気で要件定義してきた人間にとって、こう体に筋が一本通るような。 そんな内容になっていると思います。
読み進め
僕は書籍を読むとき、いつも esa (個人で契約して使っています。情報共有ツール。月額¥500)にMarkDownで記録しています。
登壇した際に少し触れたこともあるのですが、読むという行為でインプットした内容を、書くという行為でアウトプットする。
そこで不明な点が出てきたら、調べて補足する。思うところがあったら感想を書く。より理解するために原文と意訳を書き込む。
それを繰り返すことで、自分の中に刻み込んでいます。もっとうまいやり方があるとは思うので、僕が主催側にいる 読書の技術を勉強する会 #1 で改めて学ぼうかと思ってはいるのですが、今のところは7ヶ月以上続けてきて、一番手に馴染んだこの方法で学習を進めています。
最後にその日のまとめとして、Tweetして、僕の1日のアウトプットは完了する感じです。
というわけで読み進めたメモを公開してみます。
第1部 要件定義ってなんだろう?
Chapter-01 要件定義=要件を定義すること
まとめた内容を公開してみます。半分以上が書籍の写経になるので、公開に問題があればURLを閉じるとは思うのですが、これを読んで「お、自分も読んでみよう」って思ってくれたらいいな、と考えてます。
読んだ結果
内容はesaの内容や、実際に書籍を購入してみて欲しいなって思うのですが、Tweetを引用するとこんな感じです。 だいたい複数Tweetを連結させているので、ざっと並べてみます。
今日は「はじめよう!要件定義」を読み進め。システム的に言えば「発注側と受注側の間で合意した納品検収条件」となるのだろうが、無理に短く表現したところで、できるべき人の全員ができるわけではない。じゃあ詳しく言うと…(続く
— まみー (@mamy1326) 2018年11月29日
依頼した人が
— まみー (@mamy1326) 2018年11月29日
出来上がったものに対して
「これならOKです」
と言うために
「何がどうなればいいのか」
ということを明確に定めたもの
なるほど、となる。
世の中の仕事には必ず要件があって、それを事前に定めるからこそ成立する。以心伝心はあり得ない。ましてや依頼者は専門知識がない。専門家は実現可能性を検討する必要がある。そこで要件定義なんですよ、という内容が立て板に水を流すように順番にわかりやすく解説されている
— まみー (@mamy1326) 2018年11月29日
自分もちゃんとできてるわけじゃないし、できてない人はすごく多いだろうし、そもそもお客と話したがらない人も多い。それが良い悪いじゃなく、ポジションに関わらず「要件を定義して合意して仕事をする」のが基本なんだよ、という意識で読み進めたい
— まみー (@mamy1326) 2018年11月29日
転職してから、要件定義の場に出ることが多くなったし、これができてないと今後のエンジニアとしての仕事の広がりも期待できないと常々思っているところ、吾輩のボスに「課題図書であーる」と託宣いただいた書籍。明日はChapter2、要件定義の基本的な流れ、を読み進めるぞ!
— まみー (@mamy1326) 2018年11月29日
いただいた反響
吉祥寺.pm の主催者でもある @magnoliak さんからリプいただいたりしました。
このかたは設計について非常に見識が深く、また実践的な発表もされておられて、設計について何時間でも語れるすごい人です。 設計についてそれだけの思いがあるんだから、当然要件定義についても一家言ある。本当にありがたいなって思います。
Twitterのすごいところはこういうところだぞ!と僕は言いたい!
人と人とは「簡単には」わかり合えないっていう前提で、っていつも言います
— magnoliak (@magnolia_k_) 2018年11月29日
お互いに驚くくらい思い込みによる暗黙の前提で喋っている
あと、関心があることしか喋ってない
僕も考えるところ、過去の経験から思うところがあったので、リプをお返ししたりしてました。
暗黙の前提、つまり「わかるよね?」で話しますよね。で、関心がない=実は実装しなくちゃいけない、考慮しなくちゃいけない、ってことが抜けるけど、システムのプロじゃないから抜け落ちるのが当たり前であり、そこを埋めて提案するのが我々の仕事なんだよな、ってリプをみながらしみじみ思ってます!
— まみー (@mamy1326) 2018年11月30日
Chapter-02 要件定義の基本的な流れ
章単位で分けて記録することが多い(じゃないと長大になる)ので、Chapter-02は別のエントリです。
読んだ結果
ただ書き出すんじゃなく、個人のつぶやきとして公開することで、インプットとアウトプットの回転が1回回る感じがしています。なので、毎日何かしらTweetするんですけど、毎回長いよなあと思ったり思わなかったりしつつ「Twitterだしいいか!」とか思いつつ好き勝手やってたりします。
今日は昨日に引き続き「はじめよう!要件定義」の第一部 Chapter-02を読み進め。要望が出てくる流れから始まり、要望とは人の思いであり、その思いを外に出すのが要求。これが出て初めて、我々はクライアントの要望を知ることになる。
— まみー (@mamy1326) 2018年11月30日
要望が要求として伝わったら、実現可能性含め検討が始まる。ここで大事なのは、できないことの代替案を出すだけじゃダメで、できることでも「専門家視点でのより良い代替案」を検討すること。大抵の依頼者はただ注文を受けてくれるのではなく、専門的な知見を求めている、と。
— まみー (@mamy1326) 2018年11月30日
続いて大事な点として「代替案を出す=相手を否定する」ことになるので気を配る必要があること。なぜ代替案を出すのか、相手の言葉で、伝わりやすい図解も交え、判断までのプロセスとレポートを提示することが大切と理解した。そしてこれこそが「提案」であると。
— まみー (@mamy1326) 2018年11月30日
この要求から検討、提案、の流れは1回ではない。何度も繰り返すことで、最終的な「要件定義」として「双方合意」することができる。このプロセスを双方が面倒がらずに丁寧にやる。阿吽の呼吸の関係などない。人間同士が「簡単に」わかりあえないのはこの言葉に集約されるなあ https://t.co/9Hd7ZH2o98
— まみー (@mamy1326) 2018年11月30日
「目先の面倒くささから目を背けない」ことこそ要件定義に必要であり、要件定義とは「良い仕事を一緒にしていくための知恵 」である、ということで章が結ばれている。提案から要件定義の業務であれば四半世紀関わってきたけど、多分初めてきちんと解説を受けていると思う。
— まみー (@mamy1326) 2018年11月30日
大抵の依頼主の要望は、何かをよくしたい、こんなのがあったら良いな、という善意からのもの。それが誰かを幸せにするからこそ専門家がいるわけで、そこを丁寧に対応できなければならんのだよな、って思いはずっと変わらない。そんな中で読んだこの書籍は良いものだなーと思います。
— まみー (@mamy1326) 2018年11月30日
思うこと
要件定義ってお客さんとの対話なんだよな、って思います。 これって、お金を得る、つまり仕事をする人には全員必要なことなんですよね。
プログラム書いてれば良いのかって言われるとそうではなくて、それは社内のプロジェクトマネージャーからの要件をヒアリングする必要があるし、それに対して疑問点を聞いたり代替案を出したりするよね、と。
んで、それを拡大していくと、お客さんとの対話になる。
この考えかたって現場で忘れられること、そこそこあるよなって思いながら読んでました。
僕自身、この考えかたが100%できているわけでもなく、なんとなくやってて、なんとなくできてて、実はできてないこともあって。
ずっと仕事を続けていく以上、要望に応えることこそが根底なのだぞ、というのを今以上に思い定めて行かなくちゃなって思ったりしてました。
当たり前のことでも、改めて学ぶ価値もあるし、必要もある。 技術はどこかで必ず繋がっている。
日々のいろんな分野の学習を続けていけば、いずれ繋がる時が来る。
それが昨日より少し信じられるようになったかなー、とか思いました。
吉祥寺.pm16 で登壇してきました (後編 3/3)
後編 2/3 の続きです。
あとは自由に感想などをつらつらと。
嬉しかったこと
その1:グラレコしてもらった!
たかのあきこ@まだ芽は出ないぞ さんにグラレコしていただいてた!しかもこうしてハッシュタグを見返していて気づく体たらく。。。 今度お会いしたら丁重にお礼を申し上げねば!
#kichijojipm (メモ2)
— たかのあきこ@まだ芽は出ないぞ (@akiko_pusu) 2018年11月22日
i47_rozaryさま続き、良い開発現場を作りたい、そのための育成について。まみーさま、インプットとアウトプットのサイクルを回しましょう。発表への不安は入念な準備と練習を持って臨むこと(凄い!) pic.twitter.com/K6QrvZWgJH
#kichijojipm (メモ3) まみーさま続き、会場でのチェックも念入りに。誰かの背中を押せたらいいな。
— たかのあきこ@まだ芽は出ないぞ (@akiko_pusu) 2018年11月22日
papixさま、はてなエンプラ向けCMS開発のスクラム開発、その後どうなったかのお話。新規開発的な場合と継続改善のための場合とで、スクラムの手法も合う合わないがある。守破離でやっていこう。 pic.twitter.com/jwumlr8qAl
なんと今までのグラレコをこちら にまとめておられる。僕の上司に当たる人もグラレコしていて、こういう人は本当にすごいなー。尊敬する!
その2:ご挨拶をいただいてしまった!
うちる さんにご挨拶いただいた!すっごくご丁寧に!なんだか恐縮してしまうとともに、人前で話してきてよかったなー、少しでも何かを伝えたりできてるんだなー、と実感させていただきました。
あと、僕こう見えて人見知りなもので、もっとちゃんと話せたらなあと思いつつ、席も近かったのにあんまり話せず…。今度は僕の方からご挨拶させていただきますよ!
あと、うちるさんのこの言葉にイベントが集約されていると心底思いました。
今日いろんな勉強会が開催されてみんな楽しい思い出を胸に帰路についてると思うのですが、私はきちぴーが一番楽しかったです。みんなが同じ文脈を持っているわけではない場、貴重じゃないですか #kichijojipm
— うちる (@hika_riru) 2018年11月22日
その3:設計NIGHTの再演を視聴できた
恥ずかしながら、最近設計思想がわかるようになってきた。なので設計NIGHTはどうしても行きたかったけど行けなかった。 その再演を視聴できたのはすごく嬉しかった。早めに行けてよかったー。
感想は前編に書いたけど、もっとちゃんと読み返さないとな、と思ったし、普段設計する際にいろんな資料を読み返すクセをつけておきたいなって思いました。
その4:めっちゃTweetしてもらった!
いやー、話している時ってこう、時間と聴講してくださるみなさんと、話のつながりと、とかで実はいっぱいいっぱいなんですよね。なので実際みなさんがどう思ったかぶっちゃけわからない。頷いてくれたり笑顔だったり「わかるー」って表情だったり笑いだったりはもちろんわかるし、反応もらえて僕もテンション上がるし楽しいのだけど、一人一人に感想を聞くわけにも行かない。
で、席に戻ってタイムラインを見るわけですが、めっちゃTweetしてくださっている…!
いや、ほんと嬉しいですよねこういう瞬間。聞いてくださった全ての人に感謝です。聞いてくださる方がいるからこそ登壇できるってもんです。
これだから登壇はクセになるのさ!
懇親会
毎回参加できてるわけじゃないんですが、前回の懇親会で行ったお店と同じだったような気がする。確か@yoku0825さんと@soudai1025さんがキャッキャウフフした回だ!
とか思いながら まこぴーさんとずーっと喋ってた気がします。なに話したんだっけ…すっごい楽しかった記憶だけが鮮明にあるんだよな…前日ほぼ寝てない状態で飲んで、お酒が濃くて記憶が曖昧だぞ!
でも楽しかったし肉は美味かったし! あっという間に23時過ぎ。解散の時間を惜しみつつも帰路についたのでした。
帰り道
僕は京王線沿線に住んでいるので、井の頭線に乗るんですが、明大前までご一緒させていただいて、ずーっとお話させていただいた方がいらっしゃいます。 が、わたくし、天性の 顔と名前を一致させられない病 に冒されていまして…。次にお会いした時はちゃんと名前をお聞きせねば!と今更ながら心に誓ったのでした。
さいごに
また行くし、次はテックな内容で話すぞ! Perlは…たぶん話すことないんだろうなーと思いつつ、でもどこかで使うことになるかもしれないし。技術はもちろん追い続けるので、その時にアウトプットしたいネタとテーマが繋がっていたら積極的に話していこうと思います!
スケジュールが合う限り行き続けようと思ったのでした。
吉祥寺.pmに関わる全てのかたに感謝!ありがとうございました!!
吉祥寺.pm16 で登壇してきました (後編 2/3)
後編 1/3 の続きです。
Talk3: スクラムマスターやってみた(papix)
前々回 でお話しされていた スクラムやってみた の続編でした。
冒頭で 続いていなかったらここにいないので、ちゃんと続いています とのことで、ワクワクします。 今回も泰然自若とした独特の語り調で、やはりこう漫談でも鑑賞しているのかなという気にさせるんですが、内容は濃密そのもの。
スプリントは1wから2wになった
やはり1wは早すぎるんだろうなあと。僕もやったことあるけどやはり2wになったなーと思うなどしてました。 計測できる一定の期間ってあるよなあ。
カンバンが物理になった
前回はgithubのprojectだったっておっしゃってたけど、Issueがあるし、ユーザーストーリーとタスクが混じるので物理になったとのことでした。
でもリモートの人が多い場合だとどうなるかは今でも気になるなあ…と思っていたら以下の方法で実践されてるかたもいらして安心。
自分のところは, GitHubProject + Asanaでやっています。 #kichijojipm
— micchie🍻WWGT (@micchiebear) 2018年11月22日
デイリースクラムがある
座るってのMTGスタイルだと、どうしても長くなるよな。毎日必要なものだから実施するのはわかるけど、だからこそより短く。 というわけで物理カンバンの前でスタンディングにした結果、シンプルに早く終わるようになったとのこと。
とはいえ雑になるわけでも大事なことがすっ飛ばされるわけでもなく、ちゃんと振り返りで気持ちの共有とかしてるところはさすがだな、と思いました。
企画(ユーザーストーリー)と開発タスクのカンバンがある
次のスプリントに何が入ってくるのか、それがどのくらい練られているのか、どのくらいエンジニア側に共有され対話されているのか。 そういったことを重視した結果、カンバン(というかレーンかな)が分かれたってことなんだろうな。
企画カンバンはユーザーストーリーのIssueが集まる、次のスプリントどうするか、オーナーの説明をバックログ整備会をスプリントの真ん中に実施。プロダクトオーナー準備完了レーンが次の優先度の高いもの。なるほどー。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
対話を重視する
ユーザーストーリーを考える側との対話を重視する、というのも非常に共感を持てました。 何より「本当に必要なのか」とか「やるならどこまで」「エンジニアとどのくらい共有できてる?」が明確になっていくので、よりスクラムが回るよな、って思いながら聞いてました。
きっとこの一文に集約されてると思います。
ユーザーストーリのブラッシュアップができる段階、実装の検討が必要な段階を経て、準備完了(開発に着手できる) #kichijojipm
— める@12/16はアンサンブルコンテスト! (@c5meru) 2018年11月22日
KPTは飽きる
わかるし、形骸化するし、毎週とかやる意味がない場合もあるよなって思いつつ。たぶん月イチくらいで良いんだと思う。大事なのはKPTよりも、きっと気持ちや状態の共有なんじゃないかな、と思っていたら次にその話が出てきて「なるほど!」ってなってました。
重視すべきは出来事、気持ち、投票
タスクやってる時どういう気持ちだったかとか共有するのすごい大事だよな、カンバンやってスクラムやるんだからそれがないと意味がないよなって思いました。 僕も経験したことあるんですが、なんか不安だったり、しんどかったりするの、タスクを実行してる時はわかるんですけど、じゃあ振り返りってなったときって忘れてるんですよね。
なので、振り返りシートに感情を込めて書いていって、気持ちの欄を作って、出来事と気持ちを書いてよかった悪かったを数値化する。 あーすごいなこれ。それをみんなと共有するのがすごいなって思いつつ、良いチーム作ってるなーと頷くばかり。
感情を見える化すると、その時のチームの状態とリンクしていることに気づいたりするとのことで、今後人が増えたりしていった時に参考にしたいな。感情を色分けするってのもすごい。
そしてやはり、これ大事だなってタイムライン見ながら思いました。
プロダクトオーナーからのコミットメントが自然に達成されるような仕組み作りの重要さをひしひしと感じる。 #kichijojipm
— Korenari (@Korenari_D) 2018年11月22日
あと、同じくタイムライン見ていてこれ良いなあって思いました。
弊社のKPT、Keep Problem Try と ありがとう(最近GJになったけれど)があって、会がほっこりした感じになる #kichijojipm
— トーカナイザの守護霊 (@mackee_w) 2018年11月22日
アジャイルやスクラムにゴールはない
僕の意訳ですけど、進み続けるわけだから、ゴールはないんだよな。本とは違う現実があって、そのチームのやプロダクトの特性、オーナーが求めるもの、感情、などなど、数値化して見える化してこそ、みんなどんな気持ちで仕事してるのかわかる。
それってやっぱり人間同士がやってるからだよね、ってことを教えてもらったような気がします。
Talk4: 起業クエスト(Yoshitaka Kawashima)
このかたのトークというかプレイというか、筆舌に尽くしがたい! 今までの登壇スタイルを根底から覆しつつ、圧倒的な実装、物量、丁寧さ、情報量をこれでもかと伝えてくれる。
トークはRPGツクールで作った「起業クエスト」を実際にプレイしながら、起業のために必要なものを解説しつつ、しんどかったこととか大事なことをしっかり丁寧に「ゲーム内のコンテンツやアイテムとして」伝えてくれました。
いやー、これはすごかった。 だってね、登壇者が持ってるの、PCじゃなくコントローラーなんですよw
しかも「BGM必要ですよね」ってスマホでドラクエの音楽流したりして、アドリブもすごいw
しかしまだ途中までの内容だったようで、オチが黒塗りの車に衝突して終了w
ギットクエストの作者さんでもあるらしく、ここでプレイできます。
起業クエストの公開も待ち遠しい!
LT3: プロキシサーバを作って覚えるHTTP(tsucchi)
Perlでプロキシサーバを作って覚えるHTTPということで、様々なハマりどころとソースコードでわかりやすいトーク。
確かにPHPとかだとあんまり意識しないかもしれないなーと思いつつ、Real World HTTPを読み進める時にGoでHTTPサーバ作って色々試したなー、本の内容にもHTTP通信の大事なところ書いてあったし、それやってなかったら理解が曖昧だったな、と思いながら視聴しました。
やっぱり作って覚えるのが一番!
LT4: なぜ私はPerlでコーディングするのか@吉祥寺.pm16(Korenari_D)
理由:「はやい、やすい、うまい」
確かにPerlは宣言など特にしなくとも、いきなりif文とかに正規表現が使えるんだよな、15年前に使ってたなー、と思い出しながら聞いてました。
いやこれすごく便利で、おかげで当時は正規表現を難なく使いこなせてたんだけど、今じゃすっかり落ちぶれてしまった…。
この正規表現リテラル、正規表現を言語処理系でコンパイルして使い回すそうで、実行速度が向上するそう。なるほど全く知らなかったぜ。
LT5: 転生したら会社がわかれていた件(setoazusa)
安定のせとあずさん。
緊急で全社員にお伝えしたいことがあるので集合、と言われて悪い予感しかしなかったら、10周年記念で会社を分けるという話からスタート。なぜw
毎回面倒ごとを引き受けては解決していくその姿は、もうポジティブさしか感じない、という5分間でした!
自分でやりたい方向に調整していくのすごいよなあ。
LT6: スタートアップで 開発速度を上げるためにやった事(kakakazuma20)
スタートアップ、限られたリソースで速度をあげるつらさ。 それを1年半頑張った結果を発表とのことで楽しみ。
iOSとAndroidの開発効率について、iOSで開発して有用な機能ならAndroidへ。その際の開発担当は同じ人間にする。なぜなら知見も仕様も把握していて、開発工数が減りバグが少なくなる。
UseCase層のコードはかなりの部分で使いまわせるそうです。なるほど! Swift/Kotlinで関数名、変数名も可能な限り同じにできるらしい。
次は採用の話。お試しで働いてもらう制度があるそうで、これは本当にいい取り組みだと思う。 僕も以前面接受けて内定いただいた会社さんで1日就業をしたのだけど、そのおかげで中の雰囲気やサポート体制、チームの状態、雰囲気、自分が働くことの想像、など、可能な限りの現実を体験できるんですよね。
当然こちらの技術力や人柄もわかるわけで、お互いにとっていいことしかない。
体験就業の場合に気をつけてることは、
- 基本リモートだけど週一でMTGしてご飯にいく
- コミュニケーション多くして好きになってもらう
- 強いコミットは求めない
- とはいえ期待値は伝える
- 成果じゃなく時間ベースの報酬
- 相手が業務中に返事が必要なコミュニケーションを求めない
- 相手が退職してないからかな?
- 自分たちで巻き取る覚悟をもつ
とのこと。すごく考えられていてルール化されていて、ちゃんと運用されて実績あげてるんだなあ、ということがわかる内容でした。
今後受け入れ側になった時、参考にせねばと思いました。
LT7: エンジニア、こわくない(sironekotoro)
エンジニア以外の立場から見たエンジニアについて、ということで。遭遇したエンジニアの第一印象「めっちゃ怖い」w
人によるしなんとも言えないけど、突き刺さるような雰囲気を纏ってる時って確かにあるある。僕もないとは言えない。 あーなんかこう、みんなの前にいる時は「いつでもウェルカム」という空気を出すよう心がけているのだけど、それ以上にSlackなどでフランクに冗談を交えながらも会話が毎日進んでいくような環境なら、怖いってこともかなり少なくなるんだろうなと思ったりしました。
で、エンジニア以外っていうけどこのかた、エンジニアを知るためにエンジニアリングを学んで知識水準を合わせて行ったってのが本当にすごい。尊敬します。
CSをやられているだけでも、お客さんのフロントに立ってくれているからこその部分も大きいのに、Linux勉強したりして、親しみを覚えていくのって本当にすごいです。
でも僕としては、できれば両方が歩み寄れればいいなって思います。
エンジニアに聞く前に共通言語を増やしてコミュニケーションを円滑にする。エンジニア側としても見習いたい。どっちも仲良くなればいいじゃないって思ったりする。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
あと、最初から優しいエンジニアもいたw とか、知識が上がると転職して行ったw とか、笑えないけど笑っちゃうところも素敵でした。
LT8: 隙間家具OSSのすすめ(fujiwara)
リアルfujiwaraさんを拝見するのは初めて。鎌倉から参戦とのこと。隙間家具OSSの話として、新しい技術を採用すると、技術の隙間がまだ埋まってないことがある。
だから自分で作るのだけど、それをOSSにしちゃいますよってお話でした。
隙間家具は不要になったらサクッと外せるように作る。運用改善して適度に汎用的にして、技術採用の本家が隙間を埋めたらサッと外せる粒度で作る。
実際に作った実例の解説もあったし、実際に数年動いていてその間は業務効率に貢献してたし、隙間家具がやっていたことは本家が埋めても似たような内容になるので適用しやすいんだろうなあ。
で、なぜOSSにするのか。これまた重要な話でした。
- ドキュメントを書く気になる
- READMEくらいは頑張れるモチベーションに
- 過度な社内事情の混入を防ぐ
- 責任分界点を見極め、将来外しやすくなる
- 設計が綺麗になる
- 社内の事情が入っていくと切り離せなくなったりしますよね
- 魔改造が増殖するのを防ぐ
- 独立したパッケージになってるのでそのまま使ってもらえる
あと、OSSを許可してくれる会社にも感謝っておっしゃってたかな。社外秘のないコードって実はたくさんあって、ツールとかはもっと公開しようよって思うことが過去に多かった。
なのですごくわかるなあ、いい文化が今後も広がってくれるといいなあ、と思いながら聞かせていただきました。
あと最後に、本家へのリクエスト大事だし、言えば対応してくれることもあるよ、とのことでした。
AWSのサービスの隙間があったら、要望を送ると優先的に作ってくれることもあるとのこと。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
全体の感想
尊敬、感謝、がすごく多かったなって思いました。 皆さんの技術力がすごいのは当然ながら、頑張って結果を出した内容だったり、寄り添って「人」を見たり、当たり前なのだけど続けることの大事さだったり、なんていうか、 働く人の人生を垣間見る イベントだったなって思います。
仕事は人生からも生活からも切り離せない。だからこそそこにいる人たちと頑張っていくために何をしているのか。 業界を世界を技術をよくしていくにはどうしたらいいのか。
そんなことを着実に、かつ楽しく、効率的に、でも人間らしく実践されている方達だったなあ、って思い返しています。
本当に楽しかった吉祥寺.pm、でもまだ終わらないんですよね。
トークの合間、休憩時間、撤収中、懇親会。
そこでの感想も次に書こうと思います。
というわけで次に続きます!
吉祥寺.pm16 で登壇してきました (後編 1/3)
前編からの続き です。
というわけで聴講したトークの感想をつらつらと。 ここでも長くなったので、なんと後編を複数に分けるという暴挙に出たことをお許しください。
せっかくインプットもらったんだから、丁寧にアウトプットしたいんだよぅ。
LT1: エンジニアのいない世界線へ行った話(umaaaaa)
ガチの人形屋さんへ転職したエンジニアさんのお話。印象に残ったことを箇条書きにしてみます。 LTですが、5分とは思えない濃密なお話でした。
- 転職先は古代文明だった
- でもそういう会社さんっていっぱいあるよね
- 社内のヒューマンエラーをなくすぞ!
個人的に印象に残ったのは最後の言葉。
- 人間はミスをする生き物
- ヒューマンエラーをヒューマンで解決しようとするな
- 仕組みで解決💪エンジニアの特権💪
- ドキュメントに残そう
LT2:Perlにおけるクラスの実装パターン(mp0liiu)
おおっ前半からPerlの話だ!しかもガチだ! 正直、Perlから離れて15年くらい経過してるので、話の内容をちゃんと理解できませんでした。 が、PerlのOOP、クラスの実装方法の種類とそのメリットデメリットがしっかり検証された内容で、これもまた5分とは思えない内容。
実際に動いて試したソースコードも掲載されていて、イメージしやすかったです。 こんな5分LTを自分もやっていきたい!と思いました。
Talk1: エンジニアの社会科(i47_rozary)
なんとうなぎ大好きなのにアレルギーで食べられなくなったとか。そんなことがあるんや…。
社会の助けになるサービスを作るため、1つでも多くの良い開発現場を作る
言葉で言えても行動にはなかなか結びつかないことを、ずっと行動原則として実践しておられる人でした。
サービスをただ開発するだけじゃなく、事業の成功を目指して動くこと。
育成の方針として、オリジナルの価値観を持ち思考できるようになってほしい。
- 分類:価値観を強く持っている人
- PMがボトルネックにならないように、しかし、本人の横の可能性をとじさせないように
- 分類:価値観を緩く持っている人
- 業務の全体を体験してもらう
- 会社の経営からユーザー対応まで可能な限り
- 全体を俯瞰できる基礎的な知識をつけてもらう
- ジョブローテーションに近いけど、サポートするってことかな?
- 躓かないように、可能性を広げるために構造を知ってもらう
マネージャーの役割としても僕がいつも思っていることを体現されていました。
- 育成戦略
- 成長実感
- 組織の成果に繋げる
- 環境を作って、個人の成長が組織の成長になるように
- しかし個人にフォーカスしすぎない
- 属人化するよね
- 時には厳しい評価もする
余談として、マイナスに舵を切るときもあるだろうけど、それは将来プラスに転ずるからであって、ただマイナスに向かうならただのマゾだよ、と。 今頑張らなくちゃ未来はないよね。未来がなければ今を頑張れないよね。
心に響く言葉をたくさんいただきました。僕も後押しをしたい、が行動原則なので、すごく共感できました。 行動の仕方は違うけれど、見習いながら自分もやっていきたいなって思わせていただいたのでした。
誰かを助けたい、同じテーマだけど内容被らなくてよかったー。それにしてもいい話だなあ。価値観持つ人はガンガン行ってもらうし、ゆるい人は業務の全体を体験し知ってもらう。これ大事だなあ。ゆるい=ゆるくしたいわけじゃなくて「よくわからん」ってことあるもんなー #kichijojipm
— まみー (@mamy1326) 2018年11月22日
Talk2: アウトプットを継続するためにやる10箇条(まみー)
前編 に解説っぽいことを書いたのでもしご興味あればみてくださると幸いです。
というわけで後編 2/3 へ続く!
吉祥寺.pm16 で登壇してきました (前編)
時は年末目前。なのになぜか予定を入れまくり。
というわけで昼はPosgreSQLカンファレンス、夜は 吉祥寺.pm へ参加して、登壇してきました。 懇親会も最高に楽しく、今回珍しく(?)いろんな方とお話しできたなあと思いました。
では参加レポートです。
アンカンファレンスタイム
今回は 24時間以内に登壇枠が全て埋まる という嬉しい異常事態発生だったため、急遽設けられたアンカンファレンスタイム。 自分の登壇申し込みが間に合わなかったらここで喋ってただろうなあ。
というわけで19時過ぎくらいに到着したら、 @magnolia_k_ さんが先日の 設計NIGHT でお話しされていた 設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜 を話されていたので滑り込みで聴講。
このイベントマジで死ぬほど行きたかったんですけど惜しくも抽選に外れたばかりか、補欠150番目とかだったので残念ながら諦めたんです。次回は本当にもっと広いところで開催していただきたいなと思ったりしつつ、他力本願でもいけないので、もしやるならスタッフ枠で行きたいとも思いました。 トーク枠は…まだ設計については模索中なのでネタはないかなあ。
途中からでしたけど、首がもげそうなほど同意できたし、特に自分に響いたことを列挙してみます。
- 暗黙知になりやすいもの
- 「手順」「歴史/根拠」といった事実
- 「事実・関係・原則」
- コードにはHow
- t_wadaさんの言葉
コードには How
— Takuto Wada (@t_wada) 2017年9月5日
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
- 関係はコードに埋め込む
- 膨大すぎる形式知は「形式知の読み方」という暗黙知を生む
- FizzBuzzEnterpriseEdition の話
他にもたくさんの言葉をいただいたんですが、本当にここに集約されてるなと思いました。
今日の発表、ほぼこの一枚でもいいんだけどね#sekkei_n2018 pic.twitter.com/brQlsQLYD7
— magnoliak (@magnolia_k_) 2018年11月8日
もうあとはみんな ブログ を読むんだ!
自分のトーク
9月にお話した アウトプットを継続するためにやる10箇条 という 登壇を後押しするためのテクニック を、今回は吉祥寺.pm16のテーマである 「エンジニアとして何を考え、何をみて、どんな行動をしているか?」 に沿って加筆修正した内容で登壇してきました。
エンジニアとして何を考えるか
2016年まではずっと暗中模索で、一体自分は何になればいいのか、どんな道を進めばいいのか、もしくは進まないのか、迷いに迷って行き先も定まらないままその場限りの開発に関わってました。
ですが、このままではいけない。しかし何をしたらいいものか…と悩んでいた時、業務でMySQLサーバーのチューニングをゼロからしたんですよね。 で、これがめっちゃ面白かったんです。ですが、最初は何していいかもわからず相当苦しかったんですね。
ここで、僕のように 最初の1歩が苦しい 思いをしている人がいるのではないか、と考えるようになりました。
エンジニアとして何を見るか
しかし果たして本当にそんな人はいるのだろうか、俺だけが簡単な階段さえも登れずにもがいているんじゃないだろうか。 でも同じ思いの人が必ずいるはずだ。 そう信じて、Qiitaに記事を書いたり、手元に詳細な手順やメモを残す癖をつけていきました。
その時に、PHP勉強会@東京の主催の方からお誘いをいただき、初LTをすることになったんですね。
じゃあ、自分が困ったこと、それを解決した話をしよう。 そして、反響が得られるかどうかやってみるしかない。そう思い、やっと 自分の外の世界と人を積極的に見る ようになっていきました。
エンジニアとしてどんな行動をするか
人それぞれの1歩 が人によっては めっちゃ高い階段もしくは壁 であることに悩んできた自分としては、初学者が初級者へ、初級者が中級者へ、中級者が上級者へ、それぞれ 階段を登る際の後押し をしたい。
そう強く思ったんです。
LTから15分、30分、1時間と、MySQLでやって行ったことを順番にお話しする機会にも恵まれました。 そこで得られた大切なことは、 自分のように初手で困った経験を持つ人がたくさんいる ということでした。
僕は過去、初手で何度も躓き、挫折して、無駄な年月を過ごしてしまいました。 なので、本来なら少なくとも10年前にはマスターしているべきことが、今できていなかったりします。
しかしエンジニアは 一生インプットとアウトプットを続ける 生き物です。 継続していくしかないし、継続したいと思う人の助けになりたい。背中を押したい。
これからの人へ向けた内容とメッセージを届け続けよう。この行動を エンジニア人生のテーマ にしよう。
そう思い定めたのが2017年の後半だったと思います。1年以上続けてきて、自分の思いや行動は間違っていなかったな、って確信することができた大きな1年だったとも思います。
継続するには
僕なりのインプットとアウトプットの輪廻を作るお話しもさせていただきました。 幸いなことに、前職のチーフディレクターと4月から3ヶ月実施した 毎日学習、週4LT勉強会 が習慣化し、現在7ヶ月目です。 そこで、以下のことを話しました。
- インプットアウトプットを回すために実際にやったこと
- せっかくインプットしたならアウトプットの1つとして登壇してみよう
- 自分の不安を知り、解決するための5つのこと
- 登壇するまでの僕なりのテクニック10か条
僕でさえ毎日できていて、継続的に人の前でお話させていただけている。 出来るだけ多くの人がこれができたら、きっと楽しくなるし、 楽しさことがモチベーション だと思うし、 楽しさこそが技術を発展させていく んじゃないかな、っていう思いも伝わっていたらいいな、と思います。
そんなわけでレポート書いてたらアンカンファレンスタイムと自分のトークの補足だけで分量が多くなってしまったんで、トークや懇親会の感想は後編で書きます!