はてなブックマーク

こんにちは、ハコベル開発チームの坂東です。 プロダクト開発に携わっていると、 エンジニアごとに実装イメージが異なる コードレビューの段階で要件についての議論が発生する QA 終盤で実装漏れに気づき、慌てて修正する スプリントレビューで仕様の取り違いを指摘される などの問題に直面することはありませんか？ こうした問題は、複雑な要件の開発が多いチームほど深刻になりがちです。 そこで私たちのチームでは、「実装前にシステムの振る舞いを洗い出し、チーム全員で合意形成を行う」ことを重視しています。 今回は、その具体的なアプローチと合わせて、取り組む際のポイントや注意点についてもご紹介します。以下でスライドでも公開していますのでぜひご覧ください。 背景： 複雑な要件の開発に伴う課題 私たちのチームはスクラムをベースにした開発スタイルを採用しており、エンジニア・QA・PdM のメンバー構成で動いています。

始めまして。ハコベルで、テックリードを務めている横山怜です。 本記事は先日のハコベル初のMeetupイベントにて行ったLT「スクラムマスターとして取り組んだ開発プロセスの改善」を、より詳しくテックブログの記事として再構成したものです。プロジェクトの現場で実際にどのような課題と向き合い、どのように改善を実施してきたのか、その軌跡を紹介します。 記事の内容 新卒で入社した自分が当時の開発チームのスクラム体制に疑問を持ち、スクラムマスターになってから開発プロセスを改善するまでの流れを、具体的なエピソードを交えてご紹介します。 特に、QA工程の改善に苦労しながらも成功に導いた取り組みについて、詳しくお伝えできればと思います。 そもそも何を変えたかったのか 当時の状況：なんちゃってスクラム時代 私たちのチームは、形式上はスクラムのイベントを取り入れていましたが、実際の運用は以下のようなものでした。

みなさんは VSCode の設定をどのように管理していますか？ この記事では、プロファイル機能を使って VSCode の設定をきれいに保つ方法を紹介します。 結論 私は VSCode の設定を以下の3つに分類して管理しています。 ① どのワークスペースでも有効化したい設定 → 既定（Default）のプロファイルで管理する ② 特定のワークスペースにおいて、チームで合意した設定 → 各ワークスペースの.vscode/settings.jsonで管理する ③ 特定のワークスペースにおいて、個人的に有効化したい設定 → 各プロファイルで管理する 前提 VSCode の設定には異なる2つのスコープが用意されています。 ユーザー設定 ワークスペース設定 簡単に言うと、ユーザー設定はグローバルに適用される設定、ワークスペース設定は特定のフォルダにおいてのみ適用される設定です。 ワークスペース設定はプ

ID: 正の整数であること 日付: YYYY-MM-DD 形式で、存在する日付か 数量: 0以上の数値 上記のように、ひとつの行の中でも複数のセルにエラーが含まれる場合が十分ありえます。 従来の try-catch を使ったエラーハンドリング まずは、try-catchを使用してJavaScriptにおける標準的なエラーハンドリングがどのように動作するかを確認しましょう。 サンプルコード function validateId(idStr: string): number { if (!idStr) { throw new Error("IDが空欄です"); } const id = parseInt(idStr); if (Number.isNaN(id) || id <= 0) { throw new Error("IDが不正です"); } return id; } function

マルチカーソル機能の使い時 筆者がマルチカーソルを使用したくなる場面を3つ紹介します。 1. 命名を一括変更するとき 変数名や関数名を一括で変更するときに、マルチカーソル機能を使うことで、短時間で変更を行うことができます。 命名を一括変更している様子 検索バーから一括変更する方法もありますが、その場合カーソルが残らないため上記GIFのように複数の命名を試行錯誤しながら変更することができません。 2. 特定の範囲に閉じた修正を行うとき 特定の範囲に閉じた修正を行うときにもマルチカーソル機能は有用です。 特定の関数に閉じた修正 こちらは検索バーから一括変更してしまうと、下のfuga()関数にも変更が適用されてしまいますが、マルチカーソル機能を使うことで意図した範囲の修正に留めることができます。 3. フォーマットを変更するとき 以下のGIFではCSVで定義されたデータをMarkdownのドキュ

この記事では、ハコベル配車計画の0→1フェーズのSaaSプロダクトにおいてGraphQLを採用した経験から感じたGraphQLへの向き合い方について紹介します。 スライドでも公開していますのでぜひご覧ください。 また、この内容についての発表は下記で配信されていますので、こちらもぜひご覧ください。 プロダクトの背景 2022年に、物流DXを実現する新たなSaaSを作るプロジェクトが始まりました。 今まで経験と勘を頼りに行われていて属人化していた配車計画業務にフォーカスしています。この業務を仕組み化し、AIアルゴリズムを用いて配車計画を支援することで業務効率化と属人化の解消を目指したプロダクトです。 しかしながら、当時はアルゴリズムの精度やUIなどが本当にお客様にとって使えるものなのか、仮説が正しいか確証が持てていない状態でした。そのため、先行導入頂いたお客様にフィードバックを得ながら、共同で

はじめまして！24卒でハコベル株式会社のサーバーサイドエンジニアをしている磯貝です！ ハコベルでは、『ハコベル配車管理』というサービスでRuby on Railsが使われています。 この記事は内定者インターン〜入社後数ヶ月の僕がビビりながらもRuby on Railsのバージョンを6系から7系にアップデートした記録です。 Railsのアップデートに関心がある方や、同じような課題に直面している方の参考になれば幸いです。 大まかな流れ 今回は以下のような流れで行いました。 Railsのパッチバージョンを最新に更新 Railsのload_defaultsを6.1までアップデート Rails以外のgemを可能な限りアップデート Railsのメジャーバージョンアップ それでは順に見ていきます。 1. Railsのパッチバージョンを最新まで上げる まずはRailsのバージョンを6.1.7から6.1.7

こんにちは、ハコベル開発チームの坂東です。今日は、実際に私たちのチームで起きたちょっとした“怖い話”を共有しようと思います。 開発は順調に進んでいたはずだった… 私たちのチームでは、これまでプロダクトをローカル環境で動かす際、ファイルアップロード系の処理では開発用のAWS環境に直接アップロードするようにしていました。 しかし、複数のAWS環境を跨ぐような開発をする時にやりづらいので、効率化のためにローカル環境でAWSをエミュレートできるLocalStackを導入することにしました。LocalStackは、他のチームでも導入実績があったので、安心して導入に踏み切りました。 一人のメンバーがLocalStackを組み込んだPRを作ってくれ、みんなでその動作確認をすることになりました。ところが、全員が同じブランチで動作確認しているにもかかわらず、うまく動くメンバーと、うまくいかないメンバーが出て

ハコベルで品質保証のマネージャーをしている小林です。 今回は元々の自分の専門領域であるソフトウェアの品質について記載しようと思います。 対象読者 ソフトウェアの品質に関心を持つ開発者やテスターの方 ソフトウェアの品質に関する基礎知識や規格を学びたい方 ハコベルのサービスや開発体制に興味のある方 そもそもソフトウェアってなに？ ソフトウェアでググると、以下のように定義されているようです。 コンピュータを動作させる命令の集まりであるコンピュータプログラムを組み合わせ、何らかの機能や目的を果たすようまとめたもの。 (ソフトウェアとは - IT用語辞典 e-Words) この文章だと具体性がないので結局どんなものなのかがイメージしづらいですが、要するにみなさんのPCやスマートフォンなどで動いているWindows、macOS、Android、iOSや、その中で動作しているChromeやEdge、Ex

背景 ハコベル株式会社システム開発部 一般貨物運送手配システムG の坂東です。普段はサーバーサイドエンジニアとして、ハコベル配車管理の開発を行っています。 ハコベル配車管理のバックエンド処理は、Ruby on Railsで構築されています。このRailsアプリケーションにおける諸々の設定管理には、従来はSettingslogicというgemを使用していました。 Settingslogicではアプリケーションの設定を簡単に取得し、利用することができます。 具体的には以下のようなyamlファイルを用意し、

前回の記事では、GraphQLをプロダクトに投入するにあたり検討したエラーレスポンス設計パターンについて紹介しました。 この記事では、フロントエンドとバックエンド間でのバリデーションスキーマの取り決めについて解説します。 GraphQLスキーマ設計で悩まれている方の参考になれば幸いです。 ※ この記事に記載の内容は当時の情報です。最新の状況を反映していない可能性があるため、ご了承ください。 はじめに ハコベル配車計画では、バックエンドとフロントエンド間の通信においてGraphQLを活用しています。1年ほど運用していく中で、設計における課題がいくつか表面化してきました。 今回、社内ハッカソンイベントHackWeek 2023 [1] が開催され、ハコベル配車計画チームでは1年間の運用の中で感じた、GraphQLスキーマの設計における悩みを振り返ることにしました。 バリデーションにおける課題

NFCではそのまま「パ」として表されますが、NFDでは「ハ」（基底文字）と「゜」（結合文字）の組み合わせとしての「パ(UTF-8でe3 83 8f e3 82 9a)」（合成文字）で表されます。試しにNFDで正規化された「パ(e3 83 8f e3 82 9a)」を任意のテキストエリアに貼り付けて削除してみると、半濁音のみが取れて「ハ」のみになると思います。 このように文字列の正規化形式が異なる場合、単純な比較演算子での評価は困難であり、文字列によっては想定外の挙動を引き起こす可能性があります。 特にMacファイルシステムではNFDを正規化方式と採用しているため、NFC/NFD問題が度々引き起こされています。先日(2023年03月27日)リリースされた「macOS 13.3 Ventura (22E252)」では、ファイル名に濁音や半濁音が含まれるファイルがFinderから開けなくなる

ハコベル物流DXシステム開発部の坂東です。普段はサーバーサイドエンジニアとして、ハコベル配車計画の開発に携わっています。 今回の記事では、GoのRepositoryパターンとUnit of Workパターンを組み合わせたトランザクション処理の実装とテストの手法を、サンプルを使って紹介します。 背景 ハコベル配車計画ではドメイン駆動設計(DDD)の思想に基づき、Repositoryパターンを採用してサーバーサイドの開発を行なっています。 Repositoryパターンについて簡単に説明すると、レイヤードアーキテクチャにおいて、永続化層とアプリケーション層の間に中間層としてインターフェースを定義したリポジトリ層を用意したものを指します。このインターフェースを介してアプリケーション側から永続化に必要なメソッドを呼び出すことで、永続化処理の実装実体は隠蔽できるようになります。 つまり、リポジトリ層の

この記事では、普段のリモートワークに月1回のオフィスワークを取り入れ、メンバー同士の相互理解による信頼関係を育むことを目的としたハイブリッドワークの取り組みの内容を紹介します。 ※ この記事に記載の内容は当時の情報です。最新の状況を反映していない可能性があるため、ご了承ください。 背景 ハコベルでは、COVID-19の流行をきっかけに、フルリモートワークの制度を導入しました。もともとチームファーストな評価制度や、情報共有の透明性を重視した行動指針などの取り組みを行っていた背景からフィットし、以前よりも業務効率が高まる効果を得ることができました。 一方で、社員同士が顔を合わせて生まれる一体感や信頼関係が構築しきれなくなったという課題が発生し始めていました。数十名のメンバーがフルリモートワーク下で入社したり、チーム間のメンバー異動も発生したことで、この課題が顕著になってきました。 画面越しのコ

この記事では、ハコベルで行っている開発効率と生産性の向上を目的としたコードレビューを早めるための取り組みについてご紹介します。 サクッと読みたい方はこちらのスライドもどうぞ。 ※ この記事に記載の内容は当時の情報です。最新の状況を反映していない可能性があるため、ご了承ください。 背景 私たちは、ソースコードの管理をGitHub上で行っており、プルリクエストを利用したペアレビューをしています。 一方、事業の拡大によりエンジニアの責務が増加しています。そのため、レビューのタスクが後回しにされ、レビュー待ちがブロッカーになってしまう場面が増え始めていました。 プロダクトの開発効率が低下するだけでなく、開発のリズムが崩れてしまいモチベーションや生産性が低下するといった問題にも繋がってしまいます。 そこで、私たちはコードレビューがブロッカーになることを防ぐために、様々な環境づくりと、仕組みづくりに取

Sailboat Retro Created by Brody (CC BY 4.0) ホワイトボートツールであれば、テンプレートが用意されているのでまずはそのまま使えばOKです。 オフラインであれば、みんなでワイワイお絵描きするのがおすすめです。チームのムードが絵に現れます。 Sailboat Retrospective の特徴 私たちのスクラムチームは、振り返りのフレームワークをKPT法からSailboat Retrospectiveにお試しで変更してみました。 2 Sprintsほど試したところ、 KPT法と比較して次のようなメリットがあることがわかり、チームの振り返り手法として採用することにしました。 短期的・長期的な事柄を区別できる ブロッカーとリスクで分けることで、Problemのコメントが出しやすくなる プロダクトゴール、スプリントゴールに関することに話を集中させることができ