アルプに入社して丸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 が好調で、やらねばならぬコトが尽きないからなんですよね。
それだけやることが尽きないプロダクトですし、様々な期待を頂いています。
つまり、総じて「まじで忙しかった」です笑
まあ何が言いたいかというと、もっとたくさんの仲間が来てくれると良いなあと思う大晦日でした
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
というわけで、ここまでお付き合いいただき、ありがとうございました。
また来年もよろしくおねがい致します。