Future Tech Blog
フューチャー技術ブログ

ドキュメント タグ

累計
  • 20
    投稿
  • 12
    著者数
  • 2937
    総シェア数
  • 182
    X
  • 4
    Facebook
  • 1871
    はてブ
  • 880
    Pocket
直近1年
  • 2
    投稿
  • 2
    著者数

月別 投稿数の推移

よく読まれている記事

AIネイティブ時代の設計書を考える
2026.06♡197
設計ドキュメント腐る問題、Git管理で運用してみた結果
2023.11♡666
Tailwind CSSのドキュメントから見えてくる使い方とCSS設計のヒント
2025.03♡92
初めての運用引き継ぎ
2025.05♡84
markdownlintで設計書の品質を高める
2023.04♡293
実践Drawio
2020.01♡527

よく使われるカテゴリ

新着記事

AIネイティブ時代の設計書を考える

Goならわかるシステムプログラミングなどのウェブ連載や書籍化でお世話になりまくりの鹿野さんのブログ記事が話題となっています。これを読んで、今までモヤモヤ思っていたことに光明が射してきたので、ちょっと実験してみました。

Terraformに関してAIに聞いてみて初心者目線で疑問点を公式ドキュメントで解消してみた

AIって便利ですよね。新しい分野の学習にAIは欠かせなくなりました。ただAIはもっともらしい嘘をつく可能性もあり、信頼できる一次情報（公式ドキュメント）に当たることは重要だと思います。

初めての運用引き継ぎ

初めてシステムの運用引き継ぎを経験しました。その中で得た知見や工夫した点を、共有します。システムの運用を引き継ぐ立場の方はもちろん、日常的にシステム開発に携わっている方にも、参考になる点があれば幸いです。

Tailwind CSSのドキュメントから見えてくる使い方とCSS設計のヒント

CSSをわかりやすくメンテナンス性高く書くというのは長い間試行錯誤され続けてきました。命名規則でがんばる、SCSSのようなプリプロセッサを使う、CSS in JSなどいろいろな仕組みがかつて作られたりしてきましたが...

「言語化」を考える

フューチャーではコンサルティング業の例に漏れず、対顧客／社内を問わず資料作成の機会が多くあります（ex. 議事録・顧客向け説明提案資料 etc.）。また、当社の取り組みとして評価の一環として社員全員が年末にプレゼンテーションを行う機会があり、誰もがドキュメントの作成に頭を悩ませることになります。

Software Design 2024年10月号 受託開発における設計ドキュメントの課題と解決案 作成・管理のヒントを探るへの寄稿

2024年9月18日に発売された、Software Design 2024年10月号の第1特集「再考 設計ドキュメントの課題　二重管理しない，陳腐化させない」の「第1章：受託開発における設計ドキュメントの課題と解決案　作成・管理のヒントを探る」に寄稿させていただきました。

ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT に登壇しました

Findyさん主催のドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LTに「設計ドキュメント腐る問題、Git管理で運用してみた本当のところ」というタイトルで登壇しました

設計ドキュメント腐る問題、Git管理で運用してみた結果

設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします

markdownlintで設計書の品質を高める

Markdownで設計書を充実させようとすればするほど、設計書間やメンバー間のちょっとした揺れで、本質的なレビューがしにくく感じるようになりました。そこでMarkdownのLintツールを導入するモチベーションが高まりました。

Recoilドキュメント入門

RecoilはFacebookのMeta社製のReact用状態管理ライブラリです。この分野はFacebook自体がFluxという概念を発表してから、さまざまなライブラリが開発されてきました。特に広く利用されたのがReduxです。

Go 1.19リリース連載始まります GoDoc/ツール周りのアップデート

Go 1.18のジェネリクス導入の大規模リリースと比べると比較的小さな1.19ですが、それでもさまざまな変更があります。今回ももちろん、恒例行事になりつつある、このテックブログでリリース連載をやります。まずは、GoDocと、その他ツール周りのアップデートの紹介です。

技術情報の調べ方

業務を進める上では日々多くの技術情報を調べる必要がありますが、無策に調べると時間を浪費したりイマイチな解決策を採用してしまう可能性があります。そこで、本稿では普段私がやっている方法を中心に、調べる上でのポイントを紹介します。

GitHub上のChangeLogをCircleCIから自動生成する

リリースした際に、機能強化や不具合修正の内容などをユーザーや他開発メンバーに示すために、ChangeLogを作成されている方も多いと思います。読者の皆さんはどのようにChangeLogを作成されていますか？

ユーザーストーリーマッピングで始める要求整理

ユーザーストーリーマップがあると、全体像の認識をチーム全体で共有できて便利です。ユーザーストーリーマップは視覚的にわかりやすく、特殊な構造もしていないため共通理解しやすいことがポイントです。また、ユーザーストーリーマップはこれから何を作ろうかという要求定義の段階でも有効に感じます。この記事では要求の整理と理解のためにユーザーストーリーマップを使ってみたときの気がついた点や振り返りをまとめました

GoにおけるAPIドキュメントベースのWeb API開発について登壇しました

TIG 多賀です。2021/3/19 を開催しました。 私は、Goの Web API 開発にて、API ドキュメントベースで開発していることについて話しました。なお、その他の登壇者の資料は こちら に公開済みですので、興味があれば参照ください。

CircleCIでMarkdownのリンク切れを自動検知する

私のチームでは、「システムの設計情報」や「実装に関わる業務知識」などを、README.md に整理して GitHub 管理しています。設計資料や業務系のドキュメントが蓄積され、何度も更新され続けることに伴い、「あれ、この資料のリンクが切れてる。オリジナルのファイルはどこだっけ？」と探す機会が増えてきました。本来ならば PullRequest のレビュー時に気付くべきですが、ファイル名のちょっとしたスペルミスや資料パスの変更などだと、目視でのチェックには限界があります。

初めてのOSSコミュニティ活動〜ドキュメント翻訳やってみた。カンファレンススタッフもやってみた。〜

２０１７年新卒入社の永井です。小売流通系のPJに所属しており、前回はVue.jsに関する記事を書きました。2020年はコロナ禍ということもあり、夏休みを取っても予定がないという人も多いのではないでしょうか。そんな時間があるときには、普段仕事や趣味でお世話になっているOSSやOSSコミュニティへの貢献をするといった過ごし方はいかがでしょうか。でもいざgithubを開いて、イシューを覗いてみると、どうも自分には出来なさそうな難しいものばかりに見えてなかなかハードル高いですよね。

Go Tips連載4: GoDocの読み方

新しいプログラミング言語を学ぶときは、まず、情報の取得の仕方を覚えておくと学習効率が上がります。検索して、日本語で誰かが解説している二次情報を探すのもいいのですが、古くなって使えなかったり、人気のある情報に偏ってしまって、ちょっと混み入った話になると情報が見つからなくなったりしがちです。多少素っ気なく感じるかもしれませんが、一次情報を読み解く方法を知っておくと良いでしょう。本家が作ったものではなくても網羅的に、リファレンスとなる心意気で書かれたものもたまにあります。

チームで機能設計するためのPlantUML標準化

現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。

実践Drawio

もともとはMicrosof VisioやExcelなどを使って作成していた図形（ネットワーク図、各種シーケンス、ERD..etc）ですが、ファイルストレージがクラウド（Google Driveなど）に移ることで、そのまま編集したい欲求が世の中で増しているように思います。その場合の有効なツールとしてdraw.ioを利用するケースが増えてきたと感じます。そこで当社で蓄積したナレッジを文章化します。