【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。 これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。 こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。 “見積り” と “計画” は別物見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。 工数が明らかになれば計画なのか？それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、とい
www.youtube.com 昨夜未明、インターネット某所で、プログラミング支援ツール「Cline」と、それを用いたゲーム開発の経験談*1を語り合う会合がありました。 CLINEが持つ、人間の介入を最小限に抑えながら暴走機関車ようにコードを生成する性質を軸に、CopilotやCursorなど既存のAIコーディングツールとの比較や、これまでのコーディングツールのアプローチからの変化、今後の開発における展望も議論されていました。 Clineの性質 ホストの@mizchiさんはClineを「強いパーミッション持って自動で実行されるのでイテレーションの回数が多い」「AIにコーディングのアシスタントではなく主導権を持たせても何とかなるということを気づかせてしまった」と評価していました。Cursorなどと比較してその自律性（相談せず勝手にやっちゃう）に強く惹かれているそうです。 確かに全部読み込ませ
こんにちは、株式会社Berryの浅沼です。 この記事を書いている数週間前くらいから話題のClineを会社で導入し、開発に利用しています。最初はコードの自動生成から試していたのですが、.clinerulesを使ってプロジェクトごとのカスタム設定ができることを知り、どんどん活用の幅を広げていきました。 特に大きかったのが、プロジェクト内のコード構造・コーディングルールの設定に加えて、コミットメッセージやプルリクエストのタイトル・サマリーを生成するルールを追加したことです。これによって、「コードを書く→コミットメッセージを考える→プルリクを書く」という一連の作業がスムーズになり、全体の開発効率が格段に上がりました。 この記事では、実際の.clinerulesの内容も含めて、どのようにルールを作り、育て、活用しているのかを紹介します。特に、コードの自動生成以外の使い方にも触れますので、すでにCli
ここ最近は開発が佳境で、同僚とかなりの頻度でペアプロ（ペアプログラミング）（ここではペアオペも含む）している。主にTypeScriptを使ったNext.jsのコードを書いているが、もちろん設計もするし、もうちょっと大きいアーキテクチャみたいな相談もする。DBスキーマをどう割るか・・・みたいな話もしている。たいていみんな出社していないので、リモートでこれをやっている（国内だし全員日本語話者なので時差とかはない）。 いちおうどの面子もペアプロの心得はあったのだが、当初は微妙にギクシャクしたり、疲れきったりしていた。そんな中、同僚がRGST2025に行ったりする中でうまくいくようになってきたので共有する。 以前はペアプロやる？と聞かれるとウゲ〜面倒だな、とっとと終わらないかな、と思っていたのだが、今は完全にお気に入りの道具箱に入っていて、飛び出す機会を伺っている。 また、他にもオススメの知見があ
調査をサクサク進めるために。伊藤淳一が考える「良いプルリクエスト、悪いプルリクエスト」 2025年1月14日 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」（技術評論社）などがある。 keyboard_arrow_down はじめに keyboard_arrow_down TL;DR （最初にまとめ） keyboard_arrow_down なるべく小さいプルリクエストにすること keyboard_arrow_down プルリクエストのタイトルを具体的か
「サッと助けてくれるエンジニア」は、試行錯誤の質が高い。 nrs氏に聞く「経験の積み方」 2025年1月14日 GMOインターネットグループ デベロッパーエキスパート 成瀬 允宣 2017年9月GMOインターネットグループ株式会社入社。テックリードとしてWebアプリケーションプロダクト開発に従事するほか、社内研修や小学校プログラミング教育に携わる。また技術広報としてカンファレンス等でソフトウェア開発・設計を主軸に講演活動を行う。著書『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』（翔泳社）。 エラーやバグ、パフォーマンス不良などの不具合が発生したときに、最後に必ず解決してくれるエース的な存在のエンジニアに助けられた経験のある人は多いのではないでしょうか。 GMOインターネットグループのnrsさんは、まさにそんなエースの一人。今では、大抵の不具合では早急に原因を特定し、
📒ペアプロ・モブプロアンケート実施中 🖊️ あなたのご意見をお聞かせください。(2025/1/3 23:59まで） 回答結果は2025/1/6(月)にQiitaで公開いたします。 アンケートはこちらから（1分ほどで終わります） はじめに 巷ではペアプロ、モブプロがホットワードになっており、あたかも開発生産性を向上する特効薬のように取り上げられている印象を受けます。一方、この記事では、ペアプロ、モブプロ開発のネガティブな部分を考え、私の経験から感じたペアプロ、モブプロのアンチパターンとその改善策をご紹介します。 どんなアンチパターンを踏んでいたのか？ 勤務時間は100%ペアプロを実施（ソロプロ禁止） ソロプロは悪、ペアプロが最高というチームの雰囲気 フロー効率を過度に重視する姿勢 どうなったか？ ＋) 開発生産性およびデプロイ頻度は上がった ＋) 4keysなどの数値上の指標はすべてプラ
Tebiki株式会社 取締役CTO 渋谷 和暁 神戸大学法学部卒業後、SIerを経てWebシステムの開発会社に入社。ECなどの受託開発やゲームアプリ開発のリードとして従事した後、コーチ・ユナイテッドに転職。クックパッドによる吸収合併のタイミングでCEO貴山氏とともにTebiki社を起業し、取締役CTOを務める。 GitHub Medium アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。 かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社
こんな経験はありませんか？ 「開発メンバーになんでこれ優先度高い/低いんですか？」と聞かれるとき 「考えていた新機能以外にビジネスサイドからの要求が尽きない。ユーザー要望は待ったなしで、技術的な課題も放置できない……。どれから手をつければいい？」と思うとき はじめまして。株式会社GaudiyでPdMをしている三島(@kaa_a_zu)です。今は漫画やゲームのIPごとにファンコミュニティを作ることが出来るFanlinkというサービスを作っています。 実際、私も優先順位で悩んだことが何度もあります。多くの要求やアイデアに囲まれたとき、どれを先に取り組むべきか判断するのは簡単ではありません。 今回の記事ではこの課題を打破する一つの手段として、今回はICEスコアをベースにした優先順位づけの方法を紹介したいと思います。 スコアリングによる初期整理、そしてスコア化だけでは拾いきれない部分を対話や情報共
以下の公開計測会でやったものを個別に解説してみる。 細かいテクニックが多いのだが、それを可能な限りテキストとスクショで解説したい。使い方の解説が中心で、どういう意味があるかは解説しない。 Chrome131時点のスクリーンショットで、後で読む場合は頻繁にUIが変わっている点に注意。大事なのは意図。 宣伝: これを御社のサイトで解説する仕事をやっています。 デモのURL これに意味はなく、今日偶然見ていただけで意図はない。関係ないがエッジランナーズは最高のアニメ。 DevTools を開く F12 or 右クリックから「検証」 DevTools > Lighthouse この状態で計測 このとき、新しいプロファイルを作ったりして、可能な限り Chrome拡張が入ってない状態にすること。Chrome拡張による処理も計測に含まれてしまう。 Lighthouse レポートの読み方 点数部分にマウス
こんにちは。プロダクト本部プラットフォーム部SREチームのid:ut61zです。 サービスを運用していくうえで監視は避けて通れません。 Classiでは長らく朝当番という制度を設け、平日朝のピークタイムにエンジニアを監視担当としてアサインし、何らかの問題が発生した際、即座に対応できる体制を整えてきました。 2020年9月からスタートした朝当番制度ですが、2024年4月をもってこの制度を終了しました。 今回はその経緯や理由、現在のClassiの運用体制などをご紹介します。 朝当番とは あらためて朝当番制度とは、平日朝のピークタイムにエンジニアが常に1名待機し監視する制度になります。担当エンジニアは各種メトリクスに異常がないかチェックし、問題や気になったことがあれば関係各所に情報連携を行う役割を担います。 朝当番制度の目的、背景、期待される効果など、以下のブログに詳細が記載されていますので興味
次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード／悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。（以前の書籍についてのコメント記事へのリンク） ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
物流大手の日本通運が「新・国際航空貨物基幹システム」の開発失敗を巡り、ベンダーのアクセンチュアを訴えた裁判。名門企業同士の訴訟、さらには約124億9100万円という賠償請求額の大きさは衝撃的だった。 裁判資料を読んでいると胃がキリキリした。筆者は2年ほど前までシステムエンジニアとして働いていた。その分、記されていた当事者の発言やチャットが、あまりにも生々しく映った。 訴状によると、開発プロジェクトはテスト工程から遅延し始めた。当初2020年12月の予定だった結合テストの後半過程「ITb」の終了は2021年11月にずれ込んだ。アクセンチュアがITbの「成果物」を共有サーバーにアップロードしたのは2021年11月30日。しかし、日本通運は先立って実施していた「打鍵テスト」で大量の指摘事項が挙がっていたことなどから、この品質を問題視した。以降、これら成果物の検収を巡り、両者の主張は至るところで対
社内で書いた内容から、一般化できる話だけを抜き出して書いた記事です。 TL;DR 意思決定者は、 仕様が複雑になればなるだけ、指数関数的かつ継続的にコストがかかることを理解する必要がある。 ユーザーの要求や利便性について優先順位をつける必要がある。 それらを揃えた上で「いっちゃんいいバランスで顧客要望に応える」必要がある。 コストについて サービスあるいは機能の一生 サービスあるいは機能は以下のライフサイクルを辿る 初回リリース以前 初回リリース以後、クローズ以前 クローズ 実は一番コストがかかるのが「初回リリース以後、クローズ以前」の部分。なぜならサービスの一生のうちほとんどの時期がここなので……。 初回リリース以前にかかるコスト いわゆる「初期開発」が行われる。 当然、この時に仕様がシンプルであればあるだけ初期開発にかかるコストは低くなるし、仕様が複雑であればあるだけ初期開発にかかるコ
はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義関連の記事の投稿をしました。時間あればぜひ読んでみてください。 今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。 非機能要件｜6項目について 1. 可用性 システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
