はじめに 近年、様々な分野で機械学習の利用が進む中、モデルの品質を担保し、継続的な学習を行うための施策が重要視されています。そのため、機械学習のためのDevOpsであるMLOpsの必要性が高まっており、AI事業本部でも研修内容に取り入れています。 より良いMLOpsを構築するためには、アプリケーションやインフラの知識も必要です。そのため、今年は昨年までと異なり、MLエンジニアだけでなくソフトウェアエンジニアも講義に参加しました。また、新たに実践編が加わり、より業務を意識した講義が追加されました。 Container編 基礎編 応用編 実践編 そこで、今回は研修で行われた各講義の資料を公開したいと思います。 Container編 Container編では、コンテナにまつわる技術に対しインデックスを張ることと、イメージ作成や運用時のTipsを学び実業務に役立てることを目的としています。 そのた

CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

自分が会社員だった時の転職活動、必ずしも毎回全部できていたわけではないけど、一応こういうステップを意識していたなぁ、というノウハウのシェア。 ①1度に1社だけを受ける。エージェントではなくリファラルで紹介者を見つける。2社以上を同時に受けるのはちょっと大変かなと考えていた。 ②紹介者に社内の課題を聞いて、イシュー度（本当に解く価値があるか？）やCan（自分のスキルや経歴に合う領域か？）とのマッチングを確認する。 ③カジュアル面談やリファラル食事会で社内課題やカルチャーをヒアリングする。なるべく違う立場のメンバーに来てもらって、見え方や意見のズレを探り、正確な状況を把握する。必要に応じて事前にNDAを締結する。 ④外部事例をリサーチしてその会社にマッチする解決案を考え、提案資料にまとめて送る。入社後に期待される動きの1つを先に実施し、③の参加者が投下した時間コストはこの成果物でお返しとする。

この資料の目的 この記事では Terraform で、TypeScript を利用した AWS Lambda を管理する方法を記載しています。 個人的な好みで言えば Lambda を IaC で扱う場合、AWS の提供してくれる CI/CD の機能・サービスに乗りやすい CDK の方が好みです。しかし、チームによっては terraform が望ましい場合もあります。 今回、Terraform で AWS Lambda のリソースを作成したので、後々忘れないように自分のための備忘録として残します。 前提情報 言葉の定義 数々存在しているインフラリソースを任意のまとまりを、この記事では「Stack」と呼ばせていただきます。 Lambda の目的・役割 今回作成する Lambda は S3 Bucket にファイルがアップロードされたとき、それを event として SQS に message

ChatGPTが登場した当初、対話や要約、翻訳、コード生成などの典型的な言語タスクができても、SREやAIOpsの研究開発にはあまり関係ないのではないかと正直思っていた。AIOpsでは典型的にはいわゆるObservabilityデータ（メトリクス、ログ、トレースなど）が入力となるため、自然言語ではなく数値のデータを解析することが求められる。自然言語のタスクを研究対象としていなかったため、AIOpsとChatGPTに強い関係性は見いだせなかった*1。 しかし、自分で大規模言語モデル（Large Language Model: LLM）を日常的に使用したり、表題にあるようにSREのためのLLM（LLM for SRE, LLM4SRE）に関する論文を読むうちに、LLMのテキスト生成器としての性質よりもその優れた推論機械としての性質に注目するようになった。特にSREの障害診断は、人間の専門家が推

※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ

走り出す花びら 甘井最鹿 迷いと緊張を抱えて単身やってきた海の向こう、日本。何もかもが手探りのこの場所で、「新しい私」なんて、本当にみつかるんだろうかーーー？

はじめに 「ChatGPT/LangChainによるチャットシステム構築」 という本が素晴らしかったので、ちゃんと身につけるために Python だけじゃなくて Node.js でも動かしてみました。同じことをやろうとした人のために、ここにそのときの記録を残します。特に callbacksやmemoryについて、詳細に記載しようと思います。 書籍の説明につながるようなことはできる限り書きません！めっちゃ良書なので、ご興味持っていただけた方は購入してもらえますと 🙏 5章まではPython固有のToolを利用しており、6章の中身は7章とかなり近いところがあるので、7章のプログラムだけここに記載します。LangChainの学習に注力したいので、Serverelss Frameworkに関連するコードは省略しました。また、Momentoや @slack/bolt に関する説明はしません。 プロ

ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標（登録番号 第6091713号）です。 詳しくは［ABJマーク］または［電子出版制作・流通協議会］で検索してください。

はじめに この投稿はポエムです。 技術的な記事を期待してる人はブラウザバックお願いします！ なおこの文書は諸々の理由により、一部ぼかしたところがありますがご容赦ください。 TL;DR 有名になった方法論は、目的が忘れられて、手段だけ広がることがある 手段が「守らねばならぬルール」になって目的を達成できないことがよくある 何か手法を取り入れるときは手段が目的化してないか気をつけねば 本文 先日、勉強会にて、とあるベンチャー企業の営業職の方とちょっと話す機会がありました。 その方は最近営業チームのマネージャーになられたとのことで、組織設計のお話をされまして「The Model的に営業のプロセスを細かく分割し、分業を進めて、KPIで成果を追えるようにした。現在は分業のメリットを感じている」 「The Model は The Goal を参考にしているとのことなので、ソフトウェアエンジニアの人も使

背景 ２年間くらい PO & Scrum Master とソフトウェアエンジニアを兼務したり色々あった この度、ソフトウェアエンジニアに集中できることになった せっかくなので、忘れる前に ( もうたくさん忘れたけど ) 書き出すことにした この記事は、未来の自分が思い出すための記事である 全般 絶対に兼務しない これだけ兼務まつりしてて言うのもあれだが POに集中する期間は、SMとエンジニアとしての貯金が減ってるのを感じ エンジニアに集中する期間は、POやエンジニアとしての貯金が減ってるのを実感する 兼務状態は、常に何かしらの貯金が減る不安を抱えながら仕事することになる スーパーマンでない限り、１つ１つのクオリティが落ちてしまい、よしんばなんとかなっても「なんとか破綻しない」程度になる うまくいったとしても９割のケースは、誰かが荷物を持ってくれたから なので 成功ケースだけを見て「兼務いけ

TL;DR 払うべき説明・説得コストと、払うべきでない説明・説得コストが存在する 払うべき説明・説得コストとは、その行為によって期待する成果 (積極的に) 払うべきでない、もしくは説明の方向性を逆転すべき説明・説得コストは、下記の通りだと考えている 説明される側の、本来職種として持つべき知識の明らかな不足によるもの 説明される側の、間違った先入観に基づく一方的な心理的抵抗によるもの マネージャーとして、メンバーから説明を受けるときは下記項目を注意する 今受けている説明コストは、本来メンバーが支払うべきものか メンバーが支払うべきである場合 何故にメンバーが支払うべきで、その説明を受け自分はどのようなアクションをするか、そのためにどこまでの品質を求めるのか 上記項目が確実にメンバーに伝わっているか マネージャーとして、払うべきでない説明・説得コストを支払っているシーンを見たら下記の対策を検討

この資料の目的 自分のキャリアを振り返ってみると、PdMとソフトウェアエンジニア業を兼務することが多くありました。PdMとして業務していくなかで、エンジニアへのお願いの仕方を間違えて、想定よりも多く時間が掛かってしまうこともありました。その問題は、特に新しい技術を使って課題を解決しようとするときによくありました。 この記事では、新しい技術を試す際、現場で良くみるムダな仕事が発生しちゃってるケースを例に、そうならないよう自分が意識しているお願いの仕方を言語化してみようと思います。 よく見る良くない依頼の仕方 ケース１ PdM: 最近、XX という技術をよく聞くんだけどさ、あれでうちのサービスも良く出来ない？ エンジニア: うーん、とりあえず検証してみるんで、何ができたら嬉しいか教えてください PdM: 何ができるか分からないからなー。とりあえず試してみてよ。良さそうだったらどう使うか考えるか

モチベーション 私は「インフラ」という言葉は、人によって受け取り方が大き違う言葉だと思ってます。 「よく分からないけど難しそうなので出来れば触りたくない」という人や、「ごく小数の人にしか触らせたくない」という人、 「IaaS、PaaSはインフラと認めない！」という人にも会ったことがあります。 「よく分からないなんとなく難しいもの」である「インフラ」は、多くの人に敬遠されがちなので、 中小規模の開発組織では１人のエンジニアがひっそりと孤独に作ってるケースがままあるのではないでしょうか。 私もやりたがる人があまりいないので、PMとインフラエンジニアを兼務することが多くありました。 この記事では、一人でひっそりとインフラを作ってた私が、触れる人を増やしたいと思って工夫したIaC設計のアイデアを記述しようと思います。 言葉の定義 インフラ IaCで扱う「インフラ」の定義について。 言葉の定義を探し

※この記事は、Speee Advent Calendar22日目の記事です。 昨日の記事はこちら tech.speee.jp 2021年7月から業務委託のエンジニアとして主にイエウールの開発のお手伝いしている高尾です。所属は株式会社ネットワーク応用通信研究所。Rubyのまつもとゆきひろさんも在籍されており、Rubyに関するSIでそれなりの実績のある会社です。私は20年近くSIerとして仕事をしてきました。 そんな私にとってもSpeeeでの開発は魅力的です。 プロジェクトの運営、プロダクトの仕様、技術の採用、リリースなど、多くのことをエンジニアが主体的に決めます。各エンジニアがお客様の価値を理解してプロダクトを作り上げるという意識が伝わってきます。そんなエンジニアのみなさんが、 Rubyをつかって楽しくプログラミングできるように全力でサポートしていきたいと思います！ 前置きが長くなってしまい

前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

デジタルトランスフォーメーション（DX）事業本部でPMをしています、九島です。 新卒でSpeeeに入社してから、約5年間グロースに取り組んでいて、中でもLPのABテストを継続してやってきました。この記事では、ABテスト初心者の方に向けて、自分の失敗や試行錯誤の過程をお伝えしながら、今一番上手くいっている「ABテストの型」を紹介します。 「サイトのABテストを任されたけど、どう考えたらいいの？」「ちょっとやってみたけど、もっと成果出すにはどうしたらいい？」 とお考えのEFO担当者の方にとって、一助になれば幸いです。 ABテストとは？ 1年目：200施策やってCVR上がらない 2~3年目：ユーザーニーズを掴むことが糸口に 4~5年目：行き着いたのは「ユーザー中心設計」のABテスト ①ユーザーニーズを定義し、コアの提供価値を決める ②「何をやるか」ではなく「どういう仮説を検証するか」にこだわって

国をあげてDXが推進され、さまざまな業界でテクノロジーが活用され始めています。 各企業がDXに取り組む中で、2021年6月7日（月）に経済産業省から発表された「DX注目企業」として、重厚長大企業である三菱重工業株式会社が選出されました。 そこでFindyでは「日本のデジタル化最前線 Vol.4」と題し、三菱重工業株式会社のDXを推進する組織・DEDのゼネラルマネージャーである川口さんと、Findy経由で同社に入社された廣政さん、森岡さん、山田さんの計4名をお招きし、同社が取り組んでいる開発内製化、DXの実態、業務の面白さについてお伺いしました。 本稿ではパネルディスカッションの様子をお届けします！ パネリスト 川口 賢太郎さん 三菱重工業株式会社 成長推進室　デジタルエクスペリエンス推進室　室長 大学・大学院で建築デザインを専攻、三菱重工業入社後は建築デザイナーとしてさいたまスーパーアリー

早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職。17年6月より独立し、プロダクト戦略やエンジニアリングマネジメントなどの領域で企業の支援を行う。17年9月、ヘッドハンティング・人材紹介を展開するクライス＆カンパニーの顧問に就任。2019年1月、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立。「プロダクトマネージャーのキャリア戦略」 及川卓也のプロダクト視点 アマゾン、アップルといった米国企業や中国企業からの遅れが目立ち始めた日本企業。かつ