「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 Munetoshi Ishikawa, supported by LINE corporation

株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷（Team Cognitive Load）」について。 名村卓氏のキャリア変遷 大谷旅人氏（以下、大谷）：それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏（以下、名村）：はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っていま

私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、

リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。 このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。 失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフトウェアプロダクトは、そのマネジメントにおいて、常にこれらのリスクを抱えています。 本記事では、機能リリースに伴うこのようなリスクを制御する方法について考えます。 期待する成果が得られないことを前提に計画する機能リリースが期待どおりのインパクトをビジネスにもたらすかどうか。それを事前に予測し、世の中に送り出すべきアイデアを

こんにちは、CX事業本部デザインチームの小峰です。 先日、Agendというメディアさんからインタビューいただきました。 仕事のすれ違いを「ただ、話す」で解決していく、スクラムから学んだチームコミュニケーション―――――クラスメソッド小峰さんインタビュー この中で「ただ話す」を紹介しています。 今回は、これについて少し深掘ってみます。 これを知ったのはインタビューでもお話した通りLeSS Frameworkがきっかけでした。複数チームによるアジャイル開発体制を検討している中で出会いました。いわゆる「大規模アジャイル」の一種です。 「ただ話す」は、大規模アジャイルの学習のために「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」という本を購入し、そこで紹介されていたものになります。 調整と統合 スクラムガイドでは主に1チームでのスクラム

name: Scheduled build on: schedule: # 月曜日の 11:00 (JST) に処理を実行する。 # UTC の 02:00 は JST だと 11:00 。 - cron: '0 2 * * 1' jobs: build: name: build runs-on: ubuntu-latest steps: - name: curl run: curl --show-error -X POST -d {} "${{ secrets.BUILD_HOOK_URL }}" # で始まる行はコメントです。 name の値は処理には影響しないのでわかりやすい値をセットして使うとよいと思います。 記事執筆時点では runs-on に ubuntu-latest を選べば前準備なしで curl が使えました。 リポジトリの Settings → Secrets で BU

2023/05/17(水) Qiita Conference 2023

2023年6月10日に発売の拙著「人が増えても速くならない　～変化を抱擁せよ～」は、経営者やマネージャの方々がソフトウェア開発の経験がなかったとしても、その本質を掴めればと思って書きました。 今や経営や事業をしていく上でITを使ったシステムは欠かせなくなっており、関わらないわけにはいきません。特に、事業そのものにソフトウェアを内包している場合において、ただ使うだけでなく開発して活用していく必要があります。 そこでソフトウェアと、ソフトウェアを作るエンジニアたちをマネジメントしていかねばならないとき、従来通りのマネジメントをしていると、うまくいかないときが出てきます。 ソフトウェアとエンジニアのマネジメントは、ともすれば直感的なものから外れていることがあります。本のタイトルにある「人が増えても速くならない」のも、その一つです。 本書では章の目次ごとに、そうした直感とは違っているソフトウェアな

このコラムの主なテーマは、信頼できる実行結果にできるだけ短い時間でたどり着く自動テスト群の構築です。本稿では、テストダブルをうまく活用してテストピラミッドを構築する戦略を立てます。 信頼性の高い自動テスト群を求めて 自動テスト全体の中長期的な信頼性を守るために、図1のようにLargeからMediumへ、MediumからSmallへテストサイズを適宜下げ、テストピラミッドを構築します[1]。テストサイズとは、単一プロセスに閉じたテストをSmall、単一マシンに閉じたテストをMedium、そういった制約がないテストをLargeテストと呼ぶ分類基準です。 図1 テストピラミッド サイズダウンを考えるとき、テストダブルの活用が思い浮かびます。テストダブルとは、自動テストに使用する偽物、代用品のことです。単一プロセスや単一マシンに収まらない外部依存を偽物に置き換え、テストサイズを下げます[2]。 テ

東京・乃木坂から、「真面目に楽しく」をキーワードにした教育でビジネスパーソンを支援する株式会社ヒップスターゲートの主催イベントに、組織マネジメントの専門家で『遊ばせる技術 チームの成果をワンランク上げる仕組み』 の著者である神谷俊氏が登壇。「社員の自律を促す『新・マネジメント術』とは？」をテーマに、仕事に「刺激」を生み出す必須アクションや、仕事を任せるためのジョブ・デザイン10か条などを語りました。 仕事に「刺激」を生み出す必須アクション 神谷俊氏（以下、神谷）：では、どうやって、仕事の文脈を生み出していけばいいのか。最後に実践的な話をして終了したいと思います。 まず本人が仕事に対して刺激を生み出すために、不可欠なアクションがあります。ジョブ・クラフティング（自分の働き方を見直すことで仕事に対する主体性を引き出す方法）ですね。 いわゆる自分の気持ちや自分の能力レベル、自分の持っているリソー

OpenTelemetry を使用して Node.js アプリケーションを計装する 2023.08.26 OpenTelemetry は Observability のフレームワークであり、トレース・メトリクス・ログなどのテレメトリーデータを作成、管理するためのツールキットです。OpenTelemetry はベンダーに依存しない形で標準化されたプロトコルとツールを提供していることが特徴です。この記事では Node.js アプリケーションを計装して Prometheus にデータを送信する方法を紹介します。

mondでこの質問への回答を読んでみましょう

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Garoon Hanamiチームの土屋（@tsuchikazu）です。以前、この記事 Garoon開発チームを紹介します！ 2023 でGaroonの開発チームの全体について紹介しました。今回は、その中の1つであるHanamiチームについて紹介します。 PHP Conference 2023でもHanamiチームでの取り組みを、チームメンバーが発表しました。そちらもぜひご覧ください。 speakerdeck.com Hanamiチームとは リリースプロセスを改善するチームです。現在、Webエンジニア 4人、QAエンジニア2人の6人（そのうち他チームとの兼務が3人）で構成されています。 Garoonは20年以上前にパッケージ製品からスタートし、その後クラウド版のサービスの提供も開始しました。クラウド版のリリースプロセスも、パッケージ製品時代のプロセスを模倣しており、以下のような課題を抱えてい

生成系 AI を筆頭に技術革新著しい昨今ですが、日本においてそのインパクトは限定的になるだろうと言ったら驚くでしょうか。本記事で IPA や経済産業省のレポートからその予測根拠を示すとともに、インパクトを最大化する方策として AWS がアップデートしてきたワークショップをご紹介します。AWS がサービスだけではなく活用をガイドするプログラムも提供していることを知っていただけたらうれしいです。 ※トップ画像は IBA Boxing の AIBA World Boxing Championships Doha 2015 を使わせていただきました。 生成系 AI のインパクトが限定的になる理由生成系 AI に対するリーダー層の反応をデータから推察することで、インパクトが限定的になる理由が見えてきます。まず IPA ( 情報処理推進機構 ) の 「 DX 白書 2021 」では「企業変革を推進する

こんにちは。ISID 金融ソリューション事業部の若本です。 先日、GPT-4から発展し、画像も扱うことができるGPT-4 with vision（GPT-4V）が発表されました。GPT-4Vは大規模マルチモーダルモデル（LMMs: Large multimodal models）と呼ばれるAIモデルの一種であり、GPT-4の入力として「画像」を拡張したものになります。 今日は Microsoft Researchの論文[1]を中心に、Open AIの発表したSystem Card[2]も踏まえ、GPT-4Vでできることや苦手とすること、そして実用上の制限について解説します。 GPT-4Vの特徴 ① 画像とテキストを入力にできる GPT-4Vでは、GPT-4のテキスト入力に加えて画像も入力することが可能になりました。 画像は複数枚入力することが可能であり、かつ、画像とテキストを任意に交互に組

こんにちは。ファンと共に時代を進める、Web3スタートアップ Gaudiy の seya (@sekikazu01)と申します。 弊社では今 LLM をプロダクトに活用しているのですが、実際にユーザに提供するクオリティのものを作る・運用しようとすると様々な課題が立ちはだかってきました。 そんな数々の課題を解くために LangSmith というツールが活躍してくれた、また今後の活用・発展にもかなり期待ができるため、本記事ではそんな LangSmith について解説していきます。 LLM を使ったプロダクト開発において課題を感じている方々の参考になれば幸いです。 出てきた課題 まず LangSmith 自体の解説に入る前に、我々が直面した・ほぼ間違いなく今後するであろう課題たちをサラッとご紹介しようと思います。 大まかには次のような課題がありました。 プロンプトがアプリケーションコード内に書か

ステップバック・プロンプティングは極めてシンプルで具体的なテクニックながら、CoT（Chain-of-Thought prompting）やTake a Deep Breatheといった既存の手法を凌駕する性能を発揮しています。 参照論文情報 ・タイトル：Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models ・著者：Huaixiu Steven Zheng, Swaroop Mishra, Xinyun Chen, Heng-Tze Cheng, Ed H. Chi, Quoc V Le, Denny Zhou ・所属：Google DeepMind ・URL：https://doi.org/10.48550/arXiv.2310.06117 従来の課題 LLMはSTEM（科学、技術、工学、

イチから全部作ってみよう（1）ソフトウェア開発の大まかな流れを把握する：山浦恒央の“くみこみ”な話（170）（1/3 ページ） ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第1回は、イントロダクションとしてソフトウェア開発の大まかな流れを説明する。 1．はじめに 前回まで、16回にわたり「業務効率化の道具箱」と題して、業務効率化に関するトピックを取り上げました。少しでも皆さんの業務改善の役に立っていれば幸いです。 今回からは新シリーズ「イチから全部作ってみよう」が始まります。筆者が実際に関わってきたECサイトを題材として、入門者向けに、企画の立案、要求仕様書の作成、設計、コーディング、デバッグ、テスト、保守（新機能の追加を含む）まで、プログラマーとしてソフトウェア開発の全工程を学びながら、実際に体験もできるようにします。 さらに

企業・組織に属している方向けの ChatGPT の社会・ビジネスへの影響を考えるお話です。 人とComputerの在り方が大きく変わったこれらも交えて。それらが周囲にあふれ出すその日のために、今はしっかりと Prompt の仕方を学んでおきたいものです。そのためのサンプルも幾つか継続して提示しています - とある人の、変わってしまった日常の一部 - なぜ?何が? ChatGPT で変わるのか? - Plugin の可能性 - Code Interpreter の可能性 - Copilot の可能性

https://hatena.co.jp/recruit/intern/2023

ラブグラフでエンジニアをしています横江 ( @yokoe24 ) です。 ラブグラフでは、エンジニア以外で Google Apps Script (GAS) を書く方も多く、 Slack通知の自動化など、業務の効率化がおこなわれています。 マジですごいと思います！ GASをエンジニア以外が書く問題点 一方で、コードを見るとプログラマーからするとムズムズするところもあります。 変数名に snake_case が混ざっている インデントが揃っていない for文の中で getValue() を回している Google Apps Script の getValue() メソッドはコストが高く、何度も実行するとタイムアウトの可能性が高まる == で比較している double quotes " と single quotes ' が混ざっている こういうコードを見ると直したくてウズウズしてしまいます。

You’ve got a new project to work on. Or you’ve got an existing project you’re motivated to upgrade to a more modern approach. Or perhaps you’re dissatisfied with your current modern framework or second-guessing yourself and you’re investigating alternatives. In any case, you’ve got a decision to make. There are lots of “modern” frameworks to choose from. Even if you’re not facing this choice right

2023/10/25 CTOA若手エンジニアコミュニティ 勉強会 #4

ソケット通信は双方向で遠隔という複雑な条件下のためさまざまなエラーが発生する。 Goでソケット通信を書いていて、言語の力のおかげで記述は楽になっているが、下層で同じOSの機能を使っている以上エラーは避けられない。 そもそも、どんなときにどんなエラーが起こりうるのか、特にGoの net パッケージではどのようにエラーを扱っているのか、今まであまり考えずに正常系のみを実装していたので これはよくないなって思って調べた。 ソケット通信の基本 read と write TCPにおけるソケット通信は基本 read と write である。名前の通り、読み・書きを表す。 ソケット通信でエラーが起きるのは、この read/write の処理の中が多い。 net.OpError によるラップ Goでソケット通信中に起こるエラーはほぼすべて net.OpError 構造体でラップされる。 ただし io.EO

深津 貴之 / THE GUILD / note @fladdict 「ChatGPTと、どうやって一緒にコードを設計するの？」と聞かれたので、サンプルを作ってみました。だいたい、こんな感じでやってます。 chat.openai.com/share/9278e867… 2023-11-04 00:52:53 深津 貴之 / THE GUILD / note @fladdict 基本的に「磯野〜、ペアプロしようぜ！」と誘って、会話しながらやると安定します。「チミチミ、これをやってくれたまえ」って丸投げすると、だいたいダメ 2023-11-04 01:01:59

私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。 どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト／テスト駆動開発」からそのまま引用します。 この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。 一般的なE2Eテストとは一般的な書籍では、テストピラミッドにおける頂点にあるE2E（End-To-End）テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境（たとえば、Docker、あるいは開発用のクラウド環境）にデプロイして「加盟店管理用APIマイクロサービス」をテ

Next.js、Remix、SvelteKit といった近年のフレームワークは、JavaScript がなくても動作することを一つの価値として提供しています。 例えばSvelteKit のフォームではプログレッシブエンハンスメントとして、JavaScript が利用できる環境ではリッチなユーザー体験を提供しつつ、JavaScript が使えない環境においては HTML のフォームとして振る舞うことでアプリケーションの機能を変わらず提供できます。 React Server Component はサーバー側で HTML に変換されるため、クライアントに JavaScript のコードが配信されることはありません。React Server Component では useState() を使用できないといった制約がありますので、我々開発者は React Server Component の利点を

株式会社ICSの池田・西原・松本の3人で『フロントエンドの知識地図 〜 一冊でHTML/CSS/JavaScriptの開発技術が学べる本』という書籍を執筆しました！ ICS MEDIAではHTML・CSS・JavaScriptにおける最新技術をテーマに取り扱っています。ウェブメディアの特性上、記事は断片的な情報となることが多く、体系的な発信が難しいと我々は課題感を持っていました。そこで、この書籍ではICS MEDIAでは発信の難しかった、フロントエンドの全容を一冊で伝えることを目指しています。 2023年11月24日の発売で、Amazonや書店や電子版で購入できます。 Amazon サポートページ 2023年4月に執筆を開始し、フロントエンドのトレンドをまとめてキャッチアップできるようテーマを選定しました。344ページで、紙面はフルカラー。内容の厚みにたいして、定価2,860円（本体2,6

「このコードは既に十分に綺麗だから、（コメントは追加してもいいけど）リファクタリングする必要はない」" 一生リファクタリングしている自分とは仲良くなってくれなさそう。

業務で使えるかもしれない…！？GitHub Actions の Tips 集 / CI/CD Test Night #7

最強の本一式 揃えたぞー!! アフィリンクとかないので純粋に揃えたことをアピールしたい。書評することになる本の予告です。他にもおすすめがあればリコメンド待ってます! 結構それぞれ高いので、学生なら大学の図書館に取り寄せてもらうか、社会人なら気前よく購入!!という感じでいいんじゃないかと思います Designing Data-Intensive Applications 分散システムといえば!!!!この本一択!!! 一応日本語もある。一般的なエンジニアにもおすすめされている本 イノシシ本と呼ばれている https://www.amazon.co.jp/-/en/Martin-Kleppmann/dp/1449373321 Transaction Processing Concepts and Techniques トランザクション技術といえば...この本!! といっても当初は辞書みたいに使う

この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD

はじめまして！LayerXのカレー担当のN_Taisho（西井）です。 私は、もともと霞ヶ関の役人として、６年ほど地方財政支援、大規模災害の被災地の復旧・復興支援、国際協定交渉等に関わってきました。現在はLayerXに所属しながら、三井物産デジタル・アセットマネジメント株式会社（以下、MDM）にてProduct Managerとしてプロダクト開発に主に携わりつつ、会社立ち上げに係る様々な業務に従事させてもらっています。 このMDMは、「眠れる「銭」を、Activateせよ。」をミッションに、「Operation × Techでどうアセマネ業務をリデザインするか」に取り組んでおりますが、その概要については以前、同じくLayerXに所属しながらMDMにコミットしている丸野が執筆した以下の記事が詳しいところなのでそちらをご一読いただければと思います。 tech.layerx.co.jp 今回は、

株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。2回目は、「Enabling Team」の役割について。前回はこちら。 サービスの完全なオーナーシップを持っているのはすごく大事 名村卓氏（以下、名村）：それをする（認知負荷を下げる）ために何をするかというと、Cognitive Load、認知負荷は見ている領域が広がると結果的にキャパシティを超えちゃうので、そもそも絶対量を減らす必要があります。ドメインフォーカスをするんだけど、そのドメインが大きすぎるとそれだけでキャパシティがオーバーフローするので、サービスのサイズやチームが見るべき領域をできるだけ最小化して

TOPコラムキャリアを創る思考法伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」（技術評論社）などがある。 前回では、筆者がプログラマとして入社したSIer時代のエピソードと、そのあとに入社した外資系企業での社内プログラマとしてのエピソードを書いてみました。IT業界に入って間もないエンジニアさんや、これからの自分のキャリアを考え始めたエンジニアさんに

こんにちは！ 株式会社ココナラのプロダクト開発部 QA チーム所属のまると申します。 弊社では現在リリース時のリグレッションテストの大部分を手動かつモンキーテストで実施しています。そのためテスト工数が高く、さらにテスト漏れも発生し、予期せぬ機能で障害が発生してしまうことがありました。 この状況を鑑み、QA チームではテスト効率化とプロダクト品質の更なる向上を目指し、今期からWeb の E2E テスト自動化を再整備しています。 本記事で自動化ツールの評価を行い、Playwrightを選定するまでのプロセスを記載します。 前提 テスト自動化ツールAutifyを利用して、定性的に重要と判断された一部機能を対象にリグレッションテストを自動化している 現状の課題 ツール制約上、対応できない機能が発生している 現状の自動化率は 50%未満 全テストケースを実行するとテスト実行完了までに半日要する 画面

誰でもというか、自分のために書いてます。 Stable Diffusionとは Diffusionモデル：　Stable Diffusionの心臓部 Text Encoder：　指定された言葉を理解し、絵のデザインを決める 言葉を理解する 言葉から絵のデザインを決める Latent Space：データを圧縮して処理 事前学習：　Stable Diffusionを鍛えるしくみ 絵に乗っているノイズを予測するための学習 言葉と画像を結びつけるための学習 まとめ Stable Diffusionとは Stable Diffusion(ステーブル　ディフュージョン)とは、指示した通りに絵を描いてくれる、いわゆる「人工知能絵描き」です。 これ以前もそれっぽいものはいくつかありましたが、Stable Diffusionの登場で世界が一変しました。 Stable Diffusionの特徴は以下の２つです

「最適化法」第15回(ゲストトーク), 2023年1月20日, 同志社大学.

【書き起こし】メルペイチームが考える「ゼロトラスト」をベースとした認証・認可の在り方と課題 #merpay_techtalk 2021年11月5日に、メルペイ・メルコインのエンジニアたちによる「Tech Talk 〜 ゼロトラストをベースとした安定的なシステム稼働の取り組み〜」を開催しました。 現在のメルペイサービスにおける認証・認可の仕組みや、セキュリティ対策に欠かせない「ゼロトラスト」と認証・認可の関係、それらを踏まえたメルカリグループの現状と課題をご紹介します アーカイブはこちら！ https://www.youtube.com/watch?v=gXxd75iBXzE 登壇者紹介 竹井 悠人（@yuto）/ 株式会社メルコイン　Securityチーム Manager スタートアップを渡り歩いてきたソフトウェア エンジニア。2016年に暗号資産交換業者 (取引所) に入社して以後、最高

Rust.Tokyo 2023カンファレンスの発表スライドです。 The slides for my talk at Rust.Tokyo 2023 conference. Written in English and Japanese.

2023/07/01 開催 スクラムフェス大阪 | Scrum Fest Osaka 2023 での発表資料です。