開発体制について紹介

株式会社クルーバー ZERO TO ONE事業部アップガレージの基幹システムを開発・運用をしています、キムと申します。

 

今回の記事は、年度初めということで、我々ZERO TO ONEの開発体制について少し触れてみたいと思います。

少しでも知っていただけたら幸いです。

 

はじめに

ZERO TO ONEでは、新年度から開発体制に少し変化がありました。

目的としては、より円滑に顧客の要望や要件などのニーズに応えるため、一個人の業務負担を減らし、全体的な対応スピードを上げることです。

開発人数が増えていくに連れ、どうしても特定のメンバーに業務が偏りがちなので、このような課題や悩みを抱えているチームは少なくないと思います。

そこで、今回はそんな課題や悩みを解決するための糸口として、参考になれる記事にできたらなと思います。

さて、どのような変化があったのか少し気になったところで、早速本題に入ろうと思います。

 

今までの体制について

今までは体制としては、いわゆるスクラム開発という開発手法を採用していました。

チームごとに少し異なる部分があったりしますが、大まかな流れは共通してスクラム開発の形となっています。

図で表すと下記のような形になります。

 

すでにわかっている方も多いかと思いますが、変更後の体制と比較するため、念のためそれぞれの役割についておさらいしておきます。

  • プロダクトオーナー:プロダクトの責任者です。顧客の要望や要件などのニーズを満たすため、プロダクトの方向性や開発方針を決める役割を担います。
  • スクラムマスター:チームのリーダーです。スプリントを完遂させるため、開発チームを統括し、開発を円滑にに進めるための役割を担います。

 

変更後の体制について

 新しい体制は図の通りになります。

 

ステークホルダー側は変わりはないですが、開発チーム側は役割がいくつか増えたことがわかると思います。

今までのスクラム開発の形は変わらず、役割を LeadBizSystem の3つ増やしました。

それぞれの役割を説明すると、下記の通りになります。

  • Lead: チームのデリバリーの責任を負う役割です。スコープ、品質、納期を管理し、設計・実装・テストのレビューなどを行います。必要に応じて開発もします。
  • Biz: 問い合わせの一次対応、事業部との会議に参加する役割です。ビジネス側とのやり取りにおいて、Leadを積極的に補助します。
  • System: システムアラートの一次対応をする役割です。システムの監視において、Leadを積極的に補助します。
  • 上記の役割がなくても該当プロダクトのエンジニアとして、開発から保守運用をすることに変わりはありません。

 

Lead は、スクラムマスターに近いので理解しやすいと思います。要はチームをリードする役目です。

Biz は、プロダクトオーナーの代わりにビジネス側と開発チームのパイプ役を担う役目です。役目が変わったからといって、プロダクトオーナーは何もしないというわけではありません。プロダクトオーナーはプロダクトの責任者なので、方向性や開発方針を決めることは変わらないです。

System は、上記説明の通りシステムアラートを対応する役目です。

 

最後に

ZERO TO ONEとしても新しい試みなので、上手くいくかどうかはこれからになります。

個人的には、役割を適正化したことで、目的である一個人への業務の偏りを削減できたと感じています。

ただし、今回の体制変更はあくまで「顧客のニーズに対して円滑にスピーディに応える」というゴールへのステップに過ぎないということです。

今後も顧客対応や開発スピードを向上させるため、常に調整を加えながら変化を続けていきます。

 

そんな変化を一緒に楽めるメンバーを大募集しています!

採用情報 | 株式会社クルーバー ZERO TO ONE事業部

未経験のWebエンジニアが、入社2年間までに読んだ本を抜粋してみた

はじめに

はじめまして!株式会社クルーバーでWebエンジニアをやっております、加藤です!

現在入社2年目で『自動車中古部品ECサイト Croooober.com』の開発、保守を担当しております。

さて、今回の記事では、過去の自分が学びを得た本や「あの時この本を知っていれば...」と感じた本をまとめました。これからエンジニアを目指そうと思っている方、4月からエンジニアとして就職することが決まっている方に向けての記事ですが、自分の過去を振り返り現在地を把握する目的もあります。

少しでも参考になれば幸いです。

プログラマーとして汎用的な技術、知識

より良いプログラマーになることを目的としており、効率の良い開発やチームでの開発に個人単位で求められるマインドセットなどを学べます。

言わずとしれたエンジニアの入門書ですね。(この書籍が20年以上前に出版されていたのだから驚きです) 直近ですと、翔泳社の「ITエンジニア本大賞 2022」で「技術書部門大賞」という輝かしい賞を受賞しておりました。

専門用語も多々ありますが、IT業界に興味を持っている方なら問題無く読めるレベルだと思います。

 

この本ではRESTfulAPIはどのように扱うべきか?どのようにデータのやり取りが行なわれるか?等、そのままWebを支える技術を学ぶことが出来ます。

皆さんや私が良く利用している「Web」のバックグラウンドにある技術を学ぶことは、開発を大いに手助けしてくれるでしょう。

今後のIT業界においてWebは切っても切り離せない存在です。

特に「そもそもRESTってナニ?」と思った方は必読です。(私もそうでした)

 

低レイヤに対する知識

コンピュータが何故プログラムという命令を理解するか?」ということを、わざわざ進んで理解する人は多くないと思います。

システム開発の業務では「機能の実装」「保守」などのサービス向上のための対応が優先され、高レイヤの部分に注視しがちです。

しかし、コンピュータの基礎となるOS(低レイヤの部分)は、あらゆるアーキテクチャに共通している技術。ここへの理解を増やすことで、新しい技術が出てきた際のキャッチアップを高速化することも可能です。

また、汎用的で枯れた技術ですので、IT業界特有の流行り廃りに振り回される可能性が低く、継続した学習さえ続ければ強力な武器になると思います。

 

UNIX関連

広義のシステム開発において、Linuxは切っても切り離せない存在です。この本では各種操作コマンドや扱い方、Linuxの元となるUnixの設計思想などを学ぶことが出来ます。

初めてエンジニアになる方の中には「WindowsMacしか触ったことが無い」という方もいらっしゃると思います。近年のエディタや環境構築の進化は凄まじく、コードを書くだけなら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での自然な書き方を学べます。また、後述するテストの書き方、デバッグ方法の説明も手厚く書いてあります。読者に寄り添った文体で人気の入門書です。

また、著者の伊藤淳一さんはQiitaにも記事を投稿しており、RSpecの解説記事にはかなり助けられました...

使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

 

プログラミングの初学者の方にもおすすめなRailsの入門書です。

Ruby及びRailsでよく使用される整数、文字列、配列、ハッシュと言ったオブジェクトの理解にも役立つと思います。

Railsで必要となる知識を学ぶことをゴールにしているので、メソッドやクラス、モジュールの作り方、使用方法など、最低限必要となる知識を効率良く学べます。

また、以前弊社の勉強会でもこちらの本を採用し、勉強会の議論のネタに使わせていただいておりました。

Rubyは国産言語でもあることから、読みやすい本が充実しているのが良いですね〜

 

最後に

今回紹介した本は、全体的に「ブラックボックス化されている部分を理解する」という書籍の紹介が多めです。

エンジニアにおいて「何故動作しているのか分からないが、動いているので問題無い」というのは、今後不具合などにより損害を生み出す可能性が極めて高くなり、保守の観点における責務を放棄していると言えます。

サービスを「より早くリリース」「より安全に動作させる」「より長く使われる」ことを追求し続ける姿勢を持ち続けることが、チーム、顧客、市場から求められるエンジニアになる唯一の道と思っておりますので、今後も学習を続けていきたいと思っています!

今後も良い本があったら、記事を適宜アップデートしていきたいと思います!

Railsエンジニア互助会

技術顧問の五十嵐(igaiga)です。今日はクルーバー社内で開催している 「Railsエンジニア互助会」 についての話です。

クルーバーでは複数のサービスを開発するため、複数のチームに分かれて開発しています。複数チームごとに分かれていることは対象ドメインごとに開発するのには有利ですが、一方でRailsRubyなどの技術知識はチームを横断して情報交換した方がメリットがあります。

そこで週1回30分、各チームからエンジニア有志が集まって「Railsエンジニア互助会」を開催してみることにしました。たとえば次のようなことを話しています。

 

  • 日々の開発で疑問に思ったことを質問して議論
  • ライブラリのアップデート情報、またそのときに踏んだ問題点の共有
  • 最近の勉強回やカンファレンスで講演された話の共有

 

実際に話した例を1つ紹介します。参加している同僚から「なぜかこのリポジトリでだけこのコードが動かないのですけど……」と相談されました。簡略化すると次のようなコードでした。

 

def method(*args, **kwargs, &block)
  # ...
end

 

私がたまたまキーワード引数仕様変更の話を調べたばかりだったので「Ruby2.7で導入された記法 **kwargs をRuby2.6でつかっているのではないか」と仮説を立て、結果的にそれが当たりでした。最近Rubyを始めた人がこの仮説に気づくのは難しいですし、気づくためにはこの問題とは関係ないことも調べる必要があり、時間がかかりそうな問題です。このように、「知っている人に聞けばすぐわかること」を解決するときに互助会はたいへん便利です。

 

ここでのキーワード引数仕様変更の話は、私の記事「Ruby3.0キーワード引数仕様変更に伴う書き換えをしたので調べたことのまとめにまとめていますので興味がある方は読んでみてください。

igarashikuniaki.net

 

そのほかにも徳丸先生の記事「2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか | 徳丸浩の日記」を読んで自分たちのコードベースでのCookieに関する内容を議論したり、Dockerをつかって構築している開発環境を改良してもっと便利に開発できるようにならないかを議論したりしました。誰かが何かを説明するというよりは、みんなで議論をしながら問題を解決したり理解を深めたりしています。

 

この互助会を始めるにあたり、ピクシブさんの互助会の仕組みを参考にさせていただいてます。 

ピクシブフロントエンド互助会の取り組み - pixiv inside

同じような進化をしていくのか、独自の文化が生まれていくのか、私も楽しみながら運営していこうと思います。

 

クルーバーでは一緒に開発するメンバーを大募集しています!

採用情報 | 株式会社クルーバー ZERO TO ONE事業部

 

エラスティックリーダーシップ読書会


技術顧問の五十嵐(igaiga)です。今日はクルーバー社内で開催している 「エラスティックリーダーシップ」 の読書会についての話です。

 

www.oreilly.co.jp

エラスティックリーダーシップとは

エラスティックリーダーシップは2017年05月に発売された、自己組織化されたチームをつくるために、どのようなリーダーシップを取っていくべきかを解説した書籍です。

また、オライリーの書籍説明には次のように書いてあります。「チームをより良くする実践的なヒントが詰まっており、チームリーダーやマネージャーだけでなく、チームで成果に取り組むすべての人におくる一冊です。」私はこの本はリードする人だけでなく、リードされる人たちにとっても学びが多い書籍だと考えています。リーダーが求めることを知ることは、リードされるときの勘所を得ることにもなるからです。また、みんなで読むことでリーダーをする人とチームメンバーに共通認識を作ることもできます。エンジニア職種ではリーダーをやることに苦手意識を持っている人も多く、リーダーの負担を減らすことは効果が高いと考えていて、この本の読書会はその一助になるものだと考えています。

 

読書会の進め方

読書会は毎週1回、1時間で開催しています。前半30分程でその日の範囲を読み、学んだことやみんなで話したいことを書いて、後半30分でその内容をみんなへ説明する形式にしています。同意や、フィードバックをしたい人は付箋に書いて追記していきます。この方法は技術顧問をやっている別の会社Classiさんでkiryuanzuさんに教えてもらった方法(エラスティックリーダーシップ読書会 修了レポート - Classi開発者ブログ)をクルーバーでも取り入れてやってみました。付箋をつかったコミュニケーションが促進されて、良いやり方だと感じました。

 

みんなで書いてできあがったページはたとえば次のようなものです。

f:id:iga_k:20220111121436p:plain

 

この本は私もとても好きな本なので、いろいろな会社で何度も読書会をやっていますが、今回も新しい発見がいろいろとありました。一緒に読書会に参加してくれた参加者のみなさんに感謝です。

 

f:id:iga_k:20211221122301p:plain

集合写真

クルーバーでは一緒に開発するメンバーを大募集しています!

採用情報 | 株式会社クルーバー ZERO TO ONE事業部

 

パーフェクトRails読書会

技術顧問の五十嵐(igaiga)です。今日はクルーバー社内で開催している「パーフェクトRails」の読書会についての話です。

パーフェクトRuby on Rails 増補改訂版とは

パーフェクトRuby on Rails 増補改訂版(以降、パーフェクトRails)は2020年7月発売された、Railsの実践的な技術を広い範囲に渡って解説している書籍です。各筆者が個性を活かして書いています。

 

目次を見ていただけるとカバーしている範囲の広さを感じていただけるのではないでしょうか。入門よりも実践を重視していて、Railsの書籍の中では難易度が高めの本になります。

私も執筆に加わっており、思い入れが深い本です。

gihyo.jp

パーフェクトRailsの読書会

読書会は毎週1回、1時間で開催しています。決めておいた範囲を事前に読んでもらって、疑問点や話したいことを参加者の共有ページに書いてもらう形で進めています。その質問をベースに議論をしていきます。質問が多いときはここにたくさん時間をつかい、質問が少ないときは、私から内容の概略を説明したり、書かれていない裏話を話す時間に充てています。

事前に予習してもらうこの方法だと、時間の効率が良いのがメリットですが、忙しいときや難易度が高い範囲は読んで質問を出すのが難しいという問題もありました。これを材料として次の読書会では工夫してみました。(詳しくはまた次回以降のこのブログで)

f:id:iga_k:20210921183206p:plain

こんな質問が出ました

出た質問の例です。長い議論をしたものもありますが、まとめてかんたんな回答例も書いてみました。

  • Q. 「設定より規約」は、他の言語でもRailsのような規約が同様にあるものなのか?

  • A. Railsより後に出たWebフレームワークは同様の規約があることが多いと思います。「設定より規約」はRailsの大きな発明でした。

  • Q. migrationファイルのメンテナンスの方法は?

  • A. 何もしなくても良いですし、定期的にファイルをまとめる運用をすることもあります。

  • Q. Railsではデフォルトで動作するRackミドルウェアが複数あるが、Rackミドルウェアを追加したり自作しようとするケースはどんなものがあるか?

  • A. たとえば、認証に関するものや、リクエストやレスポンスのヘッダを元になんらかの処理するものなどがあります。Railsアプリ全体に対して実行する処理はRackミドルウェアに向いているかもですね。

  • Q. Gemの選定のコツなどありますか?

  • A.更新されているか(超大事)、やりたいことに対して大きすぎないか、Gemを使わないで書くことはできないか、Gemをつかうのとどちらが楽か、といったところを私は考えて選んでます。

パーフェクトRailsをより楽しめるポッドキャスト texta.fm

著者の1人であり、ピクスタ株式会社CTOでもある後藤優一さんが、同社技術顧問の和田卓人さんと話しているポッドキャストtexta.fmを公開しています。Railsアプリの設計は一般的な設計論と比較するとどのような位置づけであるのか、Railsアプリとして良い設計とはどういったものなのかを書籍よりも踏み込んで、かつ、とてもわかりやすく解説している、とても良いポッドキャストです。

パーフェクトRailsを読み終わった方は、こちらを聞くとさらに理解を深めることができると思います。私も聞いた後でRailsについての捉え方と理解が一段深くなったように感じました。お勧めです。

anchor.fm

次の読書会

4月にスタートしたパーフェクトRails読書会は8月に約20回開催して完走しました。次の本として現在は「エラスティックリーダーシップ」の読書会をやっています。こちらの様子もまたブログに書きたいと思っています。おたのしみに。

 

クルーバーでは一緒に開発するメンバーを大募集しています!

https://www.zerotoone.co.jp/recruit/ 

 

www.zerotoone.co.jp

Kaigi on Rails 2021 をスポンサーとして応援して論理ブース出展しました

技術顧問の五十嵐(igaiga)です。Kaigi on Rails 2021 が10月22日, 23日にオンライン開催されました。

 

弊社クルーバーもスポンサーとしてKaigi on Railsを応援するとともに、メンバーが業務の一環として参加して講演を聞きました。

 

kaigionrails.org

 

講演はどれも興味深く勉強になりました。特に基調講演で話されたkamipoさんと
Rafaelさんはお二方ともキャリアとモチベーションの話をされていて、聞いていると私もモチベーションを得られました。基調講演は良いものだと感じる良い基調講演でした。

 

クルーバーから参加したメンバーに感想を書いてもらいました。

 

kim 「会社で進めているプロジェクトにマッチする話(システムテストなど)がいくつかあったので参考になりました。また、reBakoというオンラインイベント会場のツールを初めて使いましたが、今後、社内のイベントなどで導入できれば良い刺激になって面白いのではないかと思いました。」

 

Ryo言語に限らずシステム開発で意識すべき課題や、開発中に当たった壁など、実体験を元にした話が多く、共感出来る部分が非常に多かったです。

また、著名な外部のエンジニアの方と会話でき、率直に楽しかったです。今後より建設的な議論をするためにも、スキルを上げなきゃ……といい刺激になりました。

 

また、今回のイベントの特色として、論理空間上でのスポンサーブース出展がありました。先ほどの感想でも出てきたツール reBako をつかって、論理空間上にスポンサーブースをつくってそこで参加者さんを待ちます。机と椅子が用意されていて、椅子に着席すると動画や音声で通話できる仕組みです。実際に話しているときの様子はこのような感じです。

 

f:id:iga_k:20211026142700p:plain

reBako

左の3人が弊社のエンジニアで、そこへkinoppydさん(RubyKaigi Takeout 2021 感想戦@仮想三重でご登壇)、yasulabさん(今回のKaigi on Railsにて『学習者に聴く!Ruby on Rails 学習者の「今」』でご登壇、また後述のプレイベントにもご登壇)、hasumikinさん(RubyKaigi takeout 2021にて『PRK Firmware: Keyboard is Essentially Ruby』でご登壇)が弊社ブースへ遊びにきてくれたときのスクリーンショットです。みんなでワイワイ話すのは、物理開催されていたころのテックイベントを思い出す、良い体験でした。

 

みんなreBakoを初めて使うのでいろいろと未知な点もありましたが、1日目でわかった「着席しづらい」という問題を2日目は「近くに来た方へDMで声かけする」「テーブル招待機能をつかう」といった手段が公開され全社で解決を試みるなど、みんながツールを使うことに慣れていくたのしさもありました。

 

reBakoはとてもよくできたツールで、物理スポンサーブースに一歩近づいた感がありました。つかってみて気づいた機能要望としては、近くを歩いている人とかんたんなテキストコミュニケーションをできたら嬉しいなと思いました。音声だと敷居が高いですが、テキストや絵文字であれば普段つかっているので気軽に複数人でお喋りができて楽しいかもと思いました。

 

また、本会に先立ち10/10にはプレイベントとして Kaigi on Rails _2021_ new が開催されました。

オーガナイザーである大倉さんの「初学者からベテランまでみんなが楽しめるイベントにしたい」という想いの1つの実装として、主に初学者へ向けたイベントとして開催され180人の登録者を集めました。

私もチェリー本の著者の伊藤さん、RailsチュートリアルRailsガイドの日本語翻訳版を運営する安川さんと共に座談会でお話ししました。

kaigionrails.doorkeeper.jp

 

gihyo.jp

railstutorial.jp

 

座談会は次のテーマで話されました。

 

  • 書籍やスクールで学べることと、現場でエンジニアとして働く(採用される)ことの一番のギャップは何だと思いますか?それを埋めるにはどうしたらよいでしょうか。
  • もし今初学者としてWeb(Rails)エンジニアを目指すとしたら、何をどのような順序で学んでいきますか?
  • おおよそ3年目くらいまでに身につけておきたい知識とそのレベル感とは?
  • 「一人前」とはどういう状態なのか、それに近づくにはどうすればよいと思いますか?

 

三者三様の意見がでてきて、参加している私にとってもとても楽しい時間でした。興味を持った方はイベントページから録画された動画へのリンクがありますので、ぜひ見てみてください。

 

どれも良いお題ですが、私は特に「もし今初学者としてWeb(Rails)エンジニアを目指すとしたら、何をどのような順序で学んでいきますか?」が面白い問いだと感じました。理由は私がたどってきた道と、これから学習していくみなさんとでは背景や状況が違うので、私の経験からだけでは答えが出ないからです。

 

私が初めて学んだRailsはバージョン2.3でしたが、当時はWebアプリ開発にみんなそこまで慣れているわけでもなく、JavaScriptも素朴であり、アセットパイプラインもなく、Bundlerもなく、GitもGitHubも知らない、そんな時代でした。環境が整備されていないが、技術を1つ1つ登場のタイミングで学んでいく時代です。また、他の言語を学んだ人がRailsにやってくることが多く、Rubyの書籍の多くもそれを前提にしていたような気がします。

一方で現在はあらゆる環境が揃っていて、それを一度に学ぶ必要があります。効率は良くなりましたが、学ぶ対象が増え、しかもそれらが一度に押し寄せるのが難しい点です。とはいえ、学ぶときは一歩ずつという基本は同じだと思うので、私なりの答えを書いてみます。

 

最初に「ゼロからわかる Ruby超入門」「Railsの教科書」で基礎を学んで、「Railsガイド」の前半分ほどを読んでRailsの機能やメソッドを把握します。そのあとは「現場Rails」「独習Rails」「Rails6実践ガイド」などの入門書から1冊もしくは複数冊選んで学んでいきます。ここでRailsのレシピ本(逆引き本)があるとすごく良いのですが、現在は無いのが残念なので、誰か書いてください。次はフロントエンドを学んでいって、そこでRailsかフロントエンドか、どちらをメインでやっていきたいかを決めるのではないかなと思います。

 

また、開発環境構築も難しい問題で、最初にやる作業なのにこれがとても難しいという課題があります。GitHub CodespacesVisual Studio Code for the Web が扱いやすくなればブラウザだけでRails開発環境構築ができるので、ここはすごく期待しています。「Railsチュートリアル」でもWeb上で動作するAWS Cloud9をつかった環境構築を説明しています。理想的にはこれらがさらに一歩進んで、アカウント登録不要で、かつ、無料枠である程度の学習ができる状況になるといいなと願っています。

 

Railsエンジニアを目指すみなさんの学習の旅路が楽しいものになりますよう応援しています!

 

そしてクルーバーでは一緒に開発するメンバーを大募集しています!

 https://www.zerotoone.co.jp/recruit/ 

 

www.zerotoone.co.jp

 

アップガレージ店舗で利用する入庫商品登録機能リニューアル

Crooooberの宮川です。アップガレージの店舗に導入されている基幹システムの開発・運用を担当しています。

 

アップガレージではタイヤ、ホイール、カーオーディオ、カーナビなどの車のパーツをお客様から買い取りをしています。今回は、店員さんが商品を買い取ってアップガレージの在庫商品として登録する機能をリニューアルしました。

 

入庫商品登録機能

いままではデジカメで写真を撮影して、PCへ転送してから登録が必要でした。今回の機能開発によってスマートフォンから商品登録が可能になりました。スマフォで撮影した写真を転送せずにそのままブラウザから登録できるので、転送する作業が不要になり、店舗の業務改善に一役買っています。

 

f:id:iga_k:20210813183918p:plain

f:id:iga_k:20210813183922p:plain

 

f:id:iga_k:20210813183932p:plain

利用技術と課題

技術スタックとしては他のサービスと同様にフロントエンドにNuxt.js、バックエンドにRailsをつかって開発しています。開発が難しかったところとしては、Crooooberのシステム全体が古いシステムと新しいシステムが共存している過渡期で、新旧システムでデータ同期が必要なことがあります。今回新しく実装した範囲でも古いシステムを一部考慮しなくてはならないので、その整合性を考える部分で難易度が高くなっている部分もありました。

 

今後の展望

今回の新機能でスマフォで業務できる範囲が増え、重要な作業である商品買い取りの業務改善を一歩進めることができました。今後、蓄積されたデータを分析したり、分析データによって業務作業をアシストするなど、より便利に業務を進められるような改善を続けていきます。

 

クルーバーでは一緒に技術的な課題を解決していく仲間を募集中です!

www.zerotoone.co.jp