在宅勤務が苦手

とにかく自宅で集中できない。
ずっと前から、自分がそういう性質であると自覚していた。大学受験の時は風の日も雪の日も学校から20分歩いて塾の自習室に通っていたし、大学生の間は研究室に入り浸っていた。かといってその成果が出ていたのか、成績そのものについては言及しないけれど、とにかく外で頑張っていたし、逆に言えば、わたしは家で何もしなかった。積極的に家にいないことで、辛うじて社会性を保っていた。
家はだらだらする場である。
と、はっきり区別をつけているわけではないけれど、少なくとも無意識がそう思っていそうな感じがする。自宅では集中できない。

もちろんわたしは内向的な人間なので、一人の時間が大好きだし、自宅も大好きだ。全く活動しないわけではないので、ゲームもするし、趣味としての読書もするし、ごくまれに気が向いたら開発したりもする。けれども、さあやるぞとスイッチを入れ、勉強したり仕事したりする場ではない。
というか、スイッチが入らない。
まあ職場にいたところで、シャキッとしてるどころか、油断するとソファに転がってる程度にちゃんとしてない方の人間だけど、職場で一週間過ごしていれば間違いなく一日くらいは集中スイッチが入る時がある。あの力は一体どこから来るんだろう?

なんとなく、周りの人の存在が必要な気がする。監視の目というよりは、やるぞ!という雰囲気の方が。

あともうちょい真面目な話、在宅勤務という就労形態、自分の良いところがまったく発揮できてない気がする。思いつきで行動する感じとか。人とワイワイする感じとか。
在宅の環境では、やるぞ!やったぞ!みたいなスピード感が出せない。人と話していい感じになんかできたぞーみたいな謎のやつ、ない。
わたしは一応エンジニアだけど決して純粋な技術力で勝負できるタイプではなく(できたら困ってない)、たぶんチームビルディングとか、設計思想とか、要件の調整とかなんかこうフワ〜としたところで役に立てていたっぽいので……辛うじて存在している良いところが全滅してここにはいま虚無がある どうして(あの猫の画像がここに入る)

2020年、大リモートワーク時代。
生き方を考えなければいけないかもしれない。



すごくどうでもいいけどわたしは紙のノートに書く日記が好きです。1ページという限られた紙面の中に今日という一日をどうまとめようか、意外と筆が乗ってきたけど残り3分の1で書き終わるのか?うーんここからは字を詰め気味に書こうかな、みたいな紙と自分との駆け引きが好きなんですけど……というのは嘘で、終わりが決まっていないと永遠にまとまらず書き続け書き終わらなくて途中で飽きて投稿しないでお蔵入りする記事が無限に増えていくからなんですけど。1000文字くらいに収めるのが良いのかもしれない。だからTwitterのほうが性に合っているんだろうか……140字制限いいよね……

書くことは息をすること

ブログなんてものは気分です。書きたい時に書くし、ためになるかもしれないこともどうでもいいことも書く。

ここ3ヶ月くらいのことを振り返って書きます。

在宅勤務

Twitterでも何度も言ってるんですが、マジでびっくりするくらい向いてなかった。就職してから感じたことがないような調子の悪さ。意外と引きこもりが苦手だし、人と関わるのが好きだということに気付かされました。
退屈は人を殺す。冗談じゃなく。
6月になってからは週2程度出社することで、仕事の進捗も自分の状態もかなり良くなりました。
一点だけ、週5出社時代に常に胃痛だったのが在宅で治りました。それだけは良かった。ちゃんと正しい時間にごはんを食べましょう。
在宅勤務も良し悪し。

異動

4月に異動になりました。送別会や歓迎会をうきうき待っていたのですが、この情勢で流れてしまい非常に心残りです。
就職してから5年、ずっとjavaでDDDでサーバサイドアプリケーションの開発をしてきましたが、モバイル向けアプリ開発をやることになりました。
最近は勉強の日々です。この「学ばないと、身に付けないと死ぬ!」っていう感覚が久しぶりで嬉しい。*1
ここ1年くらいは悪い意味でこなしてる感があったというか、成長してなくても手持ちの武器でなんとかなってしまう感じが良くなかったので、今の状況は本当に自分のためになるなと思います。Flutter勉強する。

勉強

AWS SAAの資格を上半期中に取りたい。会社のお金で海外に行きたくて取ろうとした資格だけど普通にハンズオンやら勉強会やらでわいわい学ぶのが楽しくなってきた。ただこういう資格試験対策とかお勉強は苦手すぎる。どうやって受験を乗り越えたんだ?
友達に技術書のおすすめを聞かれて最近読んだ本のことを思い返したら、チームビルディング本しか読んでない気がしてきた。もしかして自分が一番役に立てる分野ってチームビルディングなの?あんなにやりたくなかったのに。

その他の近況

  • 麻雀を学び始めた。雀魂やってる。
  • Youtubeを見るようになった。ゲーム実況って意外とおもしろい。
  • あつまれどうぶつの森。ニコバンくんに会いたい。
  • PS4を買えたのでFF7をやりたい。ただしあつもりがやめられない。ポケモンDLCもストーリーのネタバレを踏む前にやりたい。とにかく忙しい。
  • 酒量が増えた。元々酒飲み家系だけどアル中には気をつけたい。
  • ふるさと納税を覚えた。

*1:入社から3年目くらいまではずっと、自分のOJTコーチがあまりにも忙しそうすぎて早く役に立てるようになりたい!という思いで必死でした。今の自分があるのはコーチのおかげです本当に

技術書典6でシステム設計・モデリングの本「もくもくモデリングの森を旅するチビドラゴンの軌跡」を頒布します

4/14(日)開催の技術書典6にてシステム設計(モデリング)の本「もくもくモデリングの森を旅するチビドラゴンの軌跡」という本を頒布します!

イベント情報はこちら
techbookfest.org

本について


モデリング技術向上に悩む新米エンジニアたちが一念発起。「もくもくモデリング勉強会」という自分たちだけの勉強会を始めました。
みんなで学び議論しあうこの勉強会は、モデリングの楽しみを教えてくれました。
これからモデリングを始めるすべての人へ、私たちの2年間の軌跡を捧げます。

・勉強会の進め方
モデリングの過程で作る図やドキュメントの作り方、解説
モデリングの観点、考え方
・よくある失敗モデルの事例
・勉強会向けのお題集

技術書典 サークル詳細より
techbookfest.org



システムの設計ってどうやればいいのかわからない、モデリングってどう勉強すればいいの?と悩む新米エンジニアたちによる社内勉強会が立ち上がる過程と、そこで2年間学んで得た成果と知見をまとめた本です。
これからモデリングを勉強してみたいと思っている方、初心者でも手に取りやすい、読みやすくわかりやすい本を目指しました。

勉強会をどう進めるか?という部分に関して、メンバー間の意識合わせやスケジュールの組み方を紹介したり、モデリングのプロセスと図やドキュメントといった成果物の作り方をなるべく簡単に、かつ具体的に説明しています。
また、モデリングをする際の観点や考え方といった部分についても、実際に勉強会で用いた例題を取り上げながら考察しています。
自分たちが迷ったり悩んだりした経験を元に、うまくいったことだけでなく失敗したことや今もまだ悩んでいることも交えながら書いています。これからモデリングの勉強を始めたり、歩き続けていくための後押しになる本でありたいという思いを込めて作りました。

会社名義での制作・頒布となります。本文の執筆はわたしが担当しています。装丁、レイアウト、挿絵、スケジュール管理などなど本文以外のすべては会社のみんなに助けてもらいました。というわけで本そのものの出来栄えも素敵に仕上がっています🙌

当日は か11「yagitch.com」さんのスペースに委託させていただきます。
おしながきはこちら〜↓

スペースでは委託先のyagitchさんのアウトプット本と、同じく委託でKOS-MOSさんのTerraform本が頒布されてます。

明日はよろしくおねがいします!

チームリーダーの呪いに苦しむ新米リーダーへ

eri-twin.hateblo.jp

「チームリーダー」になれなかった頃。上の記事で書いたプロジェクトが始まった頃から、およそ一年が経ちました。振り返れば良い経験で、記事に書いた思いは今も変わっていません。

それでも、最近、新たにチームリーダーを任されるようになった後輩などを見ていて、新米リーダーの思考を縛る「チームリーダーにならなきゃ」という呪いの強さを改めて感じています。

チームリーダーにならなきゃと思って、なれなくて、そんなことチームメンバーにも相談できなくて、孤独に悩み続ける日々。同じような悩みを抱えている方や、一年前の自分自身へ、いまの自分から伝えたいことを書いてみます。

「なんでもできるすごいリーダーになる」のを諦めること

会社においては「なんでもできるなんかすごい人」がリーダーをやっていることがままあります。こういう人を見て育ってきた新米リーダーは、"自分もこうならなければ"と思ってしまう。

これがすべての始まりです。

弊社にもすごいリーダーたちがいて、彼らを見てると「リーダーたるもの、彼らのようになんでもできるようにならなきゃ」って考えてしまう。

だけど、こうして悩みにぶつかる人は、おそらくそのような「なんでもできるなんかすごい人」ではないし、きっと同じようにできないから悩んでいるのだと思います。

もしも自分がすごいリーダーになれるなら素敵だ。けれど去年ブログに書いたように、わたしは、決してそれが唯一にして理想のリーダー、ではないと思っています。*1

すごいリーダーになりたいと願っても、今すぐにはなれないし、いつなれるかもわからない。そんな不確かなすごいリーダーを目指すよりも、自分がすごい人じゃないことを受け入れて、「今の自分がなれるリーダーになること」を考えた方が、きっと楽です。

「理想のリーダー像」は、チームの状態によって異なるのだと知ること

リーダーの呪いにかかり、「すごいリーダーのようにできない」と帰り道で落ち込む毎日。そんな中で、先輩のすすめを受けて「エラスティックリーダーシップ」を読みました。*2

この本では3つのリーダーシップが紹介されています。

  • サバイバルモードのチームに対する、指揮統制型のリーダー
  • 学習モードのチームに対する、コーチのリーダー
  • 自己組織化モードのチームに対する、ファシリテーターのリーダー

要は、チームの状況を見て自分がどのスタイルのリーダーになるのが良いかを見極めよう……っていうのが内容なんですが、ここにシンプルな気づきがあります。

少なくともこの本の中では、3つのリーダー像が提示されている。つまり、理想のリーダー像はひとつではないということです。これをもし知らなかったのなら知ってほしいです。わたしは知らなかったので目からウロコでした。

わたしがこの本から得た学びは、「漠然と自分の中にあった理想のすごいリーダー像」はただの妄想だったということです。理想のリーダー像なんてチームの状態によっていくらでも変わるのです。

リーダー像の妄想を捨てたら次は「リーダーの仕事」という妄想も捨てること

前述のように、当時はリーダーになるなら「なんでもできるすごいリーダー」を目指さなければいけないと思っていました。 自分がコードを書く時間が取れなくとも、調整や打ち合わせや面倒なあらゆることを引き受けて、メンバーがなにも気にせずコードを書けることがリーダーの役割だと考えていました。

ですが、振り返ってみると、チームメンバーからはわたしが何をやっているかわからなかったはずです。コードも書かないから、仕事をしていないように見えたと思います。一方で実装以外の問い合わせも打ち合わせもわたしのみが知っている状態で、常にわたしが情報のボトルネックでした。

これは単純に情報共有をしていないだけではなくて、コーディングのみを丸投げしているのが問題でした。そもそも前提となるサービス仕様や要件を知ってもらおうとしてないため、たとえ打ち合わせの情報を共有したところで、メンバーはどうしようもなかったのではないかと思います。

そんな日々が続いて、自分は好きでもない調整ばかりで楽しくコードを書く時間がない。チームメンバーとも対立して、チーム全体の雰囲気は悪くなる一方。とても苦しかったです。

結局、打ち合わせはメンバーにお願いしてもいいし、もちろんリーダーがコード書いててもいいです。誰か一人にしかできない仕事なんてそんなに多くないし、それが新米リーダーならなおさらです。チームなんだからチームの誰かがやれればいい。

チームに求められているのは、チーム全員で、期待されている分のアウトプットを出すこと。そのためにチームを見て、チームが必要としている役割を自分が果たすこと。その点においては、メンバーもリーダーも同じなのだと思います。

自分が理想のリーダーになるのではなく、みんなで理想のチームを目指すこと

原点に立ち返って、リーダーがなんのために必要とされるのかを考えるなら、それは「チームのため」であるはずです。であれば、リーダーの仕事はリーダーをすることではなく、良いチームを作ることです。

だから別に、自分がリーダーだから、なんて背負い込む必要はありません。むしろその思いは過剰すぎると呪いに転換して、こうして苦しい思いをすることになります。

チームを作ることは難しいけれど、一方で、実はすごく面白いことでもあります。でも呪いにかかっている間はそんな考え方はできなくて、それが一番もったいないのかもしれません。

毎日変化して成長していくチームをみんなで作っていくの、すごく楽しいんですよね。

そのうちいいチームを作れた実感が持ててきたり、チームの解散が心から惜しかったり、次のチームではどんなふうにやってみようかな〜なんて考えるようになれたら、もう大丈夫です。

おわりに

わたしも自分自身にかけてしまって苦しんだチームリーダーの呪い。この記事が、少しでも早く解き放たれるための一助になれば幸いです。

*1:むしろ「なんでもできるすごいリーダーになる」こと、つまり超人になることを目標にするのは、自分を過大評価しているとすら思う

*2:今回あんまり書籍の内容に触れてないですが、普通にチーム作りにおいてためになる内容が書いてある良い書籍です。読みやすい本なので、悩んでいるなら悩む代わりにその時間で読んでください。

平成最後のあけおめ

新年あけましておめでとーこざいます。
のんびり帰省させていただいてるのでまだ仕事始まってません。

2018年のふりかえり

できごと
1月 インフルエンザ
2月 就職以来心の支えだった作品が終わる
3月 チームリーダになりたくなかった
4月 米がマイ(米)ブーム
5月 推しが炎上
6月 OJTコーチが退職
7月 障害対応
8月 障害対応
9月 DDDアライアンスで発表した
10月 バレーボールの試合を見た
11月 今までで一番残業した
12月 虚無

今年は就職以来一番しんどい年でした。仕事始めてからは安定した気持ちで生きていたのですが、今年の前半でいろんな精神安定剤を失ったため後半のつらみがすごかったです。

アドベントカレンダー芸人のくせに12月はなにも面白いことが思いつかなくなり、内省しているうちに年が明けました。悲しい

あとは社内ブログを炎上させたり会社のBBQイベントに行ってお友達ができたりいろんな舞台を見に行ったりしたような気がします。楽しいこともたくさんありました。

よかったこと

  • チームリーダーやりました
  • チームビルディング楽しくなりました
  • 設計楽しくなりました
  • DDD面白いなと思うようになりました
  • DDDアライアンス後、社内の若手からDDDについて一言ある人みたいに見られています 騙されるな
  • たくさん迷惑をかけていろんな人に助けてもらいました、昨年度はありがとうございます。今年はもう少し落ち着きたいと思うのでよろしくお願いします

2019年

毎年おみくじの言うことを信じています。今年は末吉でした。あんまり気にいる内容でなかったので、都合の良い解釈をしていこうと思います。

目先にあることしかやりたくないしやりたいことはすぐ変わるので年間目標は立てませんが、健康と安定した情緒を得たいです。

あとはブログでもなんでもいいのでアウトプットを増やしたいと思います。去年は書きたいことがあってもなかなかブログを書ききれなかった。悩むより書く。

今年もよろしくおねがいします。

9/26のDDD Allianceにて発表しました

先日のDDD Allianceの勉強会にて、いま開発現場で取り組んでいるドメイン駆動設計の成果について発表させていただきました〜。

ddd-alliance.connpass.com

手前味噌。 発表資料。*1 他の登壇者の発表資料は上記イベントページのリンクからどうぞ!

www.slideshare.net

ためになる裏話とかは特にないのですが、せっかくなので感想など書いておこうかと思います。

DDDって注目されてるんだな〜という話

想像していたよりもずっと多くの方がドメイン駆動設計に興味を持っているのだと今回初めて知りました。(まずイベント公開からすぐにたくさんの申込があったので、当日までビビりながら資料作りしていました)
ディスカッションの場や懇親会でも、社外でDDDを実践している方々とお話しさせていただき、とても良い機会になりました。

イベント終了後、主催者・参加者の方々によるイベントレポート、感想ブログ等もたくさん書いていただきました。

dev.classmethod.jp togetter.com vermeer.hatenablog.jp hiroronn.hatenablog.jp

素直に、今回発表できてよかったな〜と思います。
資料作りは大変だったけど、それを十分に越える反響とフィードバックを貰えたのですごく満足しています。

改めまして、本当にありがとうございました。

バックグラウンドの話

イベント中ではさらっと流した部分でしたが、私は入社4年目、5年前から始まった弊社でのDDD開発が広まり出したころに参加しました。DDDネイティブ的な立場です。
新卒で入って研修を終えた6月頃、最初に書いたのがDDDのお題でした(イベントで最後に発表した奥野さんの資料の中で紹介されているお題です)。

javaを書いたことなくクラスの概念もわからない、そんな状態の1年目の私は、言われるがままにバリューオブジェクトを作りながら「javaってコードもファイルもたくさん作らなきゃいけなくて大変だなあ」と思っていました。

あれから約3年半の開発経験を経て、今回の発表。自分が理解できていなかった頃から続くこれまでのDDD実践の積み重ねから今のベストの実装に至るまでを振り返ることで、これまで自分が当たり前に使っていた仕組みのありがたみを実感することになりました。

DDDは面白い

私がDDD面白いなと思うようになったのは今年に入った頃で、結構最近の話です。ある案件をひとつメインで任されて、設計をじっくり考える時間をもらったのがきっかけでした。
ひたすらドメインモデルを考えて、実装してみて、うまくいかないところがあったら書き直し、サービス仕様がはっきりしてくる中で変えたいところがあったら書き直し、を繰り返す。 その中で(これはすごく感覚的な話なのですが)頭の中が開けるみたいにドメインがぱーっと理解できた瞬間がありました。これだー!という感覚。
ドメインがしっくりくるようになって、そのまま設計できて、その時にDDD面白いなもっと考えたいなと思うようになりました。

そういうわけでとても最近の話なのですが、今回の発表を経て、また考えてみたい事が増えました。まだまだ飽きることなく、これからも試行錯誤、取り組んでいけそうです。

最後に

お約束ですが! こんなかんじで取り組んでます弊社のDDD開発に興味が出てきませんでしょうかどうでしょうか。エンジニア超!募集中です〜!ぜひに!よろしくおねがいしまーす!!

*1:発表当日に上がっていた資料には隠しスライドが入ってしまっていたためアップし直しました。失礼しました…

図:外部設計で作るべきドキュメントを考える 二期作

以下の記事で作った図をさらに俯瞰して、ドキュメント同士の前後関係を書く。

eri-twin.hateblo.jp

緑が↑で挙げたドキュメントたち。ユースケース記述とロバストネス図はいったん「機能詳細設計」でまとめ直した。
ピンクはinput、自分たちで書かないやつ

f:id:eri-twin:20180910164335p:plain

矢印の手前のドキュメントをインプットにして、次のドキュメントを作っていくイメージ。(図だけに)

ST仕様書だけは一応書いたんだけど、テスト向けのドキュメントについてはまだ考えられてないのでここでは掘り下げない。
まずは外部設計を開発用ドキュメントの一旦のゴールとして、それに向けてどういうものが必要かのまとめ図。

設計段階のいろいろを勉強したので、新しい案件やりたいな〜