![なぜGoogleは“あなたの不満”を無視できるのか | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/df1fbcfb853756284b40841e70fc320268975ba8/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F04%2F04Apr2024.jpg)
![ChatGPTを10倍以上高速化、秒速1,000兆回の演算ができるAIチップを開発 シリコンバレーで注目されるAIスタートアップGroqとは | AMP[アンプ] - ビジネスインスピレーションメディア](https://cdn-ak-scissors.b.st-hatena.com/image/square/082876f96f10999bb44dfa8b23e5f52283eda67a/height=288;version=1;width=512/https%3A%2F%2Fampmedia.jp%2Fwp-content%2Fuploads%2F2024%2F03%2Fshutterstock_1928860634-2.jpg)
テクニカルライティングの基本
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
PDFファイルをクリックすると、あたかも紙に印刷したかのように、どんなマシンでも同じような見た目で文章や画像がディスプレイに表示されます。 この単純な事実は、日常的にPDFファイルを利用していると当たり前に感じられるかもしれません。しかし、よくよく考えると驚くべきことです。 いったい、どのような仕組みがあれば、「過去から現在に至るさまざまな種類のコンピューターで見た目を変えずに同一の紙面を再現する」という目的を達成できるでしょうか？ そのような仕組みがけっして自明なものでないことは、コンピューターに少し詳しい人であれば容易に想像できると思います。 PDFファイルの中身には、この「多様なマシン環境で文書の同一の見た目を再現する」という目的にとって必要な要素がぎっしり詰め込まれています。 この目的に特化して開発されたファイルフォーマットと、それを解釈して表示するための専用アプリケーションが、「
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」
あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 仕事で作業クオリティが低いってコメント来たので話聞いてみると不思議な世界が広がっていた 相手「仕様に書いてないが、普通のエンジニアならできるでしょ」 私「仕様に書いてないならやれません。仕様確認会などあったのでしょうか？」 相手「そんなものない。わからなかったら確認するでしょ」 続 2022-03-16 10:02:09 あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 私「わからないところは都度確認してますが、仕様に記載されていないものを作ることはできませんし、確認すらやりようがありません」 相手「テストでいっぱい不具合出てくる」 私「クオリティコントロールの仕組みがないから当たり前では？」 相手「こっちが確認してないのが悪いってこと？」 続 2022-03-16 10:
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
AWS テクニカルサポートを 5 年経験して アノテーションの荒川です。 クラスメソッドメンバーズをご契約いただいているお客様のテクニカルサポート業務を始めて、早 5 年が経過しました。 私が対応したチケット件数をざっくりと調べたところ、本日時点で 1685 件でした。 最近は私がチケット対応する機会は減りまして、チケット対応メンバーの教育（新入社員から各チームへ所属するまでの育成）やチケット相談に使う時間がメインです。 その中で、今まで何となくこうやって対応すると上手くいくと感じていた暗黙知をメモ書きしていたので、今回ブログとして公開します。 回答者側で意識したいこと 技術的なお問い合わせに関するガイドラインを参考にする AWS サポートのガイドラインは、一般的なカスタマーサポートでも使えます。 一文を短くし、適宜改行を挿入する 例: 一行にぎっしり × お客様環境をお調べしたところ、E
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
Google、マイクロソフトらが設立、「Open Web Docs」を発表。MDNなど支援、Web技術のドキュメント化を推進
オープンソースやテクノロジーを中心としたコミュニティの維持や発展を支援する組織「Open Collective」は、Web技術のドキュメント化を長期的に支援する取り組みとして「Open Web Docs」を発表しました。 Open Web Docsはおもに既存のコミュニティによるドキュメント、特にMozillaのMDNをまずは優先的に支援するとしています。 We’re happy and proud to announce Open Web Docs, to support a community of technical writers around creation and long-term maintenance of web platform technology documentation that is open and inclusive for all.https://t
日本のプログラマはレベルが低い
日本のプログラマでマスを占めてるのは、大規模SIのコーダーじゃん？ そんで、そこでのお仕事はExcel方眼紙に書かれた設計書を、ひたすらプログラム言語に翻訳するだけという。 だから翻訳するために最低限の言語仕様だけ知っていれば良くて、あとはまあ上手に立ち回るコミュ力があれば上出来とされるけど、あくまでオプション扱い。 仕事そのものには数学的素養どころか、理系的センスすら全く不要。 つまり、SIにおけるプログラミングは工学でも自然科学でもない。 そんな知識がなくても務まるし、実際備わっていない人が大半。 だからSIにおけるプログラマはどう間違ってもエンジニアではない。 もしエンジニアなどと言ってしまったら、他の分野の「正しい」エンジニアに失礼だろう。 というか、エンジニアと呼べるレベルには程遠いと言い換えてもいい。 まあライン工としては一人前だと思うが。 以上のことから結論づけると、タイトル
FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事（厳密には違うんですが、本旨ではないので割愛します）→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い
Goの言語仕様書精読のススメ & 英語彙集
この記事について Go言語公式から提供されているThe Go Programming Language Specificationという文章があります。 実際のThe Go Programming Language Specificationのページ画面 この文章、個人的にはじっくり読んでみると結構得るものが大きいな、と感じるものです。本記事では The Go Programming Language Specificationって何が書いてあるの？ 読んだら何がわかるの？ 読むときにはどういうところに注目したらいいの？ 英語難しいから単語教えて！ という疑問に答えながら、The Go Programming Language Specification精読の布教を行います。 The Go Programming Language Specification とは？ The Go Prog
PHPerKaigi 2024の登壇資料です。
Markdown 左右2画面でのリアルタイムプレビューが可能。言語ごとのコードハイライトや絵文字や注釈(footnotes)、タスクリスト、Bootstrap による HTML コードにも対応しています。 シンプルなアセット管理 ファイルのアップロードは編集画面にファイルをドロップするだけです。ストレージはローカルFS、AWS S3、Google Cloud Storage、MongoDB GridFS の4種をサポートしています。 強力な GUI による図表編集 draw.io 連携機能を使うことで、様々な図を簡単に描くことができます。(v3.7.0 以降) 編集画面内にあるツールバーの draw.io ボタンを押すことで diagrams.net (旧 draw.io) 編集ウィンドウ上で図を直感的に作成・編集することができます。
設計書・仕様書の書き方が分かる！
弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。 各工程で必要なドキュメントを定義しましょう 下記のように工程ごとにドキュメント成果物、内容を定めております。 どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。 ※業務系のシステム開発に照準を当てております。 要求分析（要件定義） システム開発は要求分析（要件定義）というプロセスから始まります。要求分析（要件定義）は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性／定量） 体制図
【データ基盤チーム ブログリレー 3日目】 こんにちは、エンジニアリンググループの石塚です。 趣味は筋トレです。好きなトレーニングはレッグカールです。今年2023年の1月に第一子が爆誕し、毎日子供の笑顔に癒されております。一方であまり言い訳にはしたくはないですが、事実自分自身の自由に使える時間は少なくなったなと感じております。そんな中でもトレーニングの時間は作りたいので、24時間ジムに契約して妻と娘が寝ている早朝の時間にウホウホトレーニングをしている今日この頃であります。時間のありがたみをとても感じるようになりました。 これは仕事でも同様かと思います。有限な時間の中でタスクを取捨選択して価値ある成果を上げていく事が仕事では求められます。ドキュメンテーションはその価値ある成果につながる時間を増やす一助になるかもしれません。 この記事では、ドキュメンテーションの必要性について言語化します。改め
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
HTML HTMLの仕様策定には複雑な歴史があります。詳細は他の解説記事に譲りますが、簡単に述べるとW3CとWHATWGのダブルスタンダード状態が長い間続いていました。2022年現在はWHATWGによってLiving Standardとしてまとめられた仕様が実質的な標準となっています。Living Standardという名前が示す通り、バージョンはなくエディターによって随時更新されています。 CSS CSSの仕様はW3Cが策定しています。現在は、CSSとして1つの標準仕様があるわけではなく、数多くのモジュールに分かれて標準仕様の策定が進められています。草案、勧告候補などを経て勧告に至るプロセスと、Levelという概念で整理されたバージョン管理が特徴です。年に1度、SnapShotとしてその時点での標準化の概況が公開されています。 JavaScript JavaScriptは主にWebブラウ
基本設計は、顧客の要件を実現するための機能を具体化する工程だ。 基本設計工程では、画面・帳票・テーブルなどの設計した後に「基本設計書」としてまとめるが、どのような資料を作るのか不安を感じるエンジニアも多いと思う。 そこで...
A guide to writing specs toward engineers(Japanese)
This slide is for Product Managers who want to write specs that can get buy-in from engineers and that is well stated that a team can start working on it without hassle. エンジニアから共感を得られて、チームがすぐに動き出せる仕様書を書きたいプロダクトマネジャーに向けたスライドです。
Show navigation All episodes In this article, we take a simple function in the spec and try to understand the notation. Let’s go! Preface #Even if you know JavaScript, reading its language specification, ECMAScript Language specification, or the ECMAScript spec for short, can be pretty daunting. At least that’s how I felt when I started reading it for the first time. Let’s start with a concrete ex
これ超大事 単にペラペラ喋っても、それはレビューできないんだよ 喋ってることってまとまっていないから ディスカッションはいいんだけどね ただ言っただけのことを「決め事」にするのはとても危険 https://t.co/DzASlZNqqs— magnoliak🍧 (@magnolia_k_) 2022年3月5日 「書かれて、レビューを受けて、合意されたものだけが決定事項だ」って言われた— magnoliak🍧 (@magnolia_k_) 2022年3月5日 「○○さんが言ってました」では決定事項であることの証跡にならないって— magnoliak🍧 (@magnolia_k_) 2022年3月5日 何を持って「決まったこと」とするか、その定義があいまいなまま進めると当たり前だけどロクなことが無い。 「仕様は○○です」と言っても、実はたまたま誰かが「こうしようかな」と呟いただけのことだ
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
long doubleの話 - Qiita
C言語の long double は環境によって実体がまちまちである。この記事ではその辺をまとめてみる。 C言語の規格での話 まず、C言語の規格で浮動小数点数がどういう扱いになっているか確認しておく。 C言語では、多様な環境に対応するため、浮動小数点数がIEEE 754に準拠しない環境も考慮している。符号、基数、指数部、仮数部がある点はIEEE 754と同じだが、 基数 $b$ は1より大きい整数（IEEE 754では2または10のいずれかとしている） 指数部の範囲 $\mathit{emin}$, $\mathit{emax}$ の関係は特に規定されていない（IEEE 754では $\mathit{emin}=1-\mathit{emax}$ としている）。 0, 無限大、NaNは符号付きでも符号なしでも良い。 非正規化数がなくても良い。 となっている。 <float.h> ではその環境
Page not Found | Monstarlab
Page not found.
Excel で設計書作るのそんなに悪いことか？ 僕は長らく Excel で仕様書や設計書、テストケースなどを作ってきた。現在も、何か情報を整理しようと思うと、とりあえず Excel に書き始めている。とある現場では「Excel マスター」なる称号をもらったりしたし、Excel の細かな仕様は技術ブログ Corredor でも度々紹介してきたとおり、そこら辺のニホンノエスイーよりは熟知した上で使っていると自負している。 しかし、ネットの界隈では「まだ Excel で仕様書書いてんの？」という風潮が強く、「Excel で仕様書のフォーマット作ってみました！」みたいな記事にネガティブコメントがわんさか付き、「Docker を使って PlantUML 環境を構築！」みたいな記事が高評価を得ていたりする。自分も技術オタクなので、イマドキのツールが簡単便利に色んなことができるのを見ると、いいね！と思う
神奈川県の行政文書を保存したハードディスクドライブ（HDD）がインターネットオークションで転売された問題で、HDDの処理を担当した廃棄業者ブロードリンク（東京・中央）が12月9日に会見を開いた。 同社の調査で、他のHDDにも転売の恐れがあることが判明した。榊彰一社長は「流出した原因は管理体制にあった」とし、原因究明や再発防止が完了した時点で辞任する考えを示した。「前代未聞」ともいわれるHDD転売はなぜ見過ごされたのか。会見で注目された3点を解説する。 まず経緯を整理しよう。発端は11月26日、神奈川県に「県の情報と思われる電子データが入っているので確認してほしい」との情報提供があった。情報提供元の男性は、オークションサイトの「ヤフーオークション」で落札した9本のHDDについて、市販のデータ復元ソフトを使って一部のデータを復元していた。県が翌27日、個人情報や県の重要情報を含む内部資料である
[JavaScript] "10" + 1 は "101" だが "10" - 1 は 9 を理解する - Qiita
そういうものなんです！仕様です！（完） だけではあれなので、仕様をちゃんとみてみる 加算演算子（＋） 12.8.3 The Addition Operator ( + )をみていきます。 NOTE The addition operator either performs string concatenation or numeric addition. 12.8.3.1 Runtime Semantics: Evaluation AdditiveExpression:AdditiveExpression+MultiplicativeExpression 加算演算子は文字の連結と数値の加算を担うことがわかりました。 次に処理の流れをみていきましょう。 Let lref be the result of evaluating AdditiveExpression. Let lval be ?
![[JavaScript] "10" + 1 は "101" だが "10" - 1 は 9 を理解する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/af24213434f5729e5f8e5bb7bd3bc7d2b42de4e6/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZ0eHQ9JTVCSmF2YVNjcmlwdCU1RCUyMCUyMjEwJTIyJTIwJTJCJTIwMSUyMCVFMyU4MSVBRiUyMCUyMjEwMSUyMiUyMCVFMyU4MSVBMCVFMyU4MSU4QyUyMCUyMjEwJTIyJTIwLSUyMDElMjAlRTMlODElQUYlMjA5JTIwJTIwJUUzJTgyJTkyJUU3JTkwJTg2JUU4JUE3JUEzJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03NTAyZmZhOTc3N2YzMDQ0MDQ5NTY3MWVhMTk5MmQ5Yg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa296enp6JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02OTI0YmRjOTk3YjFlYzI1M2Y4MmI5ZmIxZjRlNTRmMw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D76079ef425f02bd65573d2359ff5196f)
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方｜kakomoe
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方 💡このnoteはなに？ プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです 💡誰のためのnote？ プロダクト開発に必要なドキュメントについて日々心を悩ませている人 ドキュメントの話に着地をつけたい 誰かが言い出すアレ今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。 プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。 そしてそれぞれの言葉には単一の定義があるわけではない。 そもそもドキュメン
【ゲームプランナー基礎講座】「仕様書の書き方」
はじめまして！ 開発一部プランナーの宮城です！ 今回は、先日社内で行われた、ゲームプランナー基礎講座「仕様書の書き方」の内容とその様子をご紹介します！ ※追記（2018/8/8） 「企画書を作る工程やポイント」の記事も追加しましたので、こちらもぜひご覧ください。 ゲームプランナー基礎講座とは？ ゲームプランナー基礎講座とは、社内のまだ経験の浅い若手プランナーが集い、スキルアップを目指して、基礎的な知識や技術を身につけることを目的とした研修会です。 開催は不定期で、今回が2回目の開催となります。 実は何を隠そう、これを書いている宮城も、別の職種からプランナーに転向したばかりで、日々「もっとレベルアップしていきたい！」という想いを持っていたので、渡りに船とばかりに喜び勇んで参加してきました！ ゲームプランナーとは？ 勉強会の紹介に入る前にまず、「ゲームプランナーって、なんだろう？」という点から
はじめに 皆さん、仕様書のレビューは実施していますか？テストで不具合を見つけて修正することも大事ですが、そもそも仕様書の段階で問題があるのであれば、レビューでその問題を検出して修正しておきたいですよね。 一口に「レビュー」といっても、様々なやり方が知られています。時と場合によって効果的なレビューの方法は変わるとは思いますが、まずは色々なレビューの方法を知っていることで、どんなやり方でレビューしたら良いか考えるきっかけになるはずです。ということで、この記事では、色々なレビュー技法（Reviewing techniques）について解説したいと思います。 この記事で扱う「レビュー」の範囲 仕様書（要求仕様書、要件定義書、機能仕様書など）のレビューを想定して記載します。コードレビューについては対象としていませんのでご注意ください。ただし、記載しているレビュー技法が、それ以外の文書やコードレビュー
機能仕様書の書き方 - Qiita
今回は機能仕様書について述べていこうと思う。 テンプレート 会社の機能仕様書は見せられないが、機能仕様書のテンプレートはネット上に沢山あるのでそちらを参照していただきたい。例えば以下のリンクが参考になりそうだ。 https://biz.trans-suite.jp/9158 ポイント 機能仕様書は「ユーザから見た仕様」について書く。プログラムなど詳細については次工程「詳細設計書」で書く。 記入事項 大きく分けて以下の8つの項目がある。 1. 表紙 2. 改訂履歴 3. 目次 4. 用語説明 5. システム 6. 機能策定方針 7. 機能概要 8. 機能仕様 9. 非機能仕様 10.データ仕様 それぞれの項目ごとに説明していく。 表紙 表紙には「○○システム機能仕様書 ver1.0」と「所属部署や名前等の出どころ」を書く。 改訂履歴 改訂履歴には「日付」「版（ver）」「改訂者の名前」「内容
『４人同時対戦可能ダメージ排除型バトルロイヤル格闘』後の大乱闘スマッシュブラザーズの企画書が投稿されています。この段階から、一風変わった格闘ゲームを作りたかったというのが伝わってきます。そしてこれが名作の始まり。
パラメーターを【】でくくる 【プログラム・テクニカル】
複雑なゲームを調整するため､多くの人がパラメーターをいじります｡ いつ誰が見ても､何のパラメーターであるのかが判るように｡ 私はこういう工夫をしています｡
外部仕様書のテンプレート
背景 仕事の中でシステムやソフトウェアの開発を行う際、外部仕様書を書く機会が増えてきたので、外部仕様書に必要な項目をまとめた。 記事の目的外部仕様書を効率的に作成するため、外部仕様書のテンプレートを作成する 外部仕様書とは外部仕様書は、基本設計書もとも呼ばれている。外部仕様書の目的は、要件定義の結果を受けて、具体的なシステム構成や機能に記載した文書である。 外部仕様書の全体構成外部仕様書の全体構成は、下記の通りである。 処理設計 システム化の背景・目的 システム化が必要な背景(理由)と目的を簡潔に記載する。 (オプション)システム化の対象範囲 対象処理のシステム化範囲を明確に記載する。新規の場合は不要。 システム機能要件一覧 システムの機能要件について、一覧で記載する。 分類 機能名 利用者 機能概要 重要度 優先度 処理フロー システム全体の処理の流れについて記載する。 UML図のアクテ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
プログラマーから見たPDFファイル | アンテナハウス PDF資料室
AWS テクニカルサポートで得た暗黙知をまとめてみた | DevelopersIO
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
https://twitter.com/developer_quant/status/1551910433858400256
パフォーマンスを改善するには仕様変更が1番はやい
OSS開発wikiツールのGROWI | 快適な情報共有を、全ての人へ
エンジニアリングの時間を生み出すドキュメンテーション術 - エムスリーテックブログ
ゲームの仕様書を書こうまとめ
AIが「理解」するから、API仕様書のコピペでアプリができあがるローコード開発環境「Flowise」を試す【イニシャルB】
HTML, CSS, JavaScriptの標準の仕様書はどこにあるのか
基本設計における成果物一覧と書き方（基本設計書サンプルあり） | 若手エンジニアの羅針盤
Understanding the ECMAScript spec, part 1 · V8
書かれて、レビューされて、合意されたものが”決まったこと” - Magnolia Tech
Excel で設計書作るのそんなに悪いことか？ - Neo's World
神奈川HDD転売、元社員は3904個を販売 企業・官公庁に飛び火も
知らないようでやっぱり知らない仕様書のレビュー技法 - Qiita
大乱闘スマッシュブラザーズの企画書が面白い、名作はここから始まった！
tojun.hatenablog.com
do10info.com
mixi.jp
booksch.hatenablog.com
bukkenfan.jp
plaza.rakuten.co.jp/eigohasshin