窮屈で仕方ない。決められたものを、決められた日までに作るだけ——プロジェクトの成功とは、そういうものなのか。 そんな疑問が頭をもたげるスクラムチームは、自らを “もどき” だと感じるようになります。スクラムで開発しているはずが、気づけば違うものに変わってしまっていた、と。 はじめから “何を作るか” にばかり集中すると、そうなります。そして、チームは次の四段階を経て、静かに侵食されていきます。 はじめから全体を詳細に詰める 決定を開発へ一方通行で流す すべてのパーツを作ってから組み上げる スプリントレビューを進捗報告の場にする 1. はじめから全体を詳細に詰める“何を作るか” が、プロジェクトのはじめに、たっぷり時間をかけて書き出されます。それは、詳細で網羅的。思いの丈をすべて注ぎ込んだかのような、少々壮大で立派すぎる仕様ができあがります。 “なぜ作るか” に、一分の隙もない “正しい答え
AI 始めました！というと、ミーハーな感じがありますが、15年ほどやってきたソフトウェアエンジニアとしてのキャリアは終わりにして、 2カ月程前から AI エンジニアになりました。ここ5年程は、過去の経験の切り売りしかしていない感じがずっとあったのですが、 全く新しいことを始めて1から勉強し直しているところでとても楽しいです。 Fifteen Years of Dev, Deleted — Hello AI 目次 AI エンジニアって何？ 今までのAI/機械学習と違うところ 自律的なエージェントの構成要素 自律的なエージェントが人間を拡張した先 未来への不安 ブラックボックスを超えて 自然言語が主役になる時代のソフトウェア開発 やりたいこと AI エンジニアって何？ 雑に言えば、この表現が言いえて妙だと思います: 「LLM インテグレーション屋さん」 LLM インテグレーション屋さんになるこ
ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労することに、そもそも違和感を持てないのだ。 日常化した苦労は、改善されることがない。違和感がないからこそ、問題として扱われない。そして、原因に目が向けられることもなく、風景に溶け込んだまま、空気のようにあり続ける。 つまり、苦労を軽減するには、日常風景の中から問題を見つけ出す必要がある。そのための第一歩が、「気づく」ことだ。問題というのは、気づかなければ解決のしようがない。学校の試験のように、誰かに出題されるものではないのだから。 本記事では、「気づく」ための視点を言語化し、手がかりとして整理している。 ソフトウェアエンジニアリング業務でありがちな苦労を、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 まずは、このご時世に新規のアプリ開発を出来るというチャンスに感謝しましょう。 もちろんすでにあるアプリの追加開発や運用で得られる経験値はとても素晴らしいですが、同じように新規開発も胸踊るものがあります。 あなたのRoleがDeveloperなのか、あるいはProject Managerなのか、Product Managerなのかで主に考慮すべき点は変わってきますが、それはそれとしてすべての点を理解して、抜け漏れがあったら指摘あるいは巻き取る覚悟を持っておきましょう。 ラストマンシップは良い資質です。具体的にはラストマンシップがある
www.youtube.com 昨夜未明、インターネット某所で、プログラミング支援ツール「Cline」と、それを用いたゲーム開発の経験談*1を語り合う会合がありました。 CLINEが持つ、人間の介入を最小限に抑えながら暴走機関車ようにコードを生成する性質を軸に、CopilotやCursorなど既存のAIコーディングツールとの比較や、これまでのコーディングツールのアプローチからの変化、今後の開発における展望も議論されていました。 Clineの性質 ホストの@mizchiさんはClineを「強いパーミッション持って自動で実行されるのでイテレーションの回数が多い」「AIにコーディングのアシスタントではなく主導権を持たせても何とかなるということを気づかせてしまった」と評価していました。Cursorなどと比較してその自律性（相談せず勝手にやっちゃう）に強く惹かれているそうです。 確かに全部読み込ませ
概要プロジェクト利用する依存ライブラリのメンテナンスを放置すると、セキュリティ、パフォーマンスの問題もさることながら、ライブラリの数もどんどん増え続けます。これを放置すると生産性の低下にも繋がります。この問題に対処するべく開発したCLIツールstay_or_goの紹介とそれを利用したソリューションの提案をします。 目的プロジェクトで利用している依存ライブラリのスコアリングして、依存ライブラリの棚卸しをすることで、フレームワークやプログラミング言語のアップグレードを迅速に行えるようにしたり、生産性の向上を図ります。 対象読者CTOやSRE、リードエンジニアなどを技術的負債の解消についてプロダクトオーナーや決裁権のある人に説明責任がある人対象とします。 PRUZUMAKIではアジャイル開発で新規事業の開発から、大規模Webアプリケーションのアーキテクチャ更新などの開発をしています。 お問い合わ
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
筆者自己紹介と本記事概要はじめまして、持辺高志ともうします。 本記事は、業界完全未経験だった自分がふとしたきっかけでゲームを作り始め。大体1年半～くらいの期間でSteamで有料販売をするまでに経験したことやノウハウを赤裸々にまとめたモノになります。 プログラミングはおろか、絵もかけず曲も作れない、シナリオも書けない私でもゲームを作って人からお金を貰えた。という事実が、少しでもこれからゲーム製作を始める人や、販売したいと思ってる人の栄養になればいいなと思っています。 別に自慢や自作品の宣伝をしたいわけではなく、その辺は省いていくので 適当な暇つぶしのための読み物として読んで頂ければ幸いです。 実績としては、1年半～2年弱でフリーゲームや有料販売含めた4タイトルをリリースし 累計ダウンロード数は2万前後となります(普通に弱小です)。 書いていく内容は、よくある啓発のような内容のものではなく ゲ
Cloud Operator Days 2024 クロージングイベントでの発表資料です。 PFN では PLaMo という生成AI基盤モデルを開発しており、100B規模のモデルを運用する際の課題について話しました。
リソース不足によるデスマーチは珍しくもありませんが、そうしたプロジェクトが真に崩壊する時は目標の達成の見込みが無くなった時です。 具体例として名前を出して申し訳ありませんが、過去の特許庁や京都市のシステム更改案件などが典型です。 デスマーチに陥ったプロジェクトにおいて、出来ることと出来ない事を整理し、優先順位をつけて対応するのは重要な事です。しかし、その結果目標達成の見込みや効果が見いだせなくなった時、モラルハザードに陥りプロジェクトは急速に崩壊に向かいます。 その意味で、全国のシステム標準化プロジェクトは今極めて危うい状況です。 "全国のシステム標準化事務に従事する自治体職員に伝えたい事"にも書きましたが、システム標準化の表向きの目標は標準化基準への適合ですが、真の目的は国の重点計画にあるトータルデザインの実現です。 言い換えれば、今多大な労力をかけてこのシステム標準化を遂行し、標準化基
最近、システム開発はこうあるべきだよなって考えていたのと、他所のエンジニアリング文化についての記事を見たことから、自分にとっての今の理想と現実の間について整理して吐き出しておきたくなりました。 所詮理想ではあるものの、自身の環境におけるベストに近づけようとする思考や、ベストに程遠い状況を認識する、ということには意味があるのではないかと思う次第です。 はじめに 自分は100％WEB系出身ですが、全く異なる文化である SIer 方面のお話を読むのはわりと好きで、これらは興味深く読ませてもらいました。 誰も教えてくれないSIの本質、SIerの世界観 日本のSIerの技術力の低さの要因から考えるアメリカソフトウェアの強さ – きしだのHatena プログラミングが設計作業であるという話 – きしだのHatena ソフトウェアの「詳細設計書」とはなんなのか – きしだのHatena だいたい SIe
「ソフトウェアを職人技からエンジニアリングへ」と題した講演を、ウーブン・バイ・トヨタのジェイエフ・バスティエン氏がAUTOSARオープンカンファレンス（2024年6月11～12日）で行った。同氏はトヨタ自動車のB＆D改革部 商品・製品開発にも所属し、プログラミング言語であるC++の標準化を担うISO/SC22/WG21の進化作業グループの議長なども務めている。 ソフトウェア開発の歴史を1960年代までさかのぼりながら、SDV（ソフトウェアデファインドビークル）の時代に向けてソフトウェアエンジニアが持つべき目線について語った。 ビルや橋は大丈夫なのにソフトウェアは…… 勤務先が入居するオフィスビルや日々通過する橋に不具合が発生することは、めったにない。それは建築や土木がエンジニアリングとして確立されているおかげだといえる。しかし、身の回りだけを見ても、ソフトウェアが使われている製品からバグが
「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 追記(2024/11/27)：「概略図」「物理設備の設計」を追記 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできます
いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト
人間が何もしないと病気になるのと同じように、ソフトウェアも何もしないと複雑になる。 はじめに ソフトウェア開発の世界に飛び込んでから、「ソフトウェアは認知の限界まで複雑になる」という言葉を耳にしたとき、正直なところ、「ほへー」って思いながら何も理解していませんでした。しかし、大規模なシステムに携わるようになって、その言葉の重みを身をもって感じるようになりました。内部構造や相互作用が複雑化し、全体を把握するのが難しくなっていく。それは挑戦であると同時に、私たち開発者の存在意義を問いかけるものでもあります。 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon この複雑性との闘いは、時に苦しいものです。でも、それを乗り越えたときの喜びは何物にも代えがたい。私たちの
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
A guide to scaling product & engineering teams from $0 to past $100M ARR. © 2025. Stay SaaSy. As a product manager, it’s important to hone the minimum set of activities that allow you to keep a product line moving forward productively. One of the most important core product management skills: the ability to triage unsuccessful products and avoid spending unnecessary effort on products that are des
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
