並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 25 件 / 25件

新着順 人気順

要求仕様書の検索結果1 - 25 件 / 25件

  • イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ

    イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ:山浦恒央の“くみこみ”な話(178)(1/3 ページ) ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第9回は、「ヒアリング」した内容をまとめる「要求仕様書作成」について、情報工学専攻の大学3年生でも悩む「ジャンケンの要求仕様書」を例にその難しさを解説します。

      イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ
    • イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる

      今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2.要求仕様フェーズでは何をするのか 図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。 2.1 要求仕様フェーズ ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。 取扱説明書は、一般ユーザー向けのドキュメントで、そこには「(1)以下の部品がそろっていることを確認してください……、(

        イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる
      • 「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ

        こんにちは、west-cです。 業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。 【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術 ~仕様が書けていますか? 作者:清水 吉男技術評論社Amazon ◆ 関連ブログ 仕様書 とは 【まとめ】 おすすめの読者層 要求仕様書の目的・ゴールが曖昧な方 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方 依頼者から要求を引き出す方法の糸口を掴みたい方 要求仕様書とは 書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。 要求(今回の機能で実現したいこと)は曖昧なものを含

          「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ
        • 要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説

          要件定義書と要求仕様書の違いとは?システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか? システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。

            要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説
          • イチから全部作ってみよう(7)正しい要求仕様書の第一歩となるヒアリングの手順

            1.はじめに 山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。第170回を読んでいない方は、以下のリンクから一読することをおススメします。

              イチから全部作ってみよう(7)正しい要求仕様書の第一歩となるヒアリングの手順
            • 要求仕様書とはなにか|daiki nishioka

              ※この記事は hey アドベントカレンダー2020 9日目の記事です。 STORES でプロダクトマネージャーとして働いている西岡(@nishiokadaiki1)と申します。 プロダクトマネージャーの重要な仕事である要求仕様書についてnoteをかきます。過去何度も要求仕様書らしいものは書いてきたのですが、最近の開発プロジェクトの中で書く意味や内容が、ようやく腹落ちした感覚があったので、hey アドベントカレンダーという良い機会にアウトプットしてみます。 要求仕様書とは最初に、要求仕様書とは何かを簡単に説明します。 要求仕様書とは、開発をする前にプロダクトマネージャーが、機能を実施する背景や内容、目的をまとめたものです。開発チームで実際につくる機能を議論していく土台となります。必要となる情報が欠けていたり、論理構造が破綻していると、議論が中々前に進まず、開発スピードが落ちてしまう原因になり

                要求仕様書とはなにか|daiki nishioka
              • イチから全部作ってみよう(12)要求仕様書の異常系を階層構造を使って洗い出す

                上記では、例えば、「不良品を作った場合」「火傷をする」といった場合も考察しています。実際の「たこ焼き模擬店」の運営では、「異常系は、あらかじめ対処法は決めず、実際に発生してから、常識と良識で臨機応変に(あるいは、テキトーに)対応する」ことになるでしょう。 正常ケースでも、日常生活では、毎日、毎時、毎分、細かい判断をしています。朝起きて学校へ行くまで「目覚まし時計が鳴って、あと1分だけ寝ていようか?」「どのシャツを着ようか?」「歯磨きは十分か?」「髪形は見苦しくないか?」「バスの時間が迫っているので、走ろうか?」「前から来る歩行者を右に避けるか、左に避けるか?」「この地下鉄の車両は満員なので、隣の車両から乗ろうか?」など、無意識のうちに大量の判断をしています。プログラミングでは、この全ての判断を考慮しなければなりません。異常が発生した場合も同様です。そう考えると、朝、起床して学校へ行くのは、

                  イチから全部作ってみよう(12)要求仕様書の異常系を階層構造を使って洗い出す
                • ソフトウェア技術者のためのバグ百科事典(7)要求仕様書がバグってる

                  1.はじめに このバグ百科事典では、筆者が気になったバグを紹介し、読者の方々に「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2.要求仕様フェーズ ソフトウェア・ライフサイクルの中で最も重要なフェーズは、もちろん、要求仕様フェーズです。このフェーズでは、顧客が求める「機能」をキチンと聞き取り、要求仕様書にまとめます。例えば、エアコンのソフトウェアの場合、「機能」には、「室内を冷やす」「室内を暖める」「除湿する」「除菌する」などがあります。 要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響します※1)。今回は、全工程の「最重要フェーズ」である要求仕様書のバグを取り上げます。 2.1 要求仕様が凍

                    ソフトウェア技術者のためのバグ百科事典(7)要求仕様書がバグってる
                  • 苦労せずにプロダクト要求仕様書を作成する方法 - Qiita

                    (原文) How to Write a Painless Product Requirements Document ドキュメントの大部分は初期段階で作成されますが、実装段階はUXデザインプロセスの中で最も重要な段階の一つです。 リサーチ、分析、デザインの各段階で多くのコンセプトを練ってきましたが、いよいよ重い腰を上げる時が来ました。ドキュメントが必ずしも製品と一致するわけではないことを理解しているので、ここでは必要なものだけを紹介します。 この記事では、Product Huntのプロダクト要求仕様書をベストプラクティスとして取り上げ、あなたのものにする方法を説明します。ぜひ無料のPRDテンプレートを使ってみてください。 プロダクト要求仕様書の作成方法 「試作」段階に入ると、それまでのリサーチやプロトタイピングによって、チームは製品についてのハイレベルな理解を得られるはずです。企業によって

                      苦労せずにプロダクト要求仕様書を作成する方法 - Qiita
                    • Notionで製品要求仕様書(PRD: Product Requirement Docs)を作成する方法

                      プロダクトマネージャーは、Notionのフォーマットを使って製品要求仕様書(PRD)を作成してみてはどうでしょうか。チームメンバーとより良いコラボレーションができ、部門を超えたコミュニケーションを実現できます。

                        Notionで製品要求仕様書(PRD: Product Requirement Docs)を作成する方法
                      • USDM(要求仕様書を作成する時のお作法)の概要と、要求・理由・説明・仕様の書き方について、まとめてみました - Qiita

                        USDM(要求仕様書を作成する時のお作法)の概要と、要求・理由・説明・仕様の書き方について、まとめてみました初心者備忘録要件定義USDMAdventCalendar2022 1.はじめに どうも、ARIの名古屋支社に勤務している愛知県民こと、 新藏(にいくら)と申します♪ (/・ω・)/ 突然ですが、某日に私は 「自分は社会人5年目で、基本設計、詳細設計、単体テスト、結合テスト、移行、保守等々は やったことあるけど、ばっこり要件定義をやったことはないな・・・」と考えていました。 何かしら勉強してみようということで、 今回はUSDMの概要や書き方について記事にしたいと思います! 要件定義、USDM等について勉強中の方の参考になれば幸いです。 (*^^)v ちなみに、12月はARIのアドベントカレンダもやっていますので、 もしよろしければ、こちらも応援お願いします♪ 2.USDMとは まずは、

                          USDM(要求仕様書を作成する時のお作法)の概要と、要求・理由・説明・仕様の書き方について、まとめてみました - Qiita
                        • 要求仕様書とは? 要求定義書・RFPとの違いを解説 | 情シスBlog

                          システムやソフトウェアの開発において、どのような機能が必要であるかを明確にする文書として「要求仕様書」というものがあります。この記事では、なぜ要求仕様書を作る必要があるのか、その設計方法、書き方といった作成の上での注意点だけではなく、似たような言葉である「要求定義書」と「RFP」との違いをわかりやすく解説します。 「要求仕様書」には、次の2つの側面があります。 クライアントの要求、希望などを記述した仕様書 クライアントの要求や希望の中でも、システム開発で必要なものを示した仕様書 要求仕様書は、開発チームが開発をする前に作成するべき文書として、システムやソフトウェアの要件を明確化するために使用されます。この文書には、システムの目的や機能、性能、インターフェース、セキュリティ、品質保証など、開発に必要な要件や仕様が詳細に記載され、プロジェクトの進行や品質を確保する上で重要な役割を果たします。そ

                            要求仕様書とは? 要求定義書・RFPとの違いを解説 | 情シスBlog
                          • PRD一部Contents解禁!楽楽精算のPRD(製品要求仕様書) Agenda - RAKUS Developers Blog | ラクス エンジニアブログ

                            皆さん、こんにちは!もしくはこんばんは! 楽楽精算プロダクトマネージャーの@wekkyyyyです。 前回は「PdMとPMMの役割分担・連携」というテーマで記事をかかせていただきました。 tech-blog.rakus.co.jp 今回は、楽楽精算のPRD(製品要求仕様書) Agendaというテーマでブログを記載します。 目次は以下となります。 対象読者 前提 楽楽精算のPRD(製品要求仕様書) Agenda(一部) 一番重要と考えるAgenda Contentsサンプル ラクスのPdMとして活躍してみませんか? 対象読者 PRD(製品要求仕様書)を作成する、PdM(PM)・プランナー・PjM等の方々 前提 あくまで楽楽精算ではこうです。のサンプルですので、これが絶対!というものではございません。 会社・プロダクトごとにPdM(PM)等の役割定義は様々です。そのためどこまで書くかはそれぞれで

                              PRD一部Contents解禁!楽楽精算のPRD(製品要求仕様書) Agenda - RAKUS Developers Blog | ラクス エンジニアブログ
                            • PRD(プロダクト要求仕様書)をエンジニアが書く!エンジニアとPdMの分業体制|Cloudbase

                              クラウドセキュリティ製品 Cloudbaseでプロダクトマネージャーをしている大峠 (@0meo)です。 Cloudbaseでは、ソフトウエアエンジニアが “プロダクトエンジニア” として機能設計の上流から関わります。 本記事では、弊社が1つの機能を開発着手可能にするまでに実施するドキュメンテーション手法のノウハウと、プロダクトエンジニアとPdMが分業しながら権限委譲を進めた過程についてご紹介します! この記事を書いた人 大峠 和基(おおたお かずき) Cloudbase 株式会社 PdM 筑波大学大学院卒。学生時代からスタートアップ企業で研究論文の執筆や特許の出願に関わる。自動生成動画AIのサービスを開発して起業し、未踏事業スーパクリエータ認定及び未踏アドバンスト事業イノベータ認定を受ける。 2023年1月よりCloudbaseにジョイン。プロダクトマネージャーとして、データ分析やユーザ

                                PRD(プロダクト要求仕様書)をエンジニアが書く!エンジニアとPdMの分業体制|Cloudbase
                              • 要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説

                                要件定義書と要求仕様書の違いとは?システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか? システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。

                                  要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説
                                • PRD(製品要求仕様書)を常に最新の状態に保つ

                                  PRD (Product Requirements Document : 製品要求仕様書) は常に最新の状態に更新し続けましょう、という話をご紹介します。 PRD (Product Requirements Document : 製品要求仕様書) とは? PRD の書き方については、本記事では触れませんので以下の記事を読んでください。 スタートアップのための製品要求仕様書(MRD & PRD)の書き方 | by Hiroki Shimada | Medium 初めて書くPRD(プロダクト要求仕様書)|94|note PRD はプロダクト開発の道標 PRD はプロジェクト開発における道標だと考えており、作成・共有して、それを最新状態に更新し続けることが大切だと考えてます。 私自身、PRD を書いたことは以下のようなフローで進めていました。 (前提条件: スタートアップ企業での経験です) PR

                                  • 苦労せずにプロダクト要求仕様書を作成する方法

                                    (原文) How to Write a Painless Product Requirements Document ドキュメントの大部分は初期段階で作成されますが、実装段階はUXデザインプロセスの中で最も重要な段階の一つです。 リサーチ、分析、デザインの各段階で多くのコンセプトを練ってきましたが、いよいよ重い腰を上げる時が来ました。ドキュメントが必ずしも製品と一致するわけではないことを理解しているので、ここでは必要なものだけを紹介します。 この記事では、Product Huntのプロダクト要求仕様書をベストプラクティスとして取り上げ、あなたのものにする方法を説明します。ぜひ無料のPRDテンプレートを使ってみてください。 プロダクト要求仕様書の作成方法 「試作」段階に入ると、それまでのリサーチやプロトタイピングによって、チームは製品についてのハイレベルな理解を得られるはずです。企業によって

                                      苦労せずにプロダクト要求仕様書を作成する方法
                                    • 大手メーカでSEを担当、コーディング経験はほぼありません。設計等もほとんど外注で要求仕様書でさえ適当に書いている状態です。今後のため転職したいのですが、スキルを独学で身につけてからのが良いでしょうか?

                                      回答 (20件中の1件目) 大手インフラ関係の会社でSEを担当、40歳を超えているものの役付きではなくコーディングから設計から要求仕様から要件定義からリードの脇や陰でやっている状態です。将来のために現実の一つをお伝えしたいと思ったので回答してみます。 自分の周りをよく見てみてください。なりたい姿には今の環境でもなれます。 「環境が人を作る」と言われます。これは事実そうだと思います。するとご質問のように転職で環境を求めるという考え方になるのも頷けます。環境を求めて転職していく人も周囲にはいました。 ただ…私は虚しく思ってしまうのです。ご質問のように考える人が「技術的なスキルを活かす道...

                                        大手メーカでSEを担当、コーディング経験はほぼありません。設計等もほとんど外注で要求仕様書でさえ適当に書いている状態です。今後のため転職したいのですが、スキルを独学で身につけてからのが良いでしょうか?
                                      • KDDI、バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書を完成|BUSINESS NETWORK

                                        KDDI、バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書を完成 KDDIグループ キャリアインフラ ルーター/スイッチ KDDIは2021年6月8日、米Facebookが推進するTelecom Infra Project (以下、TIP) において、バックボーンネットワークの通信制御を担う次世代分散型大容量ルーターのハードウェアおよびソフトウェアの要求仕様書の作成を今年4月に完了したと発表した。 KDDIは、2020年3月に設立したTIP Open Optical Packet Transport (OOPT) プロジェクト内の新たなサブグループDisaggregated Open Routers (以下、DOR) の議長として、通信事業者のバックボーンネットワークにおけるルーターのホワイトボックス化に向けた技術開発を進めている

                                        • 要求仕様書記述手法「USDM」について思う - ヒャッハー!ふっくら太郎です。

                                          こんちは。志望校がふっくら太郎になる。 ふっくら太郎です。 今回は、USDMについて、ちょろっと勉強する機会があったので、感想を書きます。 USDMは、普段の業務の中で触れてはいるのですが、仕様書のフォーマット程度の認識 しかなく、こんなかっこいい名前があることすら知りませんでした。 先日、ある方に教えてもらう機会があり、興味を持ち勉強した次第です。 USDMって何や? USDMは、「Universal Specification Describing Manner」の略語で、要求と仕様の記載方法を定義したもの 株式会社システムクリエイツの清水 吉男さんが提唱している。数冊本が出てます。 [改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか? 作者: 清水吉男 出版社/メーカー: 技術評論社 発売日: 2010/05/01 メディア: 単行本(ソフトカバ

                                            要求仕様書記述手法「USDM」について思う - ヒャッハー!ふっくら太郎です。
                                          • PRD(プロダクト要求仕様書)とPoCを自動作成するプロンプトとGPTs|IT navi

                                            ChatGPTの最新モデルのGPT-4oは、簡単なプロンプトでプロダクト開発プロジェクトに必要なPRD(プロダクト要求仕様書)やPoC(概念実証)を作成することができます。 今回は、これらを作成するためのプロンプトとGPTsについて解説します。 1.PRDとPoC(1) PRDとはPRDは「Product Requirement Document」の略で、プロダクト要求仕様書と訳されます。これは、プロダクト開発プロジェクトにおいて、プロダクトの要件や仕様を明確に記述した文書です。PRDは、開発チームやステークホルダーが共通の理解を持ち、プロジェクトをスムーズに進行させるために重要です。以下はPRDの主な構成要素とその内容です。 1. 目的と背景 目的: PRDの作成目的や、プロダクトが解決する問題、ターゲット市場などを記述します。 背景: 市場の現状、競合分析、ユーザー調査結果など、プロダ

                                              PRD(プロダクト要求仕様書)とPoCを自動作成するプロンプトとGPTs|IT navi
                                            • 要求仕様書|VBAで人の為に作る開発ドキュメント - ゆんの業務改善ブログ

                                              この記事は非エンジニアの会社員で現業を持ちながらVBAでたまに自動化ツールを作っているというような方を読者として想定しています。 目次 非エンジニアに必要な開発ドキュメント3つのうちの要求仕様書 要求仕様書とは VBA開発に詳細な要求仕様書はいらない 要求仕様書の目的を意識する 要するに何が必要なのかを記述する VBA開発における要求仕様書の作成手順 非エンジニアに必要な開発ドキュメント3つのうちの要求仕様書 会社員がVBAで自動化するのに必要な開発ドキュメント3点で解説した通り、非エンジニアがVBAで他人が使うことを全停止としたツールを開発をするには要求仕様書、仕様書、チェックリストの3つの開発ドキュメントを用意すべきです。 今回はそのうち、要求仕様書について解説します。 要求仕様書とは 要求仕様書とはユーザーがソフトに要求する機能を記した開発ドキュメントです。細かく言えば要求仕様書の中

                                                要求仕様書|VBAで人の為に作る開発ドキュメント - ゆんの業務改善ブログ
                                              • バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書が完成 | KDDI News Room

                                                KDDI株式会社 KDDIは、Facebook, Inc. (本社: メンローパーク カリフォルニア州、CEO: マーク・ザッカーバーグ) が推進するTelecom Infra Project (以下 TIP) において、バックボーンネットワーク (注1) の通信制御を担う次世代分散型大容量ルーターのハードウエアおよびソフトウエアの要求仕様書の作成を、2021年4月に完了しました (注2)。これにより、開発パートナー・ベンダーは既存の製品から約3倍となる最大614.4Tbpsの処理が可能なルーターの開発が可能となり、通信事業者の5G設備の構築に貢献します。 <大容量ルーターのイメージ> KDDIは、2020年3月に設立したTIP Open Optical Packet Transport (OOPT) プロジェクト内の新たなサブグループDisaggregated Open Routers

                                                  バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書が完成 | KDDI News Room
                                                • イチから全部作ってみよう(11)たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る

                                                  今回は、前回作成したたこ焼き模擬店の要求仕様書をより詳細化します。 3.たこ焼き模擬店で考える要求仕様書の問題点 理想的な要求仕様書は、正常時だけでなく、異常時、限界時も含めて、発注側の要求事項を漏れなく明確にまとめ、見聞きしたことがない人にも伝わる文書とすることです。しかし、これは簡単なことではありません。前回のたこ焼き模擬店の要求仕様書から発生し得る問題点を考えます。 ソフトウェアの開発は、人類が作る人工物の中で、圧倒的に高難度です。これには、(1)規模が大きい、(2)適用しなければならない自然界の法則がない(考え方さえ正しければ、何でもOKの「芸術」を工学的に作るようなものです)、(3)目に見えない、(4)異常処理、境界処理、特殊条件が多過ぎる、という4つの理由があります。 (4)に関して、人間は一切間違えず、悪意満載の行為もせず、全ての機器が正常に動作するならば、世の中の処理や作業

                                                    イチから全部作ってみよう(11)たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る
                                                  • 【プラント設計の失敗事例】顧客からの要求仕様書を読まずに受注して大変なことに! | プラントエンジニアは語る

                                                    みなさんこんにちは、プラントエンジニアのヤンです。 前職では顧客向けにプラントを設計製作納入する仕事をしていたので、自社の設計基準+顧客の設計基準の両方を適用する必要がありました。 ですので、時には数百ページに及ぶ設計基準書から適用されるところを抜粋して、仕事を進めていく必要がありました。 非常に時間のかかる作業でしたが、これを怠り顧客の設計基準を満足できない、つまり顧客要求を満足できないと、プラントとしての能力は問題なくても納入できない恐れがあります。 もちろん、プラントとしての能力が発生できなければ大問題です。 すこし古い話ですがこのような事例もあります。これはかなり極端な事例だと思いますが。 住友重機、焼却灰施設を巡る紛争の全貌京都地裁での判決は2016年の5月27日に出ているようですが、この後どうなっているんですかね? ここで、僕がどんなトラブルに遭遇して来たかを書くことで「顧客満

                                                      【プラント設計の失敗事例】顧客からの要求仕様書を読まずに受注して大変なことに! | プラントエンジニアは語る
                                                    1