ScalaMatsuri 2022 へ座長チームメンバーとして参加してきました
写真は会社の人が撮ってくれた写真をいただきましたｗ
ScalaMatsuri 2022 参加ブログを書くとTシャツが当たるかもしれないキャンペーンをやっているとのこと。
ブログを書いて #ScalaMatsuri Tシャツをゲットしよう！
— scala_jp (@scala_jp) 2022年3月20日
ScalaMatsuri2022の感想をブログに書いてご応募いただくと、抽選でTシャツ各色1名様（合計4名様）にプレゼントします。プレゼントの対象には"Ninja" sponsorのTシャツも含まれます！
締切は4/20(水)23:59 JSTです。https://t.co/6vMUNtJxUb
前回
参加した経緯
参加した経緯と言っても、まあ毎年お手伝いさせていただいてますし、もはやライフワーク？なのかもしれません。
参加する目的としては、↓のインタビューに取り上げていただいた
一番の理由は、昔の私のようなScalaを始めたいエンジニアさんの力にすこしでもなりたい という想いがあるからだと思います。
から少しも変わってないです。
座長チーム
準備にかかる負荷分散を目指し、今年から座長チーム制度というものを取り入れた動きになっています。
その座長チームメンバーの一人として僕も参加させていただきました。
結果どうだったか？
座長チームでもこの後振り返りMTGを予定しているのですが、コレまで一人で座長をされてきた麻植さんのこのツイートにすべてが集約されているように思えます。
ScalaMatsuri直前なのに今年は割と普通に仕事できてるし、妻に 今年はピリピリしてないね って言われました。
— Taisuke OE (@OE_uia) 2022年3月16日
少しでも開催しやすく、そして良いカンファレンスになるべく、運営体制を変えるなどの取り組みはとても良いものかもしれません。
座長チームメンバーとしての準備
座長チームメンバーとしてどう動くのかまだあまりわからない中、そして日々の業務で忙しい合間に本当に座長メンバーとしてやっていけるのかは不安が残りましたが、スタッフのみなさんが本当に優秀でとても助かりました。
振り返ってみると、座長チームメンバーの役割は、もしかしたら「スタッフの方が無理なく、楽しく ScalaMatsuri 開催準備にかかるタスクをこなせるように、 場を温める のかもしれないと感じました。
個人タスク
それから、主な個人タスクは 2022 も上記 WEB サイトの更新でした。
リポジトリーへの初回コミットから、トータル48コミット頑張りました。
サイト自体はリニューアルされた 2020 のソースコードを元に、今年も Nuxt で作っているのですが、ライブラリのバージョンが古くて、しかしバージョンアップしていくのも大変なのでそのまま流用しています。
来年は Nuxt 3系か、やはり Scala.js で動かしたい気持ちがかなり強いです。
アルプも大名スポンサーとして参加しました
当日は司会したりとシフトを組んでいただいているので会社のイベントには出れませんでしたが、結構盛り上がった様子で嬉しい限りです。
いっぱい準備頑張ってくれた会社のみんなが本当にカッコヨカッタ！
詳しくは↓を読んでいただければ。
当日
オープニングの一部と、クロージングのファシリテーション。あとは主に司会などを担当しました。
参加者の方々に少しでも楽しんでいただけるように盛り上げて行こうとしたのですが、当日は参加者の方が自発的？に盛り上がって行くのを見て、改めて ScalaMatsuri が愛されている場なんだなあと感じました。
本当にありがとうございました。
来年
まだ何も決まっていないのですが、来年 ScalaMatsuri が開催されるとしたら
- やっぱりオフラインでやりたい
- WEB サイトをもう少しブラッシュアップしたい
- Scala.js チャレンジしたいかも
ですかね。
シュッとしてますが、このへんで。
来年もまたよろしくおねがいします！
デザイン人間工学の基本: ［分冊版］応用編
デザインというか、Web画面の情報設計に興味があるので会社のデザイナーさんに教えてもらった本。
基本的にハードウェアのデザイン（設計）に関する話が主なのだけど、デザインをするうえで考えるべきポイントみたいなの内容が手順のようにまとまっており、順を追っていくように説明されているので頭に入りやすかった、気がする。
表にまとめてもらってるのがスゴく良い。
アルプ株式会社への入社後2年感想戦(大晦日だよスペシャル)
アルプに入社して丸2年が経ちました
前回はコチラ。
前回からだいたい10ヶ月経ちました。早いもので入社してからまる2年経ったことになります。
2年という莫大な時間が過ぎたのと、大晦日にふさわしいブログになると良いなと思い、また書きます。
毎度のことで恐縮ですが、このエントリーは完全に個人のエントリーであり組織を代表するものでは無いということを予めご了承ください。
また今回も書きたいと思ったことをキーワードにして羅列、そのキーワード毎に感想を書いていくため、前後の文章はあまりつながっていないかもしれません。結果、もともと稚拙な文章しか書けないことに加え、非常に読みづらいブログになってしまっているかと存じますが、最後までお付き合いいただければ、至極幸いにございます。
あと、アルプについてもっとしっかりしたものが読みたい場合は、是非こちら↓へ訪れてみてください。
オフィス移転
さて、この半年で一番大きな変化はオフィス移転をしたことです。
場所はなんと渋谷の道玄坂。伝説の「イカセンター」が入るビルです。
渋谷はイカセンターの上に移りました。
— 伊藤浩樹（H.Ito）| アルプ | Scalebase (@itokin) June 18, 2021
よろしくお願いします。 pic.twitter.com/FwNDxkccCO
特徴をざっとあげると
- おしゃれ
- フローリング
- 靴を脱ぐ
- 全席モニター完備
- もちろん椅子も良いやつ
- お水、お茶、コーラ飲み放題(オフィス関係ない)
などなど。
仕事中は靴を脱ぎたい人間なのでフローリングづくりがとても嬉しいです。
集中できる空間とリラックスできる空間が共存しており、素敵な空間に仕上がっています。
出社デー
バリューの一つに「オーバーコミュニケーション」というものがあります。
リモートでも業務はできるのですが、ただただ毎日目の前の仕事をするだけというのはどこか違います。
社員間のコミュニケーションを以って業務を遂行し、より大きな作業をこなしていける組織にすることが必要で、「オーバーコミュニケーション」といったバリューが必要になるという理解もあります。
そのため、週に1度はみんなで膝を突き合わせて、あるいはランダムにコミュニケーションを取る日を〜ということで、オフィス移転前も後も基本的に毎週金曜日は出社デーとなっています。
オフィスに居ると雑談も楽にできて、リモートワークが(少なくともアルプで)主流になった今では、この金曜日の出社デーが割と楽しみだったりします。
新入社員
非常に多くの仲間が増えました。
振り返ると社員数が倍に！そしてインターンな若者がわんさか！
もうオフィスの席が足りなくなってきて、びびるし、僕もなんか彼方に埋もれそうです...。
そうすると「ただのおじさん」になってしまうので、埋もれないようにバリューを出していく・上げていくのが大変な今日このごろ。
また新しい仲間がたくさん増える予定だそうです。
びびります。
Huddle の瞬間風速
Slack の Huddle での雑談が地味に流行っていました。Huddle は社内 Clubhouse みたいなイメージですね。
業務で軽く確認したいことや、夜間作業後(ちょっと遅い時間だけど、真夜中ではない)のマッタリタイムなど、誰かが Huddle に居ると他の誰かが入ってきて、いつの間にか数人で雑談する時間ができることも珍しく有りません。
この前は Huddle で何故か突発「〇〇老人会」が開始し、Slack 上にも昔みんなが使っていたmp3プレイヤーなどの懐かしいアイテムが貼られて大いに盛り上がりました。
同じ会社の人間なのに散り散りで作業しているこの大変な状況下であっても、割とスムーズに業務ができているのは雑談のおかげかも知れなく、それだけすごい力があるのかなあと感じた半年でした。
そう言えば最近はスッカリ Among Us やらなくなってしまったのですが、また復活して欲しい気もしますね。
僕の前半タスク
個人のタスクはというと、年明けしばらくしてからはまた Salesforce 開発をしていました。
主に機能追加開発がメインなのですがすでに大規模なシステムになってきており、既存機能との兼ね合いだったりとなかなかに大変な作業でした。
設計やリファクタリング、そしてリーダブルに書くことの大切さや、如何にチーム内で認識をそろえるかが難しく感じました。
その中でもより良いやり方を発見したりもしましたし、間違えてしまったこともあります。
ですが、大事なのはある程度落ち着いた後に「ちゃんと振り返る時間を設けられた」ことでした。
ともすると、そういった大変だった期間を振り返ると「いや〜大変だったけどなんとかなったねｗ」で済ましてしまうことが多い気がするのですが、「『大変だったこと、間違えてしまったこと』は必ず美化してはいけない。なぜそうなってしまったのか、次はどうしたら防げるのかを考えて、つなげることが大事だよね」という一つの結論が出てきて、これがとてもしっくり来ました。
僕の後半タスク
後半からはSalesforce だけでなく、バックエンドに戻ったり、最近は久しぶりに React / TypeScript を書いていたりしました。
久しぶりのフロントエンドは結構構成が変わっていたりして、しかしわからないことながらもかなり整頓されている（ように見える）ためかサクサクすすめることができてそれなりに楽しめました。
また、タスクの種類も様々になってきており、feature や fix だけではなく、改善タスクといったチケットが増えてきました。
最近の仕事上の悩み
（当たり前なのでいまさらこう書くと怒られるかもですが）アルプではかなり真面目にテストを書く習慣があります。
さて、テストが正しく機能しているといえる根拠はどこにあるのでしょうか？
その根拠となりうるのは「仕様」なのですが、では、「インクリメンタル開発における仕様」とは、どこに”在る”べきなのでしょうか？また、何をもって「仕様」と言えるのでしょうか？
ウォーターフォールのような開発においては、当初の仕様固めとドキュメント化は非常に重要です。その仕様が後の納品物の土台になります。
しかし、個人的にはドキュメントは生モノだと考えています。
そして、プロジェクトを終わらすことを目的としない、つまり”プロダクトを育てるようなインクリメンタル開発”においては、その機能や規模は常に スケール していくものであり、それにともなって仕様も移り変わるものです。
その成長はドキュメントに落とした翌月には陳腐化するようなスピード感です。
ドキュメントは詳細になればなるほどメンテナンスコストが膨れ上がるという性質があり、良きバランスでドキュメントに落とすことなど不可能と考えています。
一つの解としてそれはE2Eテストケース=仕様になるのかなと考えていますが、これからの1年の個人的に大きなテーマとなっていきそうです。
スケールする組織と大総じ（大掃除）
スケールといえば会社規模もより大きくなっていきそうで、来年からいろいろ体制も変わってきそうです。
本当にありがたいことに、かなり Scalebase が好調で、やらねばならぬコトが尽きないからなんですよね。
それだけやることが尽きないプロダクトですし、様々な期待を頂いています。
つまり、総じて「まじで忙しかった」です笑
まあ何が言いたいかというと、もっとたくさんの仲間が来てくれると良いなあと思う大晦日でした
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
というわけで、ここまでお付き合いいただき、ありがとうございました。
また来年もよろしくおねがい致します。
ザ・ボーイ 人形少年の館
人形の世話をして欲しい老夫婦と、その世話役となった主人公の話。
オチがひどすぎた。
