マニュアル作成はじめの一歩。「因数分解ツリー」で業務の洗い出しをはじめよう | ZUU online
マニュアル作成の準備は、マニュアル作成の5W1Hの「What」で登場した「洗い出し〜対象業務の選定〜改善」の3段階を、さらに7つのステップに分けて下ごしらえします。 洗い出し ツリーで業務を俯瞰して見える化します。ツリーは周囲とすり合わせた後、リスト（表）にして情報を追加します。 対象業務の選定 洗い出した業務のなかから、マニュアル化する業務を選びます。 改善 マニュアル化する業務のプロセスを分解して、改善の視点で見直し、マニュアルの骨組みをつくります。 ステップ1 ツリーで業務を見える化する ツリーで全体を俯瞰する 準備の第1段階「洗い出し」はツリーの作成からはじめます。洗い出しの目的は、「業務の見える化」の先にある「マニュアル作成」の効果を高めることです。 ツリーは、樹木（ツリー）の形の図表です。モノやコトを、木が枝分かれするように分解して表わします。 ここでのツリーは、論理思考でおな
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
社内のドキュメンテーションの取り組みと、Kitenのご紹介 - Pepabo Tech Portal
はじめに 技術部の @june29 と申します。最近の趣味は「お散歩」で、よく晴れた休日には妻といっしょに2時間くらい歩き回ったりしています。この記事では、わたしが2020年から力を入れて取り組んでいる社内におけるドキュメンテーションの活動の一部を紹介したいと思います。 問題意識 もともと、ペパボで働く人々には「書く」という行為が定着しています。現在利用中のサービスを見渡してみると、GitHub、Slack、Google Docs、Scrapbox、Notionなどがあり、常に積極的な読み書きが行われています。 しかし、ドキュメンテーションという観点から見て、すべてが理想的にうまくいっているとは言えない状況であるとも思っていました。具体的には、下記のような課題があると感じていました。 書く場所が何種類もあり、どこになにが書かれているかがわかりにくい 場所ごとにアクセス制限が行われており、ど
ドキュメント作成ツールの決定版！Markdown + React の体験を Docusaurus で
What is Docusaurus ? Build optimized websites quickly, focus on your content - Docusaurus Keytar Docusaurus とは "最適化されたウェブサイトを迅速に構築し，本質に集中させる" というスローガンのもと Facebook 傘下のチームが開発している 静的サイトジェネレータです．特徴として，次の五つが挙げられています． Powered by Markdown => MDX Built Using React Content Search Ready for Translations Document Versioning ※ただし，まだまだアルファなので４，５については工事が進行中 追記：2021 年 5 月 12 日に β 版がリリースされ，2022/02/23 現在では beta.15
Ruby on Railsを使った開発で参照してもよいドキュメント - Qiita
記事中のURLや内容、特にRailsやRubyのバージョンについて古くなっていることに気づいた方はぜひ編集リクエストください。 この記事はOkinawa.rbのAdventCalendar 5日目の記事です。 YassLabの業務時間中にQiita:Teamに書き溜めたものを編集して公開します。 4日目は @siman さんの「今年作った gem の紹介 (2017)」でした。 明日は @fullkawa さんのFinOpsのはなしです。 背景 人数が増えたり参加プロジェクトが増えるにつれ以下のような変化がおきました。 同じソフトウェアのさまざまなバージョンを扱うようになった コードレビューをする人・される人が増えた 同じソフトウェアでもバージョンによってAPIや使い方が異なる場合があります。 また、人によっては参考にする情報源がバラバラになってしまい、ソフトウェアの開発者が提供しているド
Spring oneを経験してよりよいwebサービスを作るために僕らが取り組むこと(document編)(SpringRESTDocs)
Spring oneを経験してよりよいwebサービスを作るために僕らが取り組むこと(document編)(SpringRESTDocs) SpringOneの中からDocumentingのセッションをpickupし、Spring REST Docsの導入方法 Spring REST Docsを利用し、 どのように鮮度の高いドキュメントが作成できるか どのようなメリットがあるか について説明しています。 1.Title 2.Introduction 3.Agenda 4.Title 5.Title 6.良いドキュメンテーションの仕組みとは何か 7-9.Springを利用しているアプリではどのような仕組みがあるか(Swagger) 10.良いドキュメンテーションの仕組みとは何か(2) 11-15.Springに適したドキュメンテーションの仕組み 16-20.Spring REST Docs
Swift Documentation
Written by Nate Cook & Mattt July 11th, 2018 (revised) This article has been translated into: 中文 Code structure and organization is a matter of pride for developers. Clear and consistent code signifies clear and consistent thought. Even though the compiler lacks a discerning palate when it comes to naming, whitespace, or documentation, it makes all the difference for human collaborators. This week
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React
GitHub - k1LoW/ndiag: ndiag is a high-level architecture diagramming/documentation tool.
Documentation as Codeで継続的なドキュメント運用を実現する / July Tech Festa 2021 winter