株式会社クルーバー ZERO TO ONE事業部でCrooooberをはじめとしたWebサイトの開発・運用をしています、加藤と申します。
今回は、サイト開発中に発生した問題と失敗を備忘録としてブログに残しておこうと思います。
続きを読むDDD勉強会
株式会社クルーバー ZERO TO ONE事業部でアップガレージの基幹システムを開発・運用をしています、キムです。
まだまだ暑い日が続いていますが、みなさんいかがお過ごしでしょうか。
今回の記事は、少し前に社内で行われた勉強会について紹介したいと思います。
弊社について少しでも知っていただけたら幸いです。
はじめに
ZERO TO ONEでは、様々な読書会や勉強会を実施しています。
過去に行われた読書会については下記の記事を御覧ください。
今回は、もっとラフな形で有志を集めて行われたDDD勉強会について紹介していきます。
DDDとは？
ドメイン駆動設計（Domain-Driven Design）のことで、略してDDDです。
ざっくり説明すると、ビジネスの様々な問題を解決するために、必要なビジネス知識に焦点を当てた設計手法のことです。
詳しくはこちらの記事がわかりやすいかと思いますので、興味ある方は是非ご一読ください。
DDD勉強会
添付画像のように、少し前にSlackで有志を集めて勉強会を実施しました。
返信数が98件も！（笑）
勉強会の内容としては、下記ページの概要に載っているYoutubeのアーカイブをみんなで視聴しながら、気づきや感想などをSlackでコメントし合うという内容です。
アーカイブはまだ残っていますので、興味ある方は是非視聴してみてください！
勉強会のルールに関しては、ラフでとてもシンプルです。
Slackでのやり取りの頻度は非常に高く、勉強会は大盛りあがりでした！
一部やり取りを抜粋して貼っておきます。
最後に
私自身、このような有志による勉強会への参加は初めてで、すごく新鮮で楽しかったです！
今後、私からも何かテーマを見つけた際には勉強会を主催してみたいと思いました。
ZERO TO ONEでは共に勉強し合い、成長し合うメンバーを大募集しています！
20%ルールについて
株式会社クルーバー ZERO TO ONE事業部でCrooooberをはじめとしたWebサイトの開発・運用をしています、加藤(2020年度 新卒入社)と申します。
今回の記事では、弊社の制度である20%ルールについて、私がどのように活用しているのかを紹介したいと思います。
はじめに
弊社では2021年度下期から20%ルールを導入し、多くのメンバーがこの制度を利用しています。
20%ルールとは？
「主な業務とは別に20%の時間を自主的なプロジェクトに充てるべし」というルールのことです。
個々のスキルアップを目指し、最終的に組織全体の底力を上げることを目的としています。Googleが導入していた制度として有名ですね。
対象者
弊社の社員（1年目の新卒を除く）
具体的に
まず自分自身で伸ばしたい部分に対してテーマを決め、学習を進めます。
弊社では、基本情報技術者試験・要件定義/設計・インフラの勉強など人によってテーマが様々です。
20％ルールなので、時間は週当たり8時間割り当てられます。「毎日2時間 」や「金曜日のみ8時間」など実施タイミングは個人の自由です。
また、毎週火曜日にはアウトプットの時間を設けており、自分の発表が出来たり、他メンバーの実施項目について学ぶことが出来ます。
私のテーマについて
私の選択したテーマは「インフラ」です。
ZERO TO ONEが開発に携わっているプロダクトの多くは、リリース作業が自動化されており、画面操作だけでソースコードを本番環境にデプロイすることが可能です。
これにより、メンバー全員が簡単かつ安全にリリース作業可能になりました....が、自動化された部分において学ぶ機会が減ったとも言えます。主にインフラ系です。
それらの知識なしに開発が進められるのは素晴らしいことです。しかし、大きな機能を実装する際にインフラの観点から工夫したり、システムに障害が発生した場合の解決においてはまだまだ必要な知識とも言えるでしょう。
同時に「システムにおける全てのライフサイクルを触れるようになりたい」と考えている私にとって、早く身につけたい知識の一つでもありました。
(もともと自作PCや自宅サーバーをイジるのが趣味でしたが、個人の趣味レベルでは業務に活かすことが難しいこともあり、行き詰まっていたところでした)
上記のような理由からインフラというテーマを選択しました。
こういった挑戦にはチェックポイントが必要不可欠ですので、私は「社内インフラの神」になるという第一チェックポイントを掲げて、学習をスタートしました。
どう進めたか？
とはいえ現状、AWS関連サービスに関する知識がほぼ無く、マニュアルに従って確認作業をする程度のことしか出来ていない状況です。
まずは書籍やオンラインセミナーによるインプットと、インフラ担当のメンバーから一部作業を引き継ぐというアウトプットに専念しました。
最初の課題
そのようにして2ヶ月ほどインフラについて学習を進めていたところ、弊社は東証上場という節目を迎えることになりました。
それに伴い、企業サイトのリニューアルをするという案件が生まれました。
本来であれば経験豊富なシニアエンジニアに任される案件でしたが、20%の学習状況も踏まえて、ほぼ全面的に私が担当することになりました。
この機会でやったこと
- Dockerコンテナ作成
- Route53におけるルーティング設定
- Cloudfront CDNの設定
- Codebuild CI/CDの構築
2021年12月16日に最初のリリースを行ない、サイトのリニューアルが完了しました。
こちらのサイトが成果物になります。
通常の案件ではありますが、20%で得た知見を一つの形として完遂したことが自信に繋がりました。一般的に見ればただの企業Webサイトですが、私にとって1からやりきった初めてのプロジェクトですので、非常に印象に残っています。
今後の20%ルールについて
今回行なったことはAWSに特化している上に浅い領域です。クラウドネイティブな時代になっては来ていますが、どのサービスでも通用するであろう、より低いレイヤの知識も身につけていきたい所存です。
また、自分だけの知識とせず、いつか社内で勉強会を開くような形でチームの共有知にしていきたいですね！
最後に
今回は私の20%ルールについての紹介でした。
今後、他のメンバーの取り組みもこのブログで発表していきます。
ZERO TO ONEでは、システム開発を一緒に楽めるメンバーを大募集しています！
開発体制について紹介
株式会社クルーバー ZERO TO ONE事業部でアップガレージの基幹システムを開発・運用をしています、キムと申します。
今回の記事は、年度初めということで、我々ZERO TO ONEの開発体制について少し触れてみたいと思います。
少しでも知っていただけたら幸いです。
はじめに
ZERO TO ONEでは、新年度から開発体制に少し変化がありました。
目的としては、より円滑に顧客の要望や要件などのニーズに応えるため、一個人の業務負担を減らし、全体的な対応スピードを上げることです。
開発人数が増えていくに連れ、どうしても特定のメンバーに業務が偏りがちなので、このような課題や悩みを抱えているチームは少なくないと思います。
そこで、今回はそんな課題や悩みを解決するための糸口として、参考になれる記事にできたらなと思います。
さて、どのような変化があったのか少し気になったところで、早速本題に入ろうと思います。
今までの体制について
今までは体制としては、いわゆるスクラム開発という開発手法を採用していました。
チームごとに少し異なる部分があったりしますが、大まかな流れは共通してスクラム開発の形となっています。
図で表すと下記のような形になります。
すでにわかっている方も多いかと思いますが、変更後の体制と比較するため、念のためそれぞれの役割についておさらいしておきます。
- プロダクトオーナー：プロダクトの責任者です。顧客の要望や要件などのニーズを満たすため、プロダクトの方向性や開発方針を決める役割を担います。
- スクラムマスター：チームのリーダーです。スプリントを完遂させるため、開発チームを統括し、開発を円滑にに進めるための役割を担います。
変更後の体制について
新しい体制は図の通りになります。
ステークホルダー側は変わりはないですが、開発チーム側は役割がいくつか増えたことがわかると思います。
今までのスクラム開発の形は変わらず、役割を Lead、Biz、System の３つ増やしました。
それぞれの役割を説明すると、下記の通りになります。
- Lead: チームのデリバリーの責任を負う役割です。スコープ、品質、納期を管理し、設計・実装・テストのレビューなどを行います。必要に応じて開発もします。
- Biz: 問い合わせの一次対応、事業部との会議に参加する役割です。ビジネス側とのやり取りにおいて、Leadを積極的に補助します。
- System: システムアラートの一次対応をする役割です。システムの監視において、Leadを積極的に補助します。
- 上記の役割がなくても該当プロダクトのエンジニアとして、開発から保守運用をすることに変わりはありません。
Lead は、スクラムマスターに近いので理解しやすいと思います。要はチームをリードする役目です。
Biz は、プロダクトオーナーの代わりにビジネス側と開発チームのパイプ役を担う役目です。役目が変わったからといって、プロダクトオーナーは何もしないというわけではありません。プロダクトオーナーはプロダクトの責任者なので、方向性や開発方針を決めることは変わらないです。
System は、上記説明の通りシステムアラートを対応する役目です。
最後に
ZERO TO ONEとしても新しい試みなので、上手くいくかどうかはこれからになります。
個人的には、役割を適正化したことで、目的である一個人への業務の偏りを削減できたと感じています。
ただし、今回の体制変更はあくまで「顧客のニーズに対して円滑にスピーディに応える」というゴールへのステップに過ぎないということです。
今後も顧客対応や開発スピードを向上させるため、常に調整を加えながら変化を続けていきます。
そんな変化を一緒に楽めるメンバーを大募集しています！
未経験のWebエンジニアが、入社2年間までに読んだ本を抜粋してみた
はじめに
はじめまして！株式会社クルーバーでWebエンジニアをやっております、加藤です！
現在入社2年目で『自動車中古部品ECサイト Croooober.com』の開発、保守を担当しております。
さて、今回の記事では、過去の自分が学びを得た本や「あの時この本を知っていれば...」と感じた本をまとめました。これからエンジニアを目指そうと思っている方、4月からエンジニアとして就職することが決まっている方に向けての記事ですが、自分の過去を振り返り現在地を把握する目的もあります。
少しでも参考になれば幸いです。
- はじめに
- プログラマーとして汎用的な技術、知識
- 低レイヤに対する知識
- UNIX関連
- ネットワーク
- データベース
- 開発手法、設計手法
- コードの書き方
- 生産性、組織改善
- Java
- Ruby & Ruby on Rails
- 最後に
プログラマーとして汎用的な技術、知識
より良いプログラマーになることを目的としており、効率の良い開発やチームでの開発に個人単位で求められるマインドセットなどを学べます。
言わずとしれたエンジニアの入門書ですね。(この書籍が20年以上前に出版されていたのだから驚きです) 直近ですと、翔泳社の「ITエンジニア本大賞 2022」で「技術書部門大賞」という輝かしい賞を受賞しておりました。
専門用語も多々ありますが、IT業界に興味を持っている方なら問題無く読めるレベルだと思います。
この本ではRESTfulAPIはどのように扱うべきか？どのようにデータのやり取りが行なわれるか？等、そのままWebを支える技術を学ぶことが出来ます。
皆さんや私が良く利用している「Web」のバックグラウンドにある技術を学ぶことは、開発を大いに手助けしてくれるでしょう。
今後のIT業界においてWebは切っても切り離せない存在です。
特に「そもそもRESTってナニ？」と思った方は必読です。(私もそうでした)
低レイヤに対する知識
「コンピュータが何故プログラムという命令を理解するか？」ということを、わざわざ進んで理解する人は多くないと思います。
システム開発の業務では「機能の実装」「保守」などのサービス向上のための対応が優先され、高レイヤの部分に注視しがちです。
しかし、コンピュータの基礎となるOS(低レイヤの部分)は、あらゆるアーキテクチャに共通している技術。ここへの理解を増やすことで、新しい技術が出てきた際のキャッチアップを高速化することも可能です。
また、汎用的で枯れた技術ですので、IT業界特有の流行り廃りに振り回される可能性が低く、継続した学習さえ続ければ強力な武器になると思います。
UNIX関連
広義のシステム開発において、Linuxは切っても切り離せない存在です。この本では各種操作コマンドや扱い方、Linuxの元となるUnixの設計思想などを学ぶことが出来ます。
初めてエンジニアになる方の中には「WindowsやMacしか触ったことが無い」という方もいらっしゃると思います。近年のエディタや環境構築の進化は凄まじく、コードを書くだけならGUIのみで完結するかもしれません。
しかし、「不具合発生時の調査」「構築されている環境に変更を加える」など、サーバーの設定の操作が必要になる場合にはLinux&UNIXの知識が必要です。
UNIXコマンドは便利ですが、1発で多くのファイルを削除したり、セキュリティ的に危険な状態に導いてしまう可能性があるため、業務を進めるためにはきちんと理解しておきたいですね！
ネットワーク
AWSの各種サービスや設計思想を学べる1冊です。
AWSは提供しているサービスも多く、どうしても継ぎ接ぎの知識で環境構築しがちですが、体系的に勉強し設計思想を理解することで、より最適な形での構築が可能になります。
近年は環境のクラウド化などによって、ネットワークの設定がある程度ブラックボックス化されていることが多い思います。そのため、知識が無くても開発からリリースまで出来てしまいますが、その根底にはどのような技術があるのか？
難易度は高いと思いますが、中途半端に学習してしまった影響で断片化してしまった知識を整理するためには最適な書籍だと思います。
データベース
データベースに関する基礎知識を会得出来る本です。
近年の各種フレームワークではデータ操作をメソッドに置き換えられていますが、新規開発時の構造の設計や、データの修正を行なうエンジニアにとって、SQLの知識は必ず必要になります。
CRUDは勿論ですが、結合、インデクス、トランザクションなど、体系的に学んでおくと業務中の不安を減らせるでしょう。
開発手法、設計手法
開発手法、設計手法に関する書籍です。
駆け出しの段階だと、いきなり設計に携わることはそう多くないと思います。
ただ「将来設計する際の基礎知識の会得」「様々な手法の特徴や思想を知り、良いところを日々の開発に取り入れる」など、身に付けておけば様々なことにフィードバック出来ると思います。
コードの書き方
コードを書く際やシステムの設計時に考慮すべき規則、考え方が上手くまとまった書籍です。
サブタイトルの「3年目までに身につけたい一生役立つ101の原理原則」と、初心者には特におすすめの1冊です。
「スパゲッティコード」などと悪いコードは槍玉に挙げられがちですが、では"良いコード"とは？
変数名を考えるのが面倒でついつい`num1 = 0`みたいに書いちゃったりしてませんか？
良いコードを書くという点では「プリンシプルオブプログラミング」に近い部分がありますが、こちらはよりコードにフォーカスを置いております。
具体的な実装例などもあるため、イメージしやすいのも本書のメリットです。(挿絵のジョークも癖になります)
個人的には「プログラミングは8割が命名」だと思っていますので、命名の部分は必読です！
上記2冊は弊社の研修カリキュラムにも組み込んでおります。
生産性、組織改善
システム開発では「個人として」「チームとして」の生産性や組織改善が求められます。
開発メンバーとして行動する場合は「個人」の生産性を求められますが、開発チームのリーダーにはより大きな範囲である「チーム」としての生産性が求められます。
「チームという組織を如何に健全に保ち、生産性を高め続けられるか？」ということに興味があれば必見です。
尚「LeansとDevOpsの科学」は、弊社の勉強会用書籍としても採用しております。
Java
Javaの学習入門書籍です。
世の中にプログラミング言語は数え切れないほどありますが、まずは静的型付け言語の代表の1つであるJavaを学ぶことで、データの型やオブジェクト指向に対する理解を得ることが出来ます。
また、オブジェクト指向の学習で躓く方は非常に多いと思いますが、特にこの本は分かりやすく解説されておりますのでおすすめです。
Ruby & Ruby on Rails
弊社では店舗で使用している基幹システムのリプレイスを行なっており、新しいシステムではRailsを用いて開発を進めております。
![プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus)](https://m.media-amazon.com/images/I/41ayMTBtVtL._SL500_.jpg "プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus)")
「チェリー本」として有名な入門書です。「プロを目指す人」と名のある通り、実践技術をメインに学べる本です。
「書き方は色々存在するが、このケースではこう書くと良い」という著者のお勧めに沿ってRubyでの自然な書き方を学べます。また、後述するテストの書き方、デバッグ方法の説明も手厚く書いてあります。読者に寄り添った文体で人気の入門書です。
また、著者の伊藤淳一さんはQiitaにも記事を投稿しており、RSpecの解説記事にはかなり助けられました...
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
プログラミングの初学者の方にもおすすめなRailsの入門書です。
Ruby及びRailsでよく使用される整数、文字列、配列、ハッシュと言ったオブジェクトの理解にも役立つと思います。
Railsで必要となる知識を学ぶことをゴールにしているので、メソッドやクラス、モジュールの作り方、使用方法など、最低限必要となる知識を効率良く学べます。
また、以前弊社の勉強会でもこちらの本を採用し、勉強会の議論のネタに使わせていただいておりました。
Rubyは国産言語でもあることから、読みやすい本が充実しているのが良いですね〜
最後に
今回紹介した本は、全体的に「ブラックボックス化されている部分を理解する」という書籍の紹介が多めです。
エンジニアにおいて「何故動作しているのか分からないが、動いているので問題無い」というのは、今後不具合などにより損害を生み出す可能性が極めて高くなり、保守の観点における責務を放棄していると言えます。
サービスを「より早くリリース」「より安全に動作させる」「より長く使われる」ことを追求し続ける姿勢を持ち続けることが、チーム、顧客、市場から求められるエンジニアになる唯一の道と思っておりますので、今後も学習を続けていきたいと思っています！
今後も良い本があったら、記事を適宜アップデートしていきたいと思います！
Railsエンジニア互助会
技術顧問の五十嵐(igaiga)です。今日はクルーバー社内で開催している 「Railsエンジニア互助会」 についての話です。
クルーバーでは複数のサービスを開発するため、複数のチームに分かれて開発しています。複数チームごとに分かれていることは対象ドメインごとに開発するのには有利ですが、一方でRailsやRubyなどの技術知識はチームを横断して情報交換した方がメリットがあります。
そこで週1回30分、各チームからエンジニア有志が集まって「Railsエンジニア互助会」を開催してみることにしました。たとえば次のようなことを話しています。
- 日々の開発で疑問に思ったことを質問して議論
- ライブラリのアップデート情報、またそのときに踏んだ問題点の共有
- 最近の勉強回やカンファレンスで講演された話の共有
実際に話した例を1つ紹介します。参加している同僚から「なぜかこのリポジトリでだけこのコードが動かないのですけど……」と相談されました。簡略化すると次のようなコードでした。
def method(*args, **kwargs, &block)
# ...
end
私がたまたまキーワード引数仕様変更の話を調べたばかりだったので「Ruby2.7で導入された記法 **kwargs をRuby2.6でつかっているのではないか」と仮説を立て、結果的にそれが当たりでした。最近Rubyを始めた人がこの仮説に気づくのは難しいですし、気づくためにはこの問題とは関係ないことも調べる必要があり、時間がかかりそうな問題です。このように、「知っている人に聞けばすぐわかること」を解決するときに互助会はたいへん便利です。
ここでのキーワード引数仕様変更の話は、私の記事「Ruby3.0キーワード引数仕様変更に伴う書き換えをしたので調べたことのまとめ」にまとめていますので興味がある方は読んでみてください。
そのほかにも徳丸先生の記事「2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか | 徳丸浩の日記」を読んで自分たちのコードベースでのCookieに関する内容を議論したり、Dockerをつかって構築している開発環境を改良してもっと便利に開発できるようにならないかを議論したりしました。誰かが何かを説明するというよりは、みんなで議論をしながら問題を解決したり理解を深めたりしています。
この互助会を始めるにあたり、ピクシブさんの互助会の仕組みを参考にさせていただいてます。
ピクシブフロントエンド互助会の取り組み - pixiv inside
同じような進化をしていくのか、独自の文化が生まれていくのか、私も楽しみながら運営していこうと思います。
クルーバーでは一緒に開発するメンバーを大募集しています！
採用情報 | 株式会社クルーバー ZERO TO ONE事業部
エラスティックリーダーシップ読書会
技術顧問の五十嵐(igaiga)です。今日はクルーバー社内で開催している 「エラスティックリーダーシップ」 の読書会についての話です。
エラスティックリーダーシップとは
エラスティックリーダーシップは2017年05月に発売された、自己組織化されたチームをつくるために、どのようなリーダーシップを取っていくべきかを解説した書籍です。
また、オライリーの書籍説明には次のように書いてあります。「チームをより良くする実践的なヒントが詰まっており、チームリーダーやマネージャーだけでなく、チームで成果に取り組むすべての人におくる一冊です。」私はこの本はリードする人だけでなく、リードされる人たちにとっても学びが多い書籍だと考えています。リーダーが求めることを知ることは、リードされるときの勘所を得ることにもなるからです。また、みんなで読むことでリーダーをする人とチームメンバーに共通認識を作ることもできます。エンジニア職種ではリーダーをやることに苦手意識を持っている人も多く、リーダーの負担を減らすことは効果が高いと考えていて、この本の読書会はその一助になるものだと考えています。
読書会の進め方
読書会は毎週1回、1時間で開催しています。前半30分程でその日の範囲を読み、学んだことやみんなで話したいことを書いて、後半30分でその内容をみんなへ説明する形式にしています。同意や、フィードバックをしたい人は付箋に書いて追記していきます。この方法は技術顧問をやっている別の会社Classiさんでkiryuanzuさんに教えてもらった方法(エラスティックリーダーシップ読書会 修了レポート - Classi開発者ブログ)をクルーバーでも取り入れてやってみました。付箋をつかったコミュニケーションが促進されて、良いやり方だと感じました。
みんなで書いてできあがったページはたとえば次のようなものです。
この本は私もとても好きな本なので、いろいろな会社で何度も読書会をやっていますが、今回も新しい発見がいろいろとありました。一緒に読書会に参加してくれた参加者のみなさんに感謝です。
クルーバーでは一緒に開発するメンバーを大募集しています！
採用情報 | 株式会社クルーバー ZERO TO ONE事業部
