This is a cache of https://b.hatena.ne.jp/q/%E5%93%81%E8%B3%AA. It is a snapshot of the page as it appeared on 2026-03-24T09:30:27.671+0000.
品質の人気記事 225件 - はてなブックマーク

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 225件

新着順 人気順

品質の検索結果1 - 40 件 / 225件

品質に関するエントリは225件あります。 開発仕事テスト などが関連タグです。 人気エントリには 『良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer』などがあります。
  • 良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer

    CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

      良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer
    • 「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題|深津 貴之 (fladdict)

      わりと複数の企業のお悩みが、「そもそも生成AIでやるべきでない問い」にチャレンジして疲弊してる。ので説明メモ。 大企業が生成AIを導入してうまくいかないケースの多くは、ツールの性能不足というより、業務設計がズレている印象があります。 もう少し正確に言うと、「AIが苦手な問い」をそのまま投げている。で、当然苦戦しています。 ポイントは大きく2つあります。 完璧性を要求する仕事を、やってはいけない ステップが長く連鎖する仕事も、やらせないほうがいい 順番に解説すると… そもそも完璧性を要求する仕事を、やってはいけない生成AIは確率分布で、未来を予測したり、答えを予測するマシーンです。つまり、「確率的に間違えが発生する」ことは仕様の一部です。 なので、以下のような「そもそも100%の正しさを前提とする業務は苦手」です。 正解が一意で厳密:数式の厳密計算、機械語や厳密仕様のコード生成(1文字違いで

        「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題|深津 貴之 (fladdict)
      • 日常の失敗も品質管理で解決できる - 本しゃぶり

        失敗を後悔する「恥」としてはならない。 学習する機会と捉え、次に活かせばいいのだ。 そのためのスキルが品質管理だ。 失敗から学んでダブルチェックだと ちょっと前にこのツイートが流れてきた。 失敗を成功に変える唯一の方法https://t.co/0rF2myVk5I pic.twitter.com/9o88CNqSgj— ゆうきゆう/マンガ心療内科/セクシー心理学 (@sinrinet) June 27, 2021 基本的な主張は賛成だ。失敗から学ぶのはコスパが良い。複雑で全てを理解することができない世界において、対処すべき問題を明確にしてくれるからだ。失敗には特定のパターンがあり、対策しなければ未来にも同じ失敗が発生する。だから失敗から学び対策することは、未来の成功を助けてくれる。そして最も学習効率が高いタイミングとは、記憶が新しい失敗した直後だ。 また、失敗を精神論で終わらせないのも正し

          日常の失敗も品質管理で解決できる - 本しゃぶり
        • アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛

          アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ

            アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛
          • 「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita

            再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

              「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
            • 世の中に溢れる「うざい広告」をプロが徹底解説!マーケターは必見です | 株式会社LIG(リグ)|DX支援・システム開発・Web制作

              みなさんこんにちは、LIGのマーケターのまこりーぬ(@makosaito214)です。 ネットサーフィンをしていると頻繁に出会う「うざい広告」ってありますよね。広告を制作、運用する立場としてこの手の広告がなぜ存在するのか、そして今後こういった広告はどうなっていくのかを、今回はしっかり勉強したいと思います。 今回講師としてお招きしたのは、マーケティング会社の「株式会社キーワードマーケティング」の代表である、滝井さんです。以前よりTwitterやブログを読ませていただき勉強していたので、今回は非常に楽しみです。それではご覧ください。 滝井 こんにちは。株式会社キーワードマーケティングの滝井です。本日は、まこりーぬさんに「うざい広告」についていろいろと説明したいと思います。「うざい」と思う広告を勉強することで、ユーザーに訴求する最適な広告とは何か? を考えることにつながると思いますよ。 まこりー

                世の中に溢れる「うざい広告」をプロが徹底解説!マーケターは必見です | 株式会社LIG(リグ)|DX支援・システム開発・Web制作
              • コード品質はやはりビジネスに影響を与える - mtx2s’s blog

                私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

                  コード品質はやはりビジネスに影響を与える - mtx2s’s blog
                • 設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく

                  経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている

                    設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
                  • カスタマーサポートだけど、開発チームに敬意が持てない

                    うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。 バグが直った時に、slack上では開発チームに「修正ありがとうございます」って送ってるけど、なんで自分たちが「ありがとうございます」と言っているのかよくわからない。 開発チームが品質の悪いシステムをつくって、 お客さんがバグを見つけて怒って、 カスタマーサポートがお客さんのサンドバッグになって、 開発チームがバグを直して、 カスタマーサポートが開発チームにお礼を言う。 なにかがおかしい。なんだこれ。 自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。 カスタマーサポートはお客さんをサポートするための仕事なんだよ。 不出来な開発チームのための緩衝材じゃないんだよ。 本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。

                      カスタマーサポートだけど、開発チームに敬意が持てない
                    • CursorにPMBOKやDMBOKを叩き込んで、専門業務を爆速化する未来、見えた!

                      はじめに .cursor/rules/*.mdcファイルでプロジェクト固有のルールをAIに教えられるようになってから、「これって、もしかしてコーディング規約だけじゃなくて、もっと色んな『知識』をCursorにインストールできるんじゃない?」って思い始めました。 例えば、プロジェクト管理のバイブル「PMBOK」とか、データマネジメントの教科書「DMBOK」とか。ああいうカッチリした知識体系をCursorが理解してくれたら、日々の業務がめちゃくちゃ捗るんじゃないか…? そんな「Cursor × 専門知識体系」について、興奮が冷め上がる前に記録を残しておきます。 Cursorに「専門知識」を叩き込むって、どういうこと? まず、おさらいですが、CursorのAIって賢いですよね。コードの提案はもちろん、チャットで質問すれば答えてくれるし、ドキュメント(@docs)を読み込ませれば、その内容に基づい

                        CursorにPMBOKやDMBOKを叩き込んで、専門業務を爆速化する未来、見えた!
                      • 良いコードとは何か - エンジニア新卒研修 スライド公開

                        株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575

                          良いコードとは何か - エンジニア新卒研修 スライド公開
                        • 大成建設、前代未聞「ビル工事やり直し」の内幕

                          「嘘やろう」。ゼネコン関係者が一様に、耳を疑う事件が起きた。 スーパーゼネコンの大成建設は3月16日、北海道札幌市で建築中の高層複合ビルにおいて、鉄骨の精度不良と発注者への虚偽申告があったことを公表した。発注者であるデベロッパーのNTT都市開発が今年1月に現場を視察した際に、不審な点に気づいた。これを発端に、施工不良と数値の改ざんが発覚。建物の鉄骨部分でおよそ80カ所、コンクリートの床スラブで245カ所の精度不良があった。 【2023年4月5日14時08分追記】初出時の建物の鉄骨部分の改ざんのカ所について修正しました。 地上26階(高さ約116メートル)、地下2階のこの高層ビルには、ホテルやオフィス、商業施設が入居予定。だが、発注者が定めた品質基準を満たしていないため、今回、地上部分の鉄骨を解体して建て直す。高層ビルは2024年2月に竣工予定だったが、2026年6月末に延期される。事件の責

                            大成建設、前代未聞「ビル工事やり直し」の内幕
                          • 質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition

                            質とスピード(2022春版、質疑応答用資料付き)

                              質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition
                            • 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022

                              答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略(2022秋版)が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ

                                答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」(その1)。ソフトウェア品質シンポジウム2022
                              • 品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中

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

                                  品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
                                • 自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ

                                  こんにちは、技術広報のyayawowoです。 「自動化(オートメーション/Automation)」 今、この言葉を聞いて胸がときめいた方に必見です! 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します! イベント詳細はこちらをご確認ください! ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド testLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を

                                    自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ
                                  • ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design

                                    2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/

                                      ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
                                    • 若手が生成AI任せで仕事して、レビュー地獄で逆に生産性が落ちた話|片山良平@paiza会長

                                      自分でやって100点取れるその領域のシニア(経験者)がこれやるのは良いのだけど、20点しか取れないジュニアが生成AI任せで16点のものを100個作られるとシニアがチェックで死に、全体としての生産性が落ちる。 …という問題が生成AI駆動開発では既に起きている。 https://t.co/npcE57PTVL — 片山 良平@paiza代表 (@rk611) August 25, 2025 ジュニアエンジニアが生成AIで大量の低クオリティなものを作ってしまうがために、シニアエンジニア(年齢ではなくハイスキルな先輩エンジニア)が、チェックで工数を取られてしまうという問題について何社でも聞いたので、その話をポストしたものです。 これは生成AI駆動開発やってる人、つまりITのエンジニアだけの話だと思っていたのですが、想定以上に色々な領域の方から共感をいただきました。 このブログが良いなと思ったら、n

                                        若手が生成AI任せで仕事して、レビュー地獄で逆に生産性が落ちた話|片山良平@paiza会長
                                      • 仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」

                                        あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 仕事で作業クオリティが低いってコメント来たので話聞いてみると不思議な世界が広がっていた 相手「仕様に書いてないが、普通のエンジニアならできるでしょ」 私「仕様に書いてないならやれません。仕様確認会などあったのでしょうか?」 相手「そんなものない。わからなかったら確認するでしょ」 続 2022-03-16 10:02:09 あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 私「わからないところは都度確認してますが、仕様に記載されていないものを作ることはできませんし、確認すらやりようがありません」 相手「テストでいっぱい不具合出てくる」 私「クオリティコントロールの仕組みがないから当たり前では?」 相手「こっちが確認してないのが悪いってこと?」 続 2022-03-16 10:

                                          仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」
                                        • パナソニック「40年超」続いた品質不正の全実態

                                          「製品の開発中止を避けるため」「開発期間を短縮するため」「出荷停止による混乱を懸念した」「虚偽報告の発覚を懸念したため」 報告書には、品質不正に関与した現場の従業員らの赤裸々な証言が記されていた。 大手電機メーカーのパナソニック ホールディングス(HD)が、品質不正に揺れている。パナソニックHD傘下の電子部品事業会社、パナソニック インダストリー(パナインダ)は、11月1日に外部調査委員会の報告書を公表した。 不正が行われた製品数は約5200品番。今年7月に公表していた153品番から、33倍超へと膨らんだ。パナインダの国内外55拠点のうち、40拠点で何らかの不正行為が発覚。最も古いもので、1980年代から40年以上にわたって隠蔽されてきた。 パナインダが製造しているのは、家電やスマートフォン、PC、自動車など幅広い製品に使われている電子部品だ。影響は同社から電子部品や材料を購入した顧客40

                                            パナソニック「40年超」続いた品質不正の全実態
                                          • 政党の品質保証 | たまき雄一郎ブログ

                                            昨日、ある若手会社経営者の方とお話をさせていただきました。 その方いわく、 「自民、民主どちらの政党の政治家も何人か知っているが、どうしようもない人もいる。」 「会社で言えば、どちらの政党も上場に耐えない。」 「政党は所属議員の品質管理をもっと徹底したやるべきだ。」 「玉木さんも、無所属でやるんだったら、応援しますよ。」 このように、既存政党に対して強い不信感を持っておられた。 しかし、世間一般の感覚もおそらく同じようなものだと思う。 無党派層の多さがそれを物語っている。 「政党とは何か。」 同じ政治理念、政策を共有する集団ということでしょうが、私は、それ以前に、一定のクオリティ(品質)を満たした人の集団であるべきだと思います。 これは、弁護士や会計士などのように一定の資格試験をクリアーすることを条件にするというよりも、 「絶対に、不正をしない。」 「絶対に、不倫をしない。」 などというよ

                                              政党の品質保証 | たまき雄一郎ブログ
                                            • 品質は設計でつくり込む / design in quality

                                              GitHubでAIレビューを組み込む 〜Claude Code Actionデモ&AIエージェントの設計方針〜 / Claude Code Action for beginners

                                                品質は設計でつくり込む / design in quality
                                              • Web制作会社で働いているのだが、 最近、本当に悩ましいことが増えた。 クラ..

                                                Web制作会社で働いているのだが、 最近、本当に悩ましいことが増えた。 クライアントとの打ち合わせで、毎回のように飛び出してくる。 「AIで作れば安くできるんですよね?」 というフレーズだ。 今年に入ってから、この種の問い合わせが明らかに増えた。ChatGPTが話題になったあたりから、みんなAIさえ使えばなんでも簡単にできると勘違いしているように見える。 つい先週も新規のお客さんから「ホームページをAIで作ってほしい」と言われた。予算を尋ねると「AIなら10万円でいけるでしょ?」と返される。普通なら100万円はくだらないボリュームの案件なのにだ。 そこで説明する。「AIは便利な道具ではあるけれど、デザインの方向性を決めたり、業界や商品ごとの細かなニュアンスを理解したり、調整したりするのは結局人間の仕事なんです」と。 だけど相手は納得しない。「YouTubeで、AIが全部やってくれるって見ま

                                                  Web制作会社で働いているのだが、 最近、本当に悩ましいことが増えた。 クラ..
                                                • ソフトウェアテスト入門 / 2022-08-30 software testing

                                                  ■参考 ・JSTQB ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ・

                                                    ソフトウェアテスト入門 / 2022-08-30 software testing
                                                  • 育てるほど楽になる AI 開発体制を作っている話 | BLOG - DeNA Engineering

                                                    こんにちは。ソリューション本部 エンタープライズ事業部 スポーツプラットフォーム部の永田です。普段の業務ではスポーツ領域の新規サービス開発に従事しています。 本記事では、複雑なドメインを持つ新規サービス開発のプロジェクトにおいて、「AI を活用して開発生産性を向上させる」 ために構築した仕組みと、その具体的な例を紹介します。 背景と課題 プロジェクトの特性 本プロジェクトには、以下のような特性があります。 新規サービス開発: ゼロからの立ち上げであり、設計判断が多い タイトなスケジュール: ビジネス要件上、できるだけ早く開発を進める必要がある 複雑なドメイン・コード: 特有の概念や複雑な構造が多く、全体像の把握が難しい。新規メンバーが多いチーム構成も相まって、ドメイン知識の蓄積が十分でない こうした背景から、AI をうまく活用してスピードと品質を両立して開発を効率化したいと考えていました。

                                                      育てるほど楽になる AI 開発体制を作っている話 | BLOG - DeNA Engineering
                                                    • フロントエンドテストプラクティス in open 8

                                                      2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。

                                                        フロントエンドテストプラクティス in open 8
                                                      • ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog

                                                        ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。

                                                          ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog
                                                        • 三菱電機が性能検査で偽装 鉄道用空調、30年以上か:朝日新聞

                                                          三菱電機が、鉄道車両用の空調設備を出荷する際、架空のデータを用いて検査を適正に実施したように装っていたことがわかった。こうした行為は30年以上続いていた疑いがある。複数の関係者が朝日新聞の取材に明ら…

                                                            三菱電機が性能検査で偽装 鉄道用空調、30年以上か:朝日新聞
                                                          • AIによる実装の品質が微妙で毎回自分で指摘しまくる必要があったので、確認前に自動で品質を上げさせるようにした - $shibayu36->blog;

                                                            Claude Codeに実装させた後、毎回自分でコードレビューして突っ込みを入れるのが大変だった。そこで、実装後に自動でセルフレビューと修正をする仕組みを作ったので紹介する。 課題: Claude Codeで出力されたコードの品質が自分の基準を満たさない Claude Codeで一気に実装ができるようになった反面、出力されたコードの品質が自分の基準を満たさないことが多かった。そのため、変更のたびに毎回ツッコミを入れていて、かなりの手間がかかっていた。プランモードで事前にちゃんと設計したとしても、コードレベルでは満足いかないことが多かった。 じゃあサブエージェントやCodex CLIで先にレビューして直し切ってもらってから確認すれば良いのでは?と思ってやってみた。しかし、AIのレビュー指摘には的外れなものや過剰なものも混じるため、全部対応させるとかえってコードが散らかってしまうこともあった。

                                                              AIによる実装の品質が微妙で毎回自分で指摘しまくる必要があったので、確認前に自動で品質を上げさせるようにした - $shibayu36->blog;
                                                            • さまざまな業界で「ガワだけ綺麗なニセモノで客を騙すように稼ぎ、トラブルがあれば逃げる」が増えすぎて"高い=上質"の期待がなくなってきた

                                                              Neo_EMA @NeoEMA2000 被害者の方のご冥福をお祈りするとともに感じるのは、なかなかに今の社会をよく表した事件だと思うんですよね。「ガワだけ綺麗に設えたニセモノで、客を半ば騙すような形で小金掴んで、トラブれば潰してトンズラこけばオッケー」みたいなのがどの業界でも蔓延ってますもんね。 x.com/shibetuchan/st… 2025-12-17 17:51:48 みんないつかはだよ @shibetuchan 高級サウナ店のニュースひどいね。ドアノブ外れて開かないわ、緊急ボタンの電源切れてるわ、部屋の構造も完全密室で殺人じゃんね。昔、大学生だかが作ったアート遊具?が燃えて幼い子が亡くなった事件あったけど、見映えとか話題性みたいな店や物ばかりでうんざりする。おまけにバカ高いのに素材価値0基礎0みたいの多すぎ。 2025-12-17 12:07:47

                                                                さまざまな業界で「ガワだけ綺麗なニセモノで客を騙すように稼ぎ、トラブルがあれば逃げる」が増えすぎて"高い=上質"の期待がなくなってきた
                                                              • Vue.js?React?フレームワーク選びの7つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog

                                                                こんにちは。モノタロウでフロントエンド寄りの開発をしている、陳です。 今回はモノタロウの新フロントエンドのメインフレームワーク選定についてお話しします。 選定結果から言うと、モノタロウ独自の7つの選定基準をもとに、Reactを選ぶことになりました。 背景 新フロントエンドプロジェクトの立ち上がり Vue.jsとReactの比較検討をしてみた 俯瞰して改めて選定基準を考えた 一般的な視点 モノタロウの社内事情 7つの選定基準 選定結果 技術選定を通して得た3つの学び 背景 まず、モノタロウの現フロントエンドについてざっくり説明します。 モノタロウは2002年から、PythonとJavaScriptでECサイトを開発してきました。 基本構成として、サーバサイドのPythonでHTMLを生成し、クライアントサイドのJavaScriptでカートインなどの動的処理を補完する形ですが、実はこの構成で違

                                                                  Vue.js?React?フレームワーク選びの7つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog
                                                                • 品質管理の歴史学 / Quality Management History

                                                                  WACATE 2024 冬での発表資料です。

                                                                    品質管理の歴史学 / Quality Management History
                                                                  • バグ密度・テスト密度に依存しない品質保証への挑戦 | NTTデータ

                                                                    カテゴリで探す 業界トレンド/展望 技術トレンド/展望 事例 サービスで探す コンサルティング 戦略コンサルティング 社会課題コンサルティング 業務コンサルティング デザインコンサルティング 変革支援コンサルティング アプリケーション・サービス テクノロジーコンサルティング CRM(Salesforce) ERP(SAP/Biz∫) 顧客接点・決済 カーボンニュートラル SCM ロジスティクス 電子申請 データ&インテリジェンス 生成AI アプリケーション開発・管理 データスペース ブロックチェーン 量子コンピュータ・イジングマシン デジタルツイン IoT ロボティクス・RPA クラウド ネットワーク データセンター サイバーセキュリティ ビジネスプロセスサービス 業種で探す 金融 官公庁・自治体 医療・ヘルスケア 防災・レジリエンス 食品 流通・小売 モビリティ 製薬・ライフサイエンス

                                                                      バグ密度・テスト密度に依存しない品質保証への挑戦 | NTTデータ
                                                                    • まだAIコードをレビューするか、しないかで言い争ってるの?

                                                                      AIが生成したコードをレビューするべきかどうか、という議論は定期的に起こります。 3カ月以上その問題に悩んでいる人は、たぶんとっくに何らかの結論に達していると思います。 2026.03.08 改修メモ レビュー0に拘り過ぎているように読めたので、表現を全体的に柔らかくしました。 私の結論 品質を維持したままコードレビューを減らせるよう、開発プロセス全体を改善する必要がある これは、すでにレビューしなくて済むようになったとか、レビューを0にしなくてはならないという話ではありません。品質を保ったまま、大幅にコードレビューを削減し続けなければならないという話です。 これは、少なくとも次の3つの確定的な事実に基づいています。 今後コードレビュワーは育てられない AIはレビュワーを物量でひき殺す 今のままのレビューを人が続ける組織は、コードレビューを軽量化した組織に淘汰される そのために必要なことも

                                                                        まだAIコードをレビューするか、しないかで言い争ってるの?
                                                                      • 企業努力のおかげで『安かろう悪かろう』みたいな事は実はそんなにないが、安いウィンナーと安いラップと安いイヤホンは買ったら後悔する

                                                                        デレク宮内 @DerekDount 企業努力のおかげで「安かろう悪かろう」みたいなことは実はそんなにないんですけど、安いウィンナーと安いラップと安いイヤホンは買ったら後悔する。安いウィンナーと安いラップと安いイヤホンは企業の頑張りだけではどうにもならないらしい 2026-01-21 16:03:44

                                                                          企業努力のおかげで『安かろう悪かろう』みたいな事は実はそんなにないが、安いウィンナーと安いラップと安いイヤホンは買ったら後悔する
                                                                        • フロントエンドのテストは皆のためのもの | POSTD

                                                                          テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種

                                                                            フロントエンドのテストは皆のためのもの | POSTD
                                                                          • テストの自動化とテスト駆動開発

                                                                            組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい: ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのか…

                                                                              テストの自動化とテスト駆動開発
                                                                            • アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer

                                                                              Developers Summit 2021 Summer[A-1]アジリティを支える品質特性 講演日時: 2021年07月30日(金) 10:00 ~ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏に…

                                                                                アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
                                                                              • IIJ勝社長、ドコモの回線品質問題で「苦情が増えている、事前の連絡が全くなかった」と不快感

                                                                                  IIJ勝社長、ドコモの回線品質問題で「苦情が増えている、事前の連絡が全くなかった」と不快感
                                                                                • 技術的負債は開発者体験を悪化させる - mtx2s’s blog

                                                                                  ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad

                                                                                    技術的負債は開発者体験を悪化させる - mtx2s’s blog

                                                                                  新着記事