はじめに こんにちは。先日、社内にてSBOMに関する勉強会を行いました。この記事では、そこで学んだことを解説していきたいと思います。 具体的な内容は以下の通りです。 SBOMとは何か SBOMを導入するとどんなメリットがあるか SBOMを導入するにはどんなことに気を付けて何をすれば良いか SBOMにはどんな種類があるのか 特に、SBOMに興味はあるけど具体的に何していいかわからない、という方に参考になると思っています。少々長いですが、最後まで読んでいただけると嬉しいです。 それでは、順番に説明していきます。 SBOMとは SBOMとは、ソフトウェア部品表(Software Bill of Materials)、つまり、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストのことです。 ソフトウェアに含まれるコンポーネントの名称やバージョン情報、コンポーネントの開

https://increments.connpass.com/event/310090/ 2024/03/01「Wantedly x Qiita Meetup #2 Rubyを用いたプロダクト開発」の資料です。 本発表では、モデリングという役割を持つバックエンドエンジニアこそ、 開発段階からユビキタス言語作りを主導すべきという話をします。

みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック

昨年の8月からランサーズでLLM Labsを立ち上げ、あたらしい開発チームで今年2月にオートロンをリリースした。生成AIがでてきてからはもっぱらプログラミングが快適で楽しくなったため、僕も戦線復帰して一介のエンジニアとしてもチームに参加している。 コミュニケーションって大事なの？これまで自分がリモートでフリーで受託開発をメインでやってきたため、コミュニケーションについて深く考えることはなかった。対クライアントだけの話であるし、メールやチャットだけで話が進んでいくことも多かった。 しかし、MENTAをつくりユーザーが増え、ランサーズに売却した後、サービスの規模も大きくなったためエンジニア、営業、デザイナー、サポートなど関わる人が増え、チームで働く機会が増えた。最初のうちはテキストコミュニケーションだけで大丈夫だろうと思っていた。なぜなら自分がそうだったから。 でもそうではないと気づく。気がつ

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 28週目の記事です！ 1年間連続達成まで 残り25週 となりました！ はじめに チーム目標を設定する際、メンバーの多様な思いや方向性を理解し、一つにまとめあげることは、思っていた以上に難しいなと感じておりました。 皆さんは、チームでの目標設定や振り返りをどのように行っていますか？ 私たちはまだ完璧な方法を見つけ出せてはいませんが、チームで様々なワークショップを手探りで試行錯誤しながら、その過程で得た学びや感想を共有していきたいと思います。 前提 ログラスでは、全社的にOKR（目標設定のフレームワーク）を採用しています。このフレームワークを用いて、チームOKRや個人OKRを3ヶ月ごとに策定しています。 OKRの詳細についてはここでは深入りしませんが、大まかには以下の2つの要素から構成されていま

原　拓志 現代の製品開発・生産のマネジメントにおいて、理解しておくべき概念の1つが「モジュール化」である。「モジュール化」とは、全体システムを、いくつかの下位システム（モジュール）にわけ、モジュール間のインターフェイスを標準化することによって、システム全体の構造を変革することなく、モジュールの取替や組換えによって、システムの機能を維持ないし変更できるようにする方法である。システムがハードウェアでもソフトウェアでも問わないし、比喩的に社会システムに適用することも可能だ。大量生産方式を特徴づける部品の互換化とも共通点があるが、互換部品が通常は同じ機能のものを指すのに対し、モジュール化の場合は、異なる機能のものも組換え可能にし、全体システムの機能を変革することも狙いにするところが相違する。 「モジュール化」のメリットの1つは、全体システムの変革に際して、変革を局所化することにより変革に伴う効率の

はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？　また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？　今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重

SmartHR におけるスクラム開発の歴史と変遷@スクラムフェス大阪2022 / smarthr-scrum-history-20220618

前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳

こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ

プロダクトゴールとしてプロダクトのありたい姿を定義し、チームがそのビジョン実現に向かうミッションを背負いながら一致団結して働くということは多くの人が実践しています。アジャイル開発であればインセプションデッキでそれを決め、それを方針に、時にアップデートしながらプロダクトのコンパスの役割を果たしていきます。ゴールが明確であれば、それに向かっているかどうかはわかりやすくなるでしょう。ゴールめがけて進む中で、より多くを知ったら、それに合わせてプロダクトを変えるか、ゴールを変えるかができからです。 プロダクトやプロジェクトのゴールはあたりまえに設定されます。それはビジネス上の成果に直結するからであり、それにより設定することを求められるからでもあります。では、チームの場合はどうでしょうか。チームとしてのゴール、ありたい姿を共通認識として定義して、それに向かって検査と適応を繰り返すこともプロダクトゴール

はじめに アジャイル開発では、技術やビジネスといった側面だけでなく、開発を担う人々の「人的側面」への取り組みが欠かせません。この記事では、その「人的側面」を強化する効果的なアプローチとして、「システムコーチング®」を紹介します。 特に「アジャイル・フルーエンシーモデル(アジャイルのプラクティスを包括的にまとめるモデル)」とシステムコーチングとの相互補完性に焦点をあて、ログラスの事例を交えて具体的な効果を探ります。システムコーチングを導入することで、チームや組織にどのようなインパクトがあるのか、そのポイントをお伝えします。 アジャイル開発とは アジャイル開発は、顧客の要求に迅速に対応するためのソフトウェア開発手法の総称です。短期間のイテレーションを通じて、開発チームは頻繁に製品のリリースを行い、顧客のフィードバックをすばやく取り入れることができます。 このアプローチはその柔軟性と迅速性により

2024/2/15 Developers Summit 2024 で発表したスライドです （概要） Platform Engineeringは、Gartnerが発表した2024年トップ10の戦略的テクノロジートレンドにも登場しており、5年以内にソフトウェアエンジニアリング組織の80%が採用するだろうとも予測されています。「インフラに関わっている人だけに関係がある話なんでしょ？」とよく勘違いされがちなのですが、実は全Developerが実践できるものです。本セッションでは、様々なバックグラウンドを持つ、Platform Engineering Meetupのメンバーが「すぐにでもPlatform Engineeringを始められる」ためのノウハウや実践方法を紹介します。 https://event.shoeisha.jp/devsumi/20240215/session/4807

はじめに Java の enum は大変便利で非常多くのシーンで活用されています。例えば区分を表すようなオブジェクトを表現したい際にもよく使われていますね。 Java 14 で正式機能となった switch式にて網羅性検査が行えるようになり、それまで以前ではどうしても抽象メソッド等を活用する必要があった処理についても、switch式を利用する事で簡潔に表現することができるようになりました。 また、Java 17 で正式機能となった sealed classes/interfaces と Java 21 で正式機能になった Record Patterns によって、これまで必要だった区分値のような enum を必ずしも定義しなくて良い場合も出てきました。 この記事では、今まで enum を使っていたコードがこれらの機能によってどのように変わるのかを紹介し、盲目的に enum を定義するのでは

1on1に唯一無二の正解はない 櫻井将氏（以下、櫻井）：最後に、じゃあ「フィードバック」と「聴く」ことをどうやって両立するんだっけ、ということを話します。「フィードバック」だけでも「聴く」だけでもダメだと思うので、ここの両立について。 私も「聴く」ことや1on1について散々伝えているので、「1on1の正解を教えてください」とよく言われるんですけど、最初にお断りしておくと、これにはちょっと答えられないなと。 やはり関係性や相手の状態によっても違うし、自分側のスキルや得意や好きなものによっても異なるので、唯一無二の正解はないなと思っていて。ただ「こんな感じでやったらうまくいくよ」という定石のようなものはあると思うんです。 料理でもそうなんですけど、「肉じゃがの正解を教えてください」って言われても、唯一無二の正解はたぶんないと思うんです。ただ、「こうやったらだいたいうまくいくよ」みたいなものがあ

JaSST 23 Tohoku https://www.jasst.jp/symposium/jasst23tohoku.html

2024/2/16 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215 ■ ZOZOエンジニア向け会社説明資料 https://speakerdeck.com/zozodevelopers/company-deck ■ GitHub Universe 2023 https://githubuniverse.com/ ■ Universe 2023: CopilotがGitHubをAIを駆使した開発者プラットフォームへと変貌させる https://github.blog/jp/2023-11-09-universe-2023-copilot-transforms-github-into-the-ai-powered-developer-platform/ ■ GitHub Universe 2023 o

マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

株式会社オープンエイト、PMグループの辻です。 ここでは、プロダクトマネージャーとして働いています。ということで・・・ プロダクトマネージャーのしごと 少し前に話題になった本、皆さんも読みましたか？ この本は、これまでのプロダクトマネジメント関連の書籍と比べて、リアルな現場の目線に近いカタチで書かれており、参考になった以上に、とても勇気をもらえる１冊でした。 これまでのプロダクトマネジメント関連の本 どちらかと言うと教科書的なものが多い 参考にはなるが、自社や自分の置かれた環境で上手く実践まで持っていくのが難しい そんな印象を抱かれている方も多いのではないでしょうか？ これまでのプロダクトマネジメント関連の本。たとえば、コレ。 これはこれで、オススメです。 この本の特徴・効能 一方で「プロダクトマネージャーのしごと」を読むと、 世界的に著名なプロダクトマネージャーであっても、自分と同じよう

Hello Actor 細かい機能の解説はあとの回として、 まずはアクターシステムを使ったプログラミングを体験してみましょう。 Goではアクターシステムが商用でも十分利用できるものは、 下記のProto Actorとergoがあります。 github.com github.com Proto.Actorは、Akka.NET のオリジナル作成者 Roger Johansson によって開発されているもので、 Akka/Pekko と基本の部分がある程度似た形になっています。 あくまで似ている程度で、現在のAkka/Pekkoほど強力なツールが揃っているわけではありませんが、 Proto Actorで概念や作り方を覚えると、少ない労力でAkk/Pekkoにも移行などもができるようになります。 細部は異なりますが、概念などはかなり似ていますのですんなり理解できるはずです。 ergoは Erlan