天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「エンジニア育成勉強会LT+OST」に参加してきた

engineer-education.connpass.com

今日はこちらの会に参加してきましたので、会の様子と感想を書いていこうと思います。

会の概要

kawagoiさんが主催している勉強会で、名前の通り、エンジニアの育成に関してLTをしてから、エンジニアの育成に関してOSTをするという会です。
自分は今回、kawagoiさんから「LTをしてみないですか?」という話を受けたので、LT枠として参加しました。*1

LT会

LTといいつつ、自分も含めた皆さんがそこまで時間のことは気にせずに、10分くらい話していきました。
どの内容も面白く、エンジニア育成に際して持っておくと上手くいくかもしれないマインド、エンジニア育成を実際にした話...を聴くことができました。
具体的な話では、関係性構築のために気を付けるといい話やデリゲーションポーカーを使った権限移譲の話、見当違いの行動を後輩が取った時に使える実践的なテクニックや、リモートで新入社員や中途社員の支援の話が聴けたのですが、どれもLTで聴くのは惜しいくらい盛りだくさんの内容で参考になりました。

自分のLTに関しては、知識と経験が足りなくて最後に納得がいくところまで詰め切れず、メッセージの繋がり(論理性)や科学的根拠の部分含め、個人的にはかなり悔いが残る発表でしたが、発表までの過程で本を読んだり論文を読んだり、自分が育成についてどんなことを考えているのかを言語化できたりしたので、発表できて良かったと思います。知識不足に関しては、今後どんどん勉強して補っていきたいなあと思いました。

OST

「自信満々のエンジニアにどう接するか」「エンジニアブートキャンプあがりの新人に対する教育の仕方」「勉強の時間を確保するためにはどうすればいいのか...」という話をしていきました。

自信満々だけどあまり成果として現れないエンジニアにどう接するか

主観的な成功体験は持っているはずなので、できていない現状をあまり直視させず、未来の話からスタートするといいんじゃないか、という話が出てきました。
また、フィードバックが上手くいかなかったパターンとして、影響を非難されているのに意図が非難されていると勘違いしてしまうパターンがあるという話をRyoさんがしていて、大変参考になりました。
また、このテーマに限らず、個人の許容値を超えて関わっていないか(育成した結果、個人のメンタルがやられてしまわないか)を見極める力も大切という話を聴いて、なるほどなあと深く共感しました。

エンジニアブートキャンプあがりの新人に対する教育の仕方

派手なことはできるものの*2、コンピューターサイエンスに近い部分の基本知識がないとか、インポートの仕方を知らない、みたいな状態の人にどう教育するか、という話をしていきました。
体系的知識を学ぶという意味で、資格試験がいいのでは?という話が出ていました。

社内で勉強の時間を確保するためには

最初は自主性を奪ってでもいいから、勉強会で結果を出して、社内に勉強する時間を広めていくきっかけを作っていくという話がありました。
また、結果を出すために、学習者には1on1を通して、どういう時にやる気がでるのかをヒアリングするという話がkawagoiさんからあって、kawagoiさんらしくて面白い話だなあと思って聴いていました。

全体を通した感想

LT会もOSTも密度が濃く、楽しかったです!
エンジニアの育成に限らず、育成に関して様々な話が聴けましたし、OST後の本編では、以前からTwitterでつながって気になっていたけども中々話ができなかった方ともお話ができたので、参加して良いことづくめでした。
また、kawagoiさんとkobaseさんには、お誘いいただいた後もLTの準備やたなんやらで沢山お時間をいただけて、感謝しかありません。
また次回も期待しています!

*1:エンジニア育成をした経験が殆どないのにLTする暴挙でしたがw

*2:Webページを素早く作るとかはできる

分散アジャイルチームでスクフェス大阪のプロポーザルを考えてもらった

distributed-agile-team.connpass.com

今日も分散アジャイルチームが主催している上のイベントに参加してきました。
今日のOSTでは、なんと自分のスクフェス大阪のプロポーザルを考えてもらったので、その話を書いていこうと思います!*1

スクフェス大阪のプロポーザルを出してもらおうと思ったきっかけ

スクフェス大阪しかり、フェスやイベントで登壇するのはまだ先になるのかなー(話せるネタがない)と正直思っていたのですが、前回の分散アジャイルチームの会で、及部さんから「なんでブログを書いているのかとか、なんでコミュニティに参加するようになっているのかという話を聴いてみたい!」と言ってもらえたのが、そもそもプロポーザルを出してみようと思ったきっかけです。
また、もしかしたら自分がスクフェス大阪で話すことで、コミュニティだったりに感謝を伝えられる可能性があるのかもな、とも思いました。

分散アジャイルチームでプロポーザルを書こうと思ったきっかけ

まずは一人で書こうと思ったのですが、どんな話を書くとよさそうなのかが中々思いつかず、一からプロポーザルを書くにはどうすればいいのか、ということも全然分からなかったので、モププロ*2して書いてみるのが良さそう、という結論になりました。
たくさんのコミュニティの方々にお世話になっているので、モブプロする場所についても悩みましたが、登壇の熟練者方がたくさんいる&一番自然体で落ち着いて話ができそうなコミュニティということで、分散アジャイルチームでプロポーザルを書いてもらうのを助けてもらおうと思いました。

プロポーザルを書いてみて

きょんさんに口頭で色々とヒント&アドバイスをいただきながら、テキストチャットで皆さんから書面で色々とヒント&アドバイスをいただきました!
以下に、印象的だった(参考になった)ことを箇条書きで幾つか挙げていきます。

  • サブタイトルに数字を入れて、メインタイトルには、このセッションを聴くと何が変わるかを入れると良い
  • 自分の言葉で、楽しそうに話せる様子が見れるような話が聴きたい
  • 他の環境との違いにフォーカスして、なんでその違いが生まれるかを書いてみると面白い
  • 参加者が自分事と捉えられるポイントがあると良い(Outcomeを参加者が得やすい)
  • 自分が過去に書いてきたブログを見ると、どんな言葉を使ってきているのか、どんなことを伝えたいと思ってているかが分かる

プロポーザルを考えてもらった感想

書いたことないしまずは皆さんの意見を聴いてみようという発想だったので、やや丸投げ過ぎたのではないかという大きな反省はありましたが、多数の意見をもらったり、こんな話が聴きたいなあと教えてもらったり、きょんさんのプロポーザルを考える時の思考の仕方に改めて触れられたり*3、とにかく楽しかったです。
書けそうな感覚がするところまできたので、土日にプロポーザル提出にチャレンジしてみようと思います。
時間があんまりないのが気がかりですが(笑)、あとは書くだけなので頑張ります!

*1:ちなみに、プロポーザルを考えてもらった後は、東京大学FoundXの動画ユニコーン企業のひみつの感想戦をしていきました

*2:モブ・プロポーザル

*3:以前きょんさんがnoteで配信されていたプロポーザル作成する風景は見ていたのですが、今回また新たな発見がありました

自分自身にもっと向き合いたい

最近、自分の中で起きた一つの変化として、「もっと自分自身のことを知りたい」「自分自身の感情に向き合いたい」と思うようになったことが挙げられます。
思考の整理をするために、こう思うようになった経緯を書いてみます。

完全に雑記で、システム開発と何も関係がないので、興味がある人だけ読んでいただければと思います。

子供(?)だった学生時代&社会人1年目

大学生までの自分は、良くも悪くも感情に忠実でした。
スポーツをやっていたというのもあるかもしれませんが、上手くいったときは思いっきり喜んで感情を爆発させて、上手くいかなかったときは泣いて悔しがりました。
周囲からは、ポジティブな評価では「熱い想いを常に持っている」と言われることもありましたし、ネガティブな評価では「幼稚」と言われることがありました。
感情を制御できず人に迷惑をかけたときは申し訳ない気持ちになることがありましたが、基本的にこの性質を直したいと思うことはありませんでした。

社会人になって、さすがに感情を表に出し過ぎることはあまりないようにしたいと思っていましたが、内面は全く変わっていませんでした。
先輩よりも早くバグの原因を見つけた時は心の中ではガッツポーズしていましたし、インフラ周りの知識について、同期がすいすい理解していく中、自分だけ理解が全然できない場面では、派手に落ち込んでいました。
しかし、そんな自分に、社会人1年目の終わりに転機が訪れました。

感情に蓋をすると楽になれると気が付いた1on1

社会人1年目が終わるころ、職場で自分の育成担当だった上司との1on1で、「顧客と話せるようになって欲しいから、その1stステップとして、顧客向けにシステムの仕様説明をする役割をいずれは頼みたいと思う。次の1on1では顧客に向かう前の練習として、私(上司)に説明して欲しい」という話をされました。
その頃はスクリプトテストの打鍵をひたすらしている仕事に飽き飽きしていたので、*1喜んで話を受けて、次の1on1までに自分にできる限りの準備をしました。
また、幸いにも学生時代の4年間は塾で講師のバイトをしていて、説明がすごい上手だと生徒からも他の先生からもフィードバックを受けていたので、人に対して仕様を説明する仕事にもそれなりの適性があると思っていました。

しかし、いざ1on1で説明をしてみると、論理的に説明が破綻していることや説明の順序が分かりにくいこと、仕様の理解が浅いことを次々と指摘され、とても顧客に説明できる状態ではないと判断されました。
自分自身のふがいなさが悔しくて、普段は表に出ない感情が涙となってその場ででました。涙を見た上司からは、「ここまで順調に人生を歩んできて、まだ辛い経験が足りていないのかもしれない。これからももっとしんどい経験はあるので、自分なりに耐える方法を持っておかないといけない」という話をされました。

この話を受けて、自分なりに辛い経験に対して耐える方法を考えた時、自分が試行錯誤して一番うまくいったのは、「全ての感情に蓋をして、自分は何の才能もないし何もできることはないと思うこと」でした。*2
全ての感情に蓋をすることで、感情に左右されずに安定して仕事の成果を出せるようになりましたし、自分は何の才能もないし何もできることはないと思いこむことで、ネガティブフィードバックされた時のショックが軽減され、ポジティブフィードバックされたときに、「自分はもしかしてできるのでは」と思って自分に対しての期待値が上がることがなくなりました。

感情に蓋をすると仕事がうまくいった

感情に蓋をして仕事をするようになってからのおよそ3年弱の間は、順調に仕事が進みました。間違いなく上司のアドバイス&サポートのお陰なので、感謝したいです。
社会人1年目で入院したことで背負った負債を完済し、次第に任される仕事も大きくなっていきました。要件定義~運用保守までを一通り経験させてもらえたお陰で、どの工程でもある程度の価値を出せるようになりました。
また、学会に参加したり顧客と対話を重ねることで、強固なドメイン知識をつけることができて、その道のプロとして、業務を実際に行っている顧客や顧客の顧客に対してもドメイン知識面でアドバイスを求められるようになりました。

仕事の責任が重くなるにつれて、感情に蓋をしようという意識はより強くなり、感情に蓋をすることが成果を出す秘訣だという強固な思想を持つようになったと、今ふりかえると感じます。
また、周囲が過剰なストレスを抱えて次々と辞めていく姿も、感情に蓋をできないと自分も同じように壊れてしまうのではないか、という気持ちを後押しするきっかけになったかもしれません。

成果が出るにつれて会社でも高い評価をいただけて、(勿論この時も感情を殺しましたが)後輩からはどうすれば成果を出して高い評価をもらえると思うか聞かれたときは、「感情をなるべく殺して、自分は本当に何もできないとどれだけ思い込めるかが自分にとっては大事だ」と伝えたこともありました。

感情に蓋をすることへの疑問が生まれたきっかけその1~「仕事は楽しい?」という質問~

そんな自分が感情に蓋をすることに疑問をまず持ったきっかけは、他部署から来た先輩の存在でした。
その先輩はある時、自分に対して「置かれている状況を見ると相当大変そうに見えるから、メンタル面を心配している。最近仕事は楽しい?」と聴いてきました。
質問に対して、「感情を全て殺しているので、仕事で楽しいと感じたことは一度もない。ただ、感情を全て殺せているので、辛い状況も辛いと感じにくいから現状もそこまでメンタルがやられることはない」と自分は答えました。
その答えを聴いた先輩が表情を曇らせたような気がしましたが、その後に「いや~メンタル強いなあ~笑」と言われたので、その場は特に何もなく終わりました。

そこから少し時間が空いて、自分に対して評価のフィードバックをする場が訪れました。その時、質問をしてきた先輩がその場にいて「仕事を楽しむともっと上手くいくと思う。仕事で楽しいと感じたことが一度もないという回答は衝撃だった」という話をしてくれました。
そこで、先輩が表情を曇らせた理由が分かったと共に、本当にこのままでいいのか疑問を持つようになりました。

感情に蓋をすることへの疑問が生まれたきっかけその2~「言葉に感情があまり乗っていないような気がする」という感想~

社外のコミュニティに参加するようになり、素敵なめぐり合わせが多数ありました。
そのめぐり合わせの一つとして、自分のこれまでの話を1対1で話す場があったのですが、ここで「言葉に感情があまり乗っていないような気がする」という感想をもらいました。
そこで、これまでの経緯を思い出して、「感情に触れるのが怖いからかもしれない」という回答をしたのですが、それに対して、「でも、自分自身(筆者自身)が本当は感情のことを知りたいと思っているような気がする」という感想をもらい、そこではっという気づきがありました。

思い返すと、これまでの自分は、プロダクトであったり現場で起きている問題に対しては、真正面から向き合って、問題から逃げることなく仕事をしてきました。*3
それなのに、自分自身からはとことん逃げていて、本当は自分自身にも向き合いたいのに、恐怖から向き合えていないことに気が付いたのです。

自分自身にもっと向き合いたい

上記2つのきっかけを経て、今まで感情に蓋をすることで自分自身に向き合えていないことに気付き、もっと感情を味わい自分自身に向き合うことに挑戦してみようという気持ちが湧きました。
もしかすると、感情に飲み込まれてしまい大変なことが起きるかもしれないですし、感情を味わったことがないのでどうなってしまうのか不安もあるのですが、少しずつ味わえるように、日々感情が動いたことを日記として書きとめるようにここ最近はなりました。
自分自身に向き合えたときに何が起きるのかを楽しみにして、今後も努力を続けていきたいと思います。

*1:入社と同時に腎臓に難病が発覚して4ヶ月会社を休むことになって研修を受けられなかった影響もあり、配属先ではずっとスクリプトテストを手順通りに打鍵してエビデンスExcelに貼り付ける仕事をしていた

*2:ただ、感情を全て抑え込むと精神上鬱になりやすいというデータがあることを知ったので、プライベートでは思い切り感情を爆発させられるように、意図的に趣味を感情的なものにしました。

*3:大きな問題があると分かった時に、その場では解決できない, あるいは自分の力では解決できないと分かったとしても、どうにかして問題を解決したいと思い、役員の人に直接アポを取って相談したり、何かしらのヒントが見つかると信じて社外のコミュニティに参加したり...

「人が自分をだます理由~自己欺瞞の進化心理学~」を読んだ

読んでからは少し時間が空きましたが、「人が自分をだます理由~自己欺瞞進化心理学~」を読んでみて面白かったので、今日はこちらの感想を書いていこうと思います。

本の概要

大分雑にまとめてしまうと、人は隠れた(自分自身でも気が付かない)利己的な動機を持ち合わせていて、この動機が様々な不効率な行動を引き起こしているという話です。
この利己的な動機の存在には、他者は勿論、自分自身も気が付かないように脳がだましているという、衝撃的な仮説をベースにしながら、仮説を支持する根拠が多数載っています。

進化心理学の入門書的な位置づけの本で、断定的な言い回しや学者にありがちな読みにくさが文章になく、進化心理学を学ぶ最初の一冊としておすすめだということです。(byきょんさん)

読んでみて面白かったこと

多種多様な生物の行動や進化の過程

人間に留まらず、チンパンジーメタセコイアなど、多種多様な生物の行動と進化の過程が紹介されていました。
また、なぜそのような行動をするのか(なぜそのような進化の過程を辿ったのか)が併せて解説されていました。
自分が知らない話や、事例としては知っていたけども背景までは理解していなかった話が多数出てきたので、教養として面白かったです。

人間が取っている不効率な行動の数々

医療や教育...様々なコンテキストで、人間が取っている経済的に不効率な行動の数々が挙げられていました。
どの不効率な行動についても、利己的な動機が隠されている前提で考えると納得のいくものが多かったので、面白かったです。
また、事例の幾つかには、自分自身でも認めたくないけど認めざるを得ない動機も書いてあって、中々衝撃を受ける内容でした。

人が自己欺瞞する時の4タイプ

人は自己欺瞞をする時のやり方として、4タイプ(狂人,忠臣,チアリーダー,詐欺師)に分かれるという話があったのですが、これが面白かったです。
それぞれのタイプのような思考をしている時が、自分自身で思い当たる節があったので、素朴理論として理解できると共に、各タイプごとに、自己欺瞞することでなぜ有利に振る舞えるのかが書かれていて、自分のことを客観視する一つの視点になりそうだと感じました。
また、上手く使えば、置かれている辛い状況を、自分にとって楽しい状況に転換させることもできそうです。

 

利己的な行動に対して寛容になれた

本書の最後にあるまとめの章で、利己的な動機を自分自身でさえも見えないように隠していると仮定して、この事実をどう生かしていけば良いのかの提案が書いてありました。
本書を読み進めて、素直に書かれている事実を受け取ると、利他的に見えて利己的な行動をしていた自分にがっかりしてしまうのですが(笑)、このまとめを読んで、本書を読んで良かったし、人間であるのだから利己的でもしょうがないかなーと感じました。

例えば、他人が自分の意見や行動に過度に干渉してくることがあった時に、「あれこれ意地悪をしてきている」と捉えるのではなく、「生物の本能的に、力関係を境地ようしたいのかもしれない」と考えることができれば、大分イライラ度合いも抑えられそうだなあと思いました。

全体を通した感想

一般教養として面白い話もあり、衝撃的なデータもあり、読んでいて学びが尽きない面白い本でした。

また、利己的であることをただ肯定するわけではなく、「仮に利己的な動機であっても他者のために行動しているならそれは良いこと」「利己的である性質が人間にあったとして、犯罪や非道徳的な行動が正当化されることはない」と言ったような記述も幾度となくされていて、刺激が強めな内容に対してバランス感覚を崩されることがなく読めたのも良かったです。

「アーキ部#9~古典探訪 Warterfall~」に参加してきた

architect-club.connpass.com

今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

イベントの概要

古典リーディング企画、第1回目はウォーターフォールという名称のもとになったRoyceの「MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」です。

「そもそも、本論文ではWaterfallとは一言も言ってない」とか「工程の戻りを正式に定義したものだ」とか聞きかじりでは、そういうふうに言われてきた論文ですが、実際にはどうなのか? 何が書かれていて、何が書かれていないのか? 実物を読んでみて、生の言葉で理解してみましょう、という試みです。

 

会で印象的だったこと

Kawashimaさんが論文を事前に日本語訳してくれて、全体向けに読み上げをしていく形式で進みました。
論文の中で印象的だったことを以下に記載します。

ドキュメントの重要性

また、ドキュメントがどれくらいの量必要かが定量的に記載されていたのも、印象的でした。
500万ドル(当時の金額で概算すると15億)のソフトウェアであれば1,500ページくらいのドキュメントが必要だろうということです。勿論、ページ数がいくら多くても、かさ増しされてしまっていたら意味はないですが...
1970年代での話ということを踏まえると、そこまで違和感はない(むしろ少なめと感じるのでは?)と思いましたし、システム関係者の共通理解を形成するという意味で、ドキュメントの重要性を改めて実感しました。*1

ウォーターフォールというイメージから離れた記述が50年前の論文にあった

2回工程を繰り返そう(プロトタイプを事前に作って顧客に見てもらおう)という主張や、できるだけ早い段階で顧客を巻き込んで商品を検証しようという話など、現代でも中々できていないことが、システム開発の成功のためにやるべき作業として定義されていたのに驚きました。
全体を通して、フィードバックが遅くなることで発生するリスクを低減するための提案が多かったのも印象的でした。
ちなみに、Royceがプロトタイプ作成に書けて良いと考えている期間は、リリースまでにかかる期間の1/3~1/4ほどでした。

マイナス記号や2の係数の欠落の欠落などは目視で管理すべき(コンピューターを使うには高価すぎる)という主張

今回のイベントで、時代の変化を一番個人的に感じた場面がこの部分でした。
マイナス記号の欠落などを目視で確認するというのは、今では有り得ない話ですが、コンピューターが高価だった当時としては自然な発想だった模様です。

シンプルなウォーターフォール開発で上手くいった試しがないというRoyceの主張

論文のまとめの部分で、シンプルなウォーターフォール(要件定義→設計→開発→テスト...)で上手くいくわけがないという主張がはっきりとされていました。

また、ウォーターフォール文脈の「手戻り」にコストを使うくらいなら、プロトタイプを開発したり、ドキュメントを充実させた方がまだ健全だという主張もあり、シンプルなウォーターフォールを、肯定しているというよりも否定していた点が印象的でした。

全体を通した感想

古典的な論文(原典)に改めて向き合うと、自分が理解していた内容とは全然違う主張が展開されていて、驚きと共にこれまでの自分の無知を痛感しました。

Kawashimaさんが論文を全部日本語訳した上に落ち着いた声でゆっくり読み上げをしてくれて、会の途中でお金を払わずして参加してて良いのかが不安になりました。
古典的な論文(原典)を読む貴重な機会を得ることができて、得られた学びも多く、参加していて楽しかったです!

参考資料

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS(ウォーターフォールという名称のもとになったとされるRoyceの論文)

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

【参考】マーチンファウラーのWaterfallに関する言及

ウォーターフォールプロセス

*1:論文中でドキュメントが作成されていないPJで起きる良くない兆候が記載されていて、耳が痛くなる話が幾つかありました

2021年4月のふりかえり

今日は4月のふりかえりをしていこうと思います。2021年ももう1/3が終わったと思うと、時の流れの速さを痛感します...!

4月にやったことを書き出していって、それぞれについてふりかえりをしてみたいと思います。

4月にやったこと

チームが長らく目標にしていた案件のリリースが無事に終わった

緊急事態宣言が明けて物理出社になったことや、チーム外とのコミュニケーションが多数必要だったこと、チームメンバーが途中で別PJに異動したこと...もあり、心身ともに大分疲弊しましたが、自分がやりたかったことが大分できたので満足しています。

具体的には、この案件で以下の経験ができました。(アジャイル開発を勉強して、これまでも意識してきましたが、中々「できた!」と言えない状態だったので素直に嬉しいです)

  • 不必要な作り込みはせず、顧客が価値あると思うものに集中して機能を作った
  • 顧客と対話を頻繁にし、プロダクトの価値や発生している問題に対して一緒に向かってもらった
  • 勉強してきたテスティングスキルの実践(探索的テスト、Pict masterを用いたテストの間引き...)

社外で個別にじっくりと対話する機会をいただけた

多種多様なきっかけがあり、オンラインでじっくり対話(1時間~5時間)する機会をいただけました。
話した内容はそれぞれで違うのですが、対話を通して自分のこれまでのキャリアや価値観を見直すことができました。
今まで漠然とがむしゃらに走っていた所から、少し立ち止まって自分のことを見直す時間が増えてきたのかな、と思っていて、自分の行動や思考にも確実に変化がありました。

オンラインイベントに参加した

今月は35個のオンラインイベントに参加しました。
土日はあまりイベントを入れないようにしているので、平日に1日1,5回程度のイベントに参加していたということなので、自分自身でも驚きを隠せません。
楽しくて話を聴いたり参加したりしているので、あまり無理をしている感はなく、自然と継続できている形になっているのがいいなあと思いました。

Write Code Every Dayを継続した

4月もソースコードを書くことを毎日続けることができました。ただ、継続こそしているものの、あまり技術的に何か力が伸びてきた感覚はなく*1、少し伸び悩んだような感覚が自分の中ではあります...

f:id:aki_M:20210502220739p:plain

ふりかえりカンファレンスで登壇(LT)した

人生初登壇ということで、ふりかえりカンファレンスでLTをしてきました。
3月に製造業アジャイルでLTを経験できて、順調にステップを踏めているのかな、と思います。
LT芸ができて楽しかったのはいいのですが、「面白かったけど、殆どのスライドを飛ばして何が何だか分からなかったww」というフィードバックを多数いただいたので、今度のふりかえり実践会のイベントで、ゆっくりとお話をしてきます。

retrospective.connpass.com

aki-m.hatenadiary.com

読書

9冊(2,430ページ)の本を読みました。先月と比較すると2/3位にペースは落ち込みましたが、自分が優先したいと思った他のことに時間を割いた結果なので、あまり悲観的には捉えないようにしたいと思います。
ただ、興味があった本を上から順に読んでいった結果、技術書をあまり読めなくて、これが技術力という意味であまり成長を感じなかった要因にもなっているのかな、と思っています。

毎日ブログを書くことを継続した

今月もブログを毎日書くことを継続できました。これはもう完全に習慣化していて、息を吸うように書くようになっていますw

5月にやっていきたいこと

NVCの勉強

NVC興味あるなら勉強してみたらいいかも?というアドバイスを、5月に話した人からのべ3回も聴いたので勉強してみようと思います。
NVCが何なのかがおぼろげに分かる位のレベルなので、果たして自分にあっているのかも若干自信はないのですが、学んでみようと思います。

もっと技術の勉強をしたい

あくまでも個人の主観に過ぎない話ですが、自分の現場では技術的な課題が中々解消できず、これがチーム全体を苦しめている要因になっていると感じています。
自分が特に技術的な課題を大きく感じた所から勉強を始めようということで、テストの勉強をスタートして、少しずつ現場にも生かせるようになってはきましたが、理想と現実のGapはまだまだ大きいです。

以前ブログに書いたように、自分はアジャイル開発が好きなので多少強引にアジャイルの文脈で言うと、「自分はこのままだとレフトウィングに寄りすぎてしまうのではないか?」「レフトウィングに寄りすぎるのは自分の目指したい姿なのか?」という問題意識を4月には改めて感じたので、5月は技術的な勉強をもっとしていきたいと思います。

*1:技術力向上のための一施策として、ソースコードを毎日書くことをしていました

GWにやりたいこと

GWが今日から始まりました!
自分は暦通りに出勤するので5/5までが休みとなっていますが、折角まとまったお休みがあるということで、やってみたいことを書いておきます。(プライベートな内容は除く)

色々やろうという気持ちだけ持ってGWに突入したら、初日がほぼ睡眠&だらだらで終わってしまい危機感を持ったので、ブログに書くことで多少メリハリを持たせるのが狙いです(笑)

LTの準備をする

尊敬しているkawagoiさんにお誘いをいただけたので、こちらのイベントでLTをすることにしました。(素敵な方であるのか疑問が大いに残りますが、素敵な方となっている枠ですww)

engineer-education.connpass.com

一応kawagoiさんとkobaseさんからヒント(?)をいただくことができて、候補はなんとか決まっているのですが、エンジニア育成とまるで関係がないので、何かイベントの趣旨に沿うようなテーマがないかを探る所からGW中に始めたいと思います。(探っても思いつかなければエンジニア育成とは全く関係ないテーマで喋ります笑)

新しい言語の勉強を始めてみる

技術力を伸ばすという意味で、新しい言語を学ぶという試みをしたいと思います。

触ったことのない言語ではRubyにかなり興味があって、入門書とかも充実しているので、是非勉強を始めてみたいと思います。

自分の価値観探求をしてみる

最近色々な方と話をしていて、今後のキャリアや自分の生き方を考える上で必要になってくるであろう、自分自身が大切にしたい価値観というのがまだ分かっていないなあと痛感しています。

具体的にどう探求するかの検討がまだついていない段階なので、これはGW中に完結させるというよりは、価値観探求探しの旅をスタートすることをGW中に目標としたいなあという感じです。

DevOpsDays Tokyo&ふりかえりカンファレンスの全セッションの動画を見る

先日チケットだけ買ってリアルタイム参加はできなかったDevOpsDays Tokyo2021について、まだ動画を見れていないセッションが多数あるので、これをGW中に見切りたいです。
また、ふりかえりカンファレンスの方は、リアルタイム参加していたものの、アウトプットレーンで行われていたワークの様子や、インプットレーンで一部ちゃんと見れていないセッションの動画*1やもう一度見返したいセッションの動画があるので、こちらも見返したいと思います。(ふりかえりカンファレンスの方はYoutube公開されて永続的に見れるようになっているはずなので、先にDevOpsDays Tokyoの方を優先したいと思います)

読書

読みたい本が山ほど積まれているのと、先月あまり本を読むことができなかったことがあり、本を読みたい気持ちが高まっています。
1日くらいは読書をする日を取って、3冊位を消化できたらいいなあと思っています。

スクフェス大阪のプロポーザルを考えてみる

スクフェス大阪のプロポーザルを出してみたい気持ちが、先日のdistributed_agile_teamの会で芽生えたのですが、こちらもまだ具体的なテーマが思いついていないです笑

何か会の趣旨に合うテーマで自分が話せそうなものがありそうなら、是非プロポーザルを出してみたいと思うので、GW中にまずはテーマを考えて、実際にプロポーザルを出してみることができれば最高だなあと思っています。

*1:自分が話すLTが近づくにつれて緊張してあまり頭に入ってこないセッションがありましたw