システム構成図、ER図、フローチャートなどを描くときに無料で使える作図ツールやドローイングツールまとめ。2024
システム構成図、ER図、フローチャートなどを描くときに無料で使える作図ツールやドローイングツールまとめ。2024 システムを開発する際には、インフラを構築するためのシステム構成図やアプリケーションの仕様を検討するためのさまざまなUML関連のダイアグラム、フローチャートやデータベース設計におけるER図など、さまざまな作図をする場面があります。 これらの作図作業を支援してくれるツールは多数存在しますが、ここでは無料で使えるツール、あるいは無料プランが利用できる有料サービスなどをまとめました。 draw.io 無料で利用できるドローイングツールの代表的な存在がdraw.ioでしょう。ユーザー登録すら不要ですぐに使い始めることができて、作図したデータはGoogle DriveやOneDrive、Dropbox、GitHubやGitLab、ローカルデイバイスなどに保存できます。 GitHubにサーバ
サイバーセキュリティ情報インプット集 第1.0版 - Qiita
定期的に更新・追加していきます。 セキュリティガイドライン、フレームワーク集 サイバーセキュリティガイドラインやフレームワーク等を参照することは、自組織でのセキュリティステータスを把握し、実際にセキュリティ施策を打つうえで非常に重要となります。 ただ、これらの文書の要件を満たすような施策を実施するためには、 1. 自組織が適用（組織・技術的に対策）したい各種ガイドラインやフレームワーク等を選定する 2. これら文書における抽象的な要件を具体的な要件へ落とし込む 3. 具体的な要件を満たすために最適なセキュリティ策を実施する のような流れを踏む必要があります。 2、3についてはセキュリティ策や技術動向に精通したセキュリティ専門家による対応が求められますが、1については自組織が目指す目的に依存するため専門家の手を借りずともある程度は対応することができます。 また、業界や技術等の軸で存在感のある
アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾 剛
アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ
2022年に公開されたセキュリティ関連文書まとめ - FFRIエンジニアブログ
はじめに セキュリティサービス部セキュリティエンジニアの松原です。 昨年、セキュリティ関連の文書をまとめた記事を公開しました。サイバー空間をめぐる脅威の情勢は、毎年目まぐるしく変化しています。 そこで本記事では、最新のセキュリティ動向として 2022 年に、以下の 4 つの政府機関と 12 つのセキュリティ関連団体等が公開した、セキュリティ関連の文書についてまとめました。 政府機関 内閣サイバーセキュリティセンター (NISC) 警察庁 サイバー警察局 デジタル庁 総務省 サイバーセキュリティ統括官 セキュリティ関連団体 NICT サイバーセキュリティ研究室 CRYPTREC JPCERT コーディネーションセンター (JPCERT/CC) 情報処理推進機構 (IPA) 日本ネットワークセキュリティ協会 (JNSA) フィッシング対策協議会 セーファーインターネット協会 (SIA) 日本ク
ER図の作図について、 Draw.io, PlantUML, Mermaid を比較してみる。（VSCode拡張機能など） - Qiita
※ 参考記事「PlantUML を VSCode で利用したいけど、プレビューが表示されずエラーが出る」 参考（PlantUML 導入後の編集中画面） 2-2. ER図 今回作成したER図 Qiita記事でも、コードブロック内でPlantUMLの構文がそのまま使えます。（このER図は、Qiitaのコードブロックで表示させています） 今回作成したER図のPlantUMLの表記 @startuml yonde ' hide the spot hide circle ' avoid problems with angled crows feet skinparam linetype ortho entity "families" as families { id -- name nickname introduction created_at updated_at } entity "users
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
データベースのテーブル定義の仕様書を自動生成しよう | CyberAgent Developers Blog
AI事業本部 DX本部の黒崎(@kuro_m88)です。 社外(取引先など)向けに作成する仕様書を自動生成する取り組みを試しているので、アイデアを紹介します。今回はSnowflakeで構築されているデータ分析基盤のテーブル定義の仕様書を例に紹介していきます。ツールはGoを使って開発しました。 仕様書の運用コストを減らしたい DX本部でのプロジェクトは、開発環境を社内向けに別途用意することが大半なので、取引先に許可を取らないと何かを試すことができないということは今のところほとんどありません。 そのため、実際の開発フローとしては詳細な仕様書を書き起こしてから実装することはあまりなく、大まかな方針を決めてから軽く実装してみて、うまくいきそうであればそれを仕様としてまとめつつ実装することが多いです。 データベースのテーブル定義であれば、それらの定義はGitHub上で管理されており、リリース時に自動
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
プロダクト開発でドキュメントを書かないとどうなるか
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
論文執筆/プレゼン資料作成時の参考資料 - Qiita
はじめに 本記事では，論文執筆やプレゼン発表の際にnegocia社内で参考にしている資料を @aiueola さんと一緒にまとめました．もし何かの参考になれば幸いです． (また，もし関連リソースをご存知の方がいらっしゃれば，ぜひ本記事のコメント欄にご紹介いただけると嬉しいです．内容を確認の上，追記させていただきます．) negocia株式会社について negocia株式会社では，「うれしい広告」の実現をミッションとして，機械学習，数理最適化の技術を活かしたオンライン広告向けのSaaSを開発するメンバーを募集しています．この記事を読んで興味を持たれた方がいらっしゃいましたら，こちらのリンク よりご応募ください．ご連絡お待ちしています． 目次 研究事始め/論文サーベイ テクニカルライティング/論文執筆/レビュー テクニカルライティング全般 論文執筆 レビュー/リバッタル/ポジションペーパー プ
伝わる文章作成の基本を学ぶための記事・学習コンテンツのまとめ - Qiita
短いメッセージを書くことはできても、まとまった文章を書くのに苦労している人は多いのではないでしょうか。 この記事では、まとまった文章を作るときの技術を学ぶことができる記事や学習コンテンツを紹介します。新人エンジニア向けです。 文章の「型」を学ぶ まとまった文章を書くには、「型」が必要です。頻繁に使うものは、「型」を覚えてしまいしましょう。 バグレポートの書き方を学ぶ エンジニアとして書く文章の代表例が、バグレポートです。 バグレポートでありがちな失敗として「何が問題だと思っているのか」が伝わらないというものがあります。 これを防ぐために、「期待する結果」「実際の結果」「再現手順」の3つを必ず書くようにしましょう。 質問の書き方を学ぶ エンジニアが扱う技術は、最初はわからないことだらけです。 それを解決するために、質問の文章を作成する技術が必要となります。 概ね下記の4つの情報があれば、良い
ついに、Webアプリでの帳票印刷のベストプラクティスを編み出しました
この記事で紹介した手順をライブラリ化して公開しました🎉 こちらの別記事 で使い方など詳しくご紹介していますので、ぜひご参照ください！ 2024/05/07 追記 最新の登壇スライドバージョンはこちらです。 登壇時の様子がYouTubeに上がっているのでよろしければあわせてご覧ください。 はじめに 言い切りタイトルすみません 僕を含む一定数の人にとって現時点でのベストプラクティスとなりうる手法という意味で紹介しています 極めてシビアな帳票出力の世界にいる人から見ると使い物にならない内容かもしれないと思います 帳票印刷の世界では SVF というサービスが有名らしいです。が、こういった外部サービスは使わずに自力で実装するというのがこの記事の前提です 動的に明細行の数が増減する連票はこの記事の解説では考慮していませんが、追加で実装するのはそれほど難しくないということは読んでいただければ分かるかな
プログラムの「アーキテクチャに関するドキュメント」は面倒でも書くべき、ではどのように書くべきか？
開発プロジェクトに新しく加わった時は、まずプロジェクトの理解が第一。しかし、全体像を把握できるようなドキュメントがなく、コードから断片的な情報をかき集めるしかない場合もあります。新参の開発者がスムーズにプロジェクトを理解できるよう、大規模なプロジェクトでは「プロジェクト全体のアーキテクチャ」を示した「ARCHITECTURE.md」を添えた方がよいと、エンジニアのAleksey Kladov氏が指摘しています。 ARCHITECTURE.md https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html Kladov氏はオープンソースプロジェクトの開発に携わる中で、「プロジェクトのアーキテクチャに対する知識量」によって開発スピードに大きな差が生じると気づいたとのこと。アーキテクチャに関する知識がない開発者にとって、大量のコードは「バラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大学生に『書くこと』の授業をしたときに 引き合いに出した本 / books on writing for students
ドキュメントを改善するためのはじめの一歩
GitHub - meti-dx-team/METI-Digital-Tools
