AIエージェントを支える設計2025-07-25 設計ナイト2025の登壇資料です。
設計レビューってどうやるの？ - めるノート
はじめに 「設計レビューって、結局どうやるのが“正解”なんだろう？」 設計って、会社のフェーズによっても全然異なるものだと思います。今まで所属していた会社は人数の少ないところが多かったので、かっちり設計せずに即実装とか、それぞれ我流でアーキテクチャ図やDesign Docが作られて特にレビューなどせずに実装していくような感じでした。 ここ最近で設計レビューに参加するようになって、自分がDesign Docを作成するのはもちろん、他のメンバーのDesign Docを見て考えをインプットすることでもめちゃめちゃ設計スキルをつけられるな、と思うようになりました。 そんな中、自分のチームではDesign Docを書いて1回だけレビュー会を開く、という運用が続いていました。でもそれでは、設計を担当していないメンバーに膨大な内容が頭に入らず、レビューの時間も足りなかったりして、上手くいかない状況が続い
なぜスプリントレトロスペクティブでKPTをお勧めしないのか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません
なぜ、安易に「スクラムで開発します」と言わなかったのか？ - 結果整合的アジャイルを目指す開発 - カミナシ エンジニアブログ
プレイングマネージャー型のEMをしています、鈴木（@szk3）です。 今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。 このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。 新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「
これからSREになる人と、これからもSREをやっていく人へ
Road to SRE NEXT@京都 の登壇資料 https://sre-lounge.connpass.com/event/339458/ 株式会社はてなで、SREの立ち上げから5年以上が経過しました。その中で実践してきたことや経験をもとに、SREというキャリアや必要なスキルについて私の考え…
網羅的なPRDやDesign Docを書かなくなった - kosui
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
スタートアップ→上場企業の取締役を務めたとあるエンジニアの13年間の学び - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、クラウドワークス Advent Calendar 2024 シリーズ4の23日目の記事です。 こんにちは、のむらです。 2024年12月20日をもって、長らく務めさせていただきました取締役を退任しました。せっかくなのでこの13年をふりかえり、自分が得た学びを少しでも世の中に還元すべく、したためてみます。 まずはふりかえり 創業 〜 プロダクトリリース クラウドワークスは2011年11月に創業し、2012年3月にプロダクトの初期リリースをしました。 この間の4ヶ月は、起きている時間はほぼプログラミングをしているような生活でした
エンジニアが事業で勝つための「概念整理」のスキルについてーー事業開発の現場で学んだ「技術と事業をつなぐ」思考法｜naro143
私は都内のベンチャー企業でSaaSの開発をしているエンジニアです。 最近、事業を進めるなかで感じていることがあります。それは、エンジニアとしての「優秀さ」の定義が変わってきているな、ということです。 もはや技術力では勝負がつかないかつてエンジニアの優秀さの定義は「いかに高い技術力を持つか？」が大きな割合を占めていました。 しかし、いまの日本のWeb事業において、ぶっちゃけ「技術力」が事業の決定打になることはほぼありません。 たとえば「Wantedly」のような求人掲載サービスも「クックパッド」のようなレシピ共有サービスも、機能として見たときには大きな違いがないですよね。情報が登録できて、表示されて、検索できて、いいねや検索条件の保存ができて……と、基本機能はほぼ同じように見えます（あくまで外から見た限りですが）。 私たちが開発中のSaaSも、基本機能は「データ入力、保存、表示」なので、さほ
【入門】生成AI関連を学べる資料まとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回は生成AI関連の知識を学ぶことができる資料をまとめました。 有名企業や大学が公開しているものを厳選しています。 対象者 生成AIの概要を知りたい人 ChatGPTのプロンプトテクニックを知りたい人 AIの基礎を学びたい人 AI関連 AI関連は入門的な内容を学べる資料を厳選して3つ紹介します。 本当にわかりやすいAI入門 AIの基礎的な話から、実践的な活用事例までを網羅的に学べる資料。 AIとは何か 脳の仕組み 伝わりやすさと境界の決め方 課題を乗り越えるための取り組み 文章生成の仕組み AIのこれから AI研修【MIXI
個人目標設定の手引きとシュート2万本 - Konifar's ZATSU
個人目標を考えるのは難しい。以前自分の思考整理も兼ねて、開発メンバー向けに"個人目標設定の手引き"をスライドにして共有したことがあった。 組織によって制度も解釈も違うのでそのまま適用できるものではないと思うが、もしかしたらどこかの誰かの何かの参考になるかもしれないので雑に内容を共有してみる。 ちなみに自分は 何のための個人目標設定？ - Speaker Deck に書いたとおり、目標設定自体は必要だとは思っている。「そもそも目標設定なんて不要やろ」って意見も間違っていないが、雑にいうと"組織による"としか言えないのでそこは触れずにおく。 よい個人目標とは 『意義を自分の言葉で語れて、 日々の行動が変化する目標』 『意義を自分の言葉で語れるか』 トップダウン/ボトムアップどちらでも構いません。 かなり高い目標でもちょうどよい目標でもどちらでもいいです。 「なぜそれが今必要なのか」 「やること
シニアなエンジニアの振る舞いとリーダーシップについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分はこれまでメンバーレベルのポジションとしてしか働いたことがありません。 ただ、自分と比較して必ずしも技術的に優れているわけではない同僚がインパクトの大きい仕事をしたり、上司やマネージャーの信頼を得たりしていくのを見た経験から、 自分がよりインパクトの大きい仕事をしていくためにはどのような部分が足りていないのかを考えるために、色々と調べたり、考えたり、まとめたりしてみました。 シニアなエンジニアについて ここでは、グレードの高いエンジニアや抽象度の高い仕事を日常的に行っているエンジニアをシニアなエンジニアと呼ぶことにします。 シニアな
懸念の伝え方・吸い上げ方 - Konifar's ZATSU
何かを進める時に感じている懸念をうまく伝えるのは地味にむずかしい。 あまり気にせず伝えられる人もいると思うが、自分が消極的なことばかり言って水を差してるみたいな空気になる気がして言いにくいという人もわりといるんじゃなかろうか。自分もそう考えてしまって伝え方やタイミングに悩むことがある。 しかし個々人が感じている懸念というのはめちゃくちゃ重要で、小さな違和感もちゃんと伝えてくれる方がよい。これまで誰かのちょっとした懸念から事故を防げたということは何度もあった。 "伝え方"にも一定コツはあるが、"吸い上げ方"にも工夫できることはあるので、雑にまとめておきたい。 枕詞の引き出しを増やす 伝え方の工夫として、変な空気になりにくい枕詞がある 「めちゃくちゃ心配性なこと言ってもいいですか」、「やりたくないとかではなくて、イチ意見として気になったんですけど」、「今さらなんですけど、皆で安心していい感じに
40歳になるので30代でやってよかったことをまとめた - そーだいなるらくがき帳
来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は
Graph Database と Generative AI の素敵な関係
2024/10/9に行われた OCHaCafe Season9 #1 の資料です。
YAPC::Hakodate 2024に参加して、個人技と工芸と工学について考えた - valid,invalid
YAPC::Hakodate 2024に参加してきたので感想です。人生初の函館が良かったので観光成分も多め。 YAPCについて 前回のYAPC::Hiroshimaに続いて今回が2回目のYAPC参加です。YAPC::Hiroshimaではプロポーザルが通ったのですが今回は通らずでした。 出したプロポーザルはこちら 3Dセキュア温故知新: Web認証技術の発展が切り拓いた現在地 by ohbarye | トーク | YAPC::Hakodate 2024 #yapcjapan - fortee.jp。同僚の id:yutadayo がクレカ製造技術ネタでめちゃめちゃ強いのを出して大バズしていたので会社としては問題ない...が、個人としては悔しい！ yuta.hatenablog.com 心に残った発表たちの個人的総括 ブース担当したり廊下で人と話したりでセッションは半分ぐらいしか聞けなかった
一人前のエンジニアになれたと感じたとき - 覚書
よく聞かれるのでタイトル通りのことを書こうと思ったわけですが、さて実際のところどうだったかとなると、なかなか思い出すのが難しいです。少なくとも「最初からできた」ではなかったです。そして「俺は全然駄目だ」な状態から「いける」という状態に、あるときを境にフラグが立ってそうなるというようなものでもなかったです。いくつかの出来事によって、ようやくそう思えたと感じたと記憶しています。本記事ではこれらの出来事について紹介いたします。 本記事の主な対象読者は、社会人一年生を含む経験が浅いソフトウェア技術者で、かつ、「一人前になれてないなあ」と日々悩む人々です。「一人前とは何か」という疑問もありますが、これは先輩方から逐一指導されて仕事をするジュニアエンジニアから、それなりに独立して仕事ができるようになるミドルエンジニアへの脱皮までの道と考えてもらえればいいかと思います。みなさん取り組んでいる業務は恐らく
オブザーバビリティには限りがない話
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ（僕らは単にログファイルに吐いておい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UI 開発における ヘッドレス UI ライブラリの重要性とデザインシステムへの取り入れ方
JSR の話
個人事業主型開発からの脱却
