タグ

ドキュメントに関するs_ryuukiのブックマーク (327)

  • リッチテキストエディター(RTE)のJSライブラリ色々試してみた

    リッチテキストエディタ(RTE)って? リッチテキストエディタ(以下RTE)とは、文字を入力できるだけでなく、文字に装飾を加えたり、段落を設定できたりと複雑な機能を持つエディタのことです。 弊社プロダクトであるkintone内にも以下のようなエディタが存在します。 また、似たものを指すWYSIWYG(読み方:ウィジウィグ)という用語もありますが、これはWhat You See Is What You Get(見たままが得られる)の略であり、編集時と出力時の見た目が同じエディタのことを指します。 Zennやesaのように、Markdown記法で編集したものが変換されて表示されるようなエディタは含みません。 このようにWYSIWYGはRTEより狭義の意味になっています。 WYSIWYGエディタ(Google Docs) WYSIWYGではないエディタ(esa) 独自データモデル VS DOMツ

    リッチテキストエディター(RTE)のJSライブラリ色々試してみた
  • 情報の見つけやすさを追求する - 社内ドキュメンテーションの階層整理術 - KAKEHASHI Tech Blog

    カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回はチームに配属されて数ヶ月の私が、いかにして社内ドキュメンテーションの階層構造を整理し、情報の検索性を向上させたかについてお話します。 はじめに この記事の想定読者 課題意識 メンバーへの共有と相談 社外事例の調査 esa の階層整理 第 1・第 2 階層の整理 ストック情報とフロー情報を意識した階層の整理 esa の機能をフル活用する 効果や今後について はじめに カケハシでは全社的にドキュメンテーションツールとして esa - 自律的なチームのための情報共有サービス を利用しています。それぞれのチームやプロダクトごとに階層を切ってドキュメントを書いています。 プラットフォームチームでは認証基盤などの社内プラットフォームシステムを開発しているため、自チームが運用する各種

    情報の見つけやすさを追求する - 社内ドキュメンテーションの階層整理術 - KAKEHASHI Tech Blog
  • 簡単なプロンプトで質の高い長編小説を量産する方法の紹介|IT navi

    2.2種類のプロンプトこのプロンプトをClaude 3.5 Sonnetで実行すると、以下のような2種類のプロンプトが生成されます。 (1) アウトライン作成プロンプト以下の要素を含むSF小説のアウトラインを作成してください: 1. 舞台設定: - 時代と場所を具体的に設定し、その世界の科学技術レベルを説明してください。 - その世界特有の社会システムや文化的要素を3つ以上挙げてください。 2. 登場人物: - 主人公を含む5人以上の重要な登場人物を設定してください。 - 各キャラクターの背景、性格、動機、特殊能力(もしあれば)を簡潔に説明してください。 - キャラクター間の関係性を示してください。 3. プロット: - 物語の核となる科学的概念や発見を明確にしてください。 - 5つ以上の主要な出来事や転換点を含む物語の流れを示してください。 - 読者の感情を揺さぶる要素を少なくとも3つ含

    簡単なプロンプトで質の高い長編小説を量産する方法の紹介|IT navi
  • 長く読まれるブログを書く

    SocialDog でエンジニアチームのブログ編集長を担当している上田です。 私たちは最近ブログ発信に力を入れているのですが、『ブログをどう書けばいいのかわからない』という声がちらほらありました。 そこで今回は私の経験則[1]をベースに、ブログの 書き方のプロセス や 長く読まれるために心がけていること をご紹介します。 ✍️この記事で書くこと 主に次の2つのことを書きます。 執筆のプロセス 記事を書く上で 迷いを減らすためのプロセス について書きます。 寿命の長い記事の書き方 私がブログ記事を書いてきたなかで、 数年にわたって Google の検索順位で 10 位以内 をキープする記事がいくつかありました。[2] また前職でも、 会社ブログ全体の流入数の3割が私の1つの記事だった 経験があります。 ただ、毎回すべての記事が一定読まれるようになったわけではなく、継続的に読まれる記事にはいく

    長く読まれるブログを書く
  • ドキュメンテーションを文化にする〜コミュニケーションの「ハブ」作りに取り組んだ4年間~ - MonotaRO Tech Blog

    はじめに こんにちは。プラットフォームエンジニアリング部門の池田(@progrhyme)です。 この記事では、モノタロウのテック系の部門で筆者が取り組んできた「ドキュメンテーションプロジェクト」について、下の目次の流れに沿って紹介していきます。 【目次】 はじめに 「ドキュメンテーションプロジェクト」とは プロジェクト発足の背景 ねらい(まとめ) 何をやったか ドキュメンテーションの促進 Confluence → Googleドキュメントへの移行 その結果どうだったか 上手く行ったこと 上手く行かなかったこと まとめ 「ドキュメンテーションプロジェクト」とは 初めに、プロジェクトの概要について簡単に説明します。 このプロジェクトのミッション(=目標)は主に以下の2つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ

    ドキュメンテーションを文化にする〜コミュニケーションの「ハブ」作りに取り組んだ4年間~ - MonotaRO Tech Blog
  • ユーザーが自己解決できるヘルプページを書くポイント - inSmartBank

    こんにちは。カスタマーサポート部のnyancoです。 お問い合わせを減らすためにできることはたくさんありますが、日は「ユーザー自身で自己解決できるための手段の一つ」である「ヘルプページ」はどう作るべきか?スマートバンクで考えている方針についてブログを書こうと思います。 前提:ユーザーに自己解決を促したい ユーザーが困っていることはなるべく早く解決してもらいたいというのがカスタマーサポートの人であればみなさん思うところではないでしょうか。そこでカスタマーサポートではよく「初回返信時間」を短縮するためにどうするか?を考えることが多いと思います。 お問い合わせ返信を行う人数は限られているので、そもそもお問い合わせをせずとも自己解決ができると待つ時間もなくすぐに疑問を解消できます。自己解決を促すような仕組みはユーザーにとってもサービス提供側としても嬉しいはずです。 ※初回返信時間とは、ユーザーが

    ユーザーが自己解決できるヘルプページを書くポイント - inSmartBank
  • Permanent Agility

    Scrum Fest Kanazawa 2024 https://www.scrumfestkanazawa.org

    Permanent Agility
  • Google Docs、Markdown形式でのドキュメントのエクスポート、インポートなど可能に

    Googleは、Google Docsの新機能としてドキュメントをMarkdown形式でエクスポートする機能やMarkdown形式のファイルをドキュメントとして読み込む機能などを発表しました。 具体的には以下の4つの機能が利用可能になります。 Markdown形式のテキストをGoogle Docsのドキュメントに変換してペースト Google DocsのドキュメントをMarkdown形式のテキストとしてコピー Google DocsのドキュメントをMarkdown形式のテキストとしてエクスポート Markdown形式のテキストをGoogle Docsのドキュメントとしてインポート 例えば、Google DocsのドキュメントをMarkdown形式のテキストとしてエクスポートする場合には、下記の「ダウンロード」メニューからMarkdowsn形式を選択することになります(下記の画像は現時点での

    Google Docs、Markdown形式でのドキュメントのエクスポート、インポートなど可能に
  • ローカルLLMに小説を書いてもらう v2|Kohya S.

    この時はそれぞれ単独のプロンプトで小説家と編集者を演じさせましたが、今回はもうすこしシステマチックに、段階を踏んで小説を生成させてみます。 プロンプトの検討等にはkgmkm氏のリポジトリや記事を参考にさせていただきました。この場を借りてお礼申し上げます。 仕組みを相談するのにClaude (3.5 Sonnet)とやり取りをしていましたので、この記事の草稿も書いてもらいました。所々、なんとなく冗長だったり文体が違ったりしますが、面倒なのでそのままにしてあります(すみません)。 生成スクリプト生成スクリプトとプロンプト定義はgistに置きました。 https://gist.github.com/kohya-ss/68d41a9720bfbdfd87869ec970142f4b 概要近年、大規模言語モデル(LLM)の発展により、AIによる文章生成の可能性が大きく広がっています。今回はローカル環

    ローカルLLMに小説を書いてもらう v2|Kohya S.
  • ドキュメントを書かないことは「負債を生む」ということ - Qiita

    記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう! はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から

    ドキュメントを書かないことは「負債を生む」ということ - Qiita
  • 網羅的なPRDやDesign Docを書かなくなった - kosui

    2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー

    網羅的なPRDやDesign Docを書かなくなった - kosui
  • 無料で使える最高のAIノート『NotebookLM』使い方と活用事例|AI-Bridge Lab こば

    こんにちは!最近、ChatGPTと話しすぎてAI風の口調がうつってきたAI-Bridge Labのこばです!👋 今回の記事はGoogleのサービス『NotebookLM』(ノートブックLM)について 1.NotebookLMの概要 2.使い方 3.具体例として過去のnote記事を全部読ませた結果どうなったか この3点を分かりやすくご紹介します! 先に結論だけお伝えするとかなり実用性が高くオススメのツールです! そしてこの記事を読んで頂ければご自身での活用法が想像できるようになると思いますので、ぜひ最後まで読んで頂けますと幸いです! 1.NotebookLMの概要公式サイト:https://notebooklm.google.com/ NotebookLMは、Googleが提供する生成AIサービスで、ユーザーのメモ書きやアップロードした資料を基に情報を整理し、質問に答えることができる革新的

    無料で使える最高のAIノート『NotebookLM』使い方と活用事例|AI-Bridge Lab こば
  • 組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog

    何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった&話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念:ADR ADRの実践:その1 何を書くか ADRの実践:その2 どこに書くか ADRの実践:その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ

    組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog
  • LLMにまつわる"評価"を整理する

    「LLMの評価」というフレーズを見て、どんなことを思い浮かべるでしょうか? おそらく大半はLLMモデル自体の評価のことを思い浮かべると思います。新しいモデルが出てきた時に𝕏で見かける「GPT-4o のMMLUベンチマークは89%!」みたいなアレ。 ですが、プロダクト開発にLLMを使っている人の間では、プロンプト等が十分な品質を出しているかの確認などにも評価という言葉を使っていることは多いのではないかと思います。 うまい具合に後者を区別するためにいい感じの呼び名を付与したい気持ちがあるのですが、英語圏での例を見てみるとシンプルに"Evals"と呼んでることもあれば Evaluating LLM System Evaluating LLM-based Applications などなど表現の仕方は様々になっています。 そしてそのプロダクト開発文脈での評価も、実態としてはオフライン評価やオンラ

    LLMにまつわる"評価"を整理する
  • 東京都の生成AI活用事例集にツッコミを入れてみる|saip(さいぴ)

    この記事の概要 ・都職員による生成AI活用事例集を基に、ChatGPTの効果的な使い方を解説 ・プロンプト作成のコツと最新ノウハウを平易な言葉で紹介 ・具体的な指示、マークダウン記法の活用、理由の記載など実践的なテクニックを解説 ・サンプルプロンプトの修正例を通じて、より効果的な書き方を例示 ・ChatGPTとの対話を通じた論理的思考力向上の可能性を示唆 Claude 3.5 Sonnetで作成こんにちは、saip (@_saip_) です。 生成AIを利用した事業をしている株式会社TrippyでCTOを務めています。 Xで話題になっていたところてんさんの以下のポストから、「都職員のアイデアが詰まった文章生成AI活用事例集」という資料が公開されていることを知りました。 東京都もMarkdownとは言ってなくて、ハッシュタグと言ってる…… どうみてもMarkdownの見出しによる強調なんだが

    東京都の生成AI活用事例集にツッコミを入れてみる|saip(さいぴ)
  • テキスト生成 AI 利活用におけるリスクへの対策ガイドブック(α版)

    テキスト生成 AI 利活用におけるリスクへの対策ガイ ドブック(α版) 2024(令和 6)年 5 月 29 日 デジタル庁 〔ドキュメントの位置付け〕 参考資料。今後、デジタル社会推進標準ガイドラインへの編入を検討予定 〔キーワード〕 テキスト生成 AI、生成 AI、サービス開発者、サービス提供者 〔概要〕 テキスト生成 AI を利活用し、行政サービスや職員業務の改善の重要度が高まる中、リ スクを特定し、そのリスクを受容できるレベルまでに軽減する対応もまた重要になってい る。テキスト生成 AI に関連するリスクは多岐にわたるが、その多くはテキスト生成 AI 固有 でない AI システム全般に共通するものである。そこで、文書では政府情報システムを対 象に、テキスト生成 AI 固有と見られるリスクに焦点をあて、留意点を紹介する。現段階 (2024 年 5 月現在)では、実践的なフレームワー

  • 【西川和久の不定期コラム】 初心者も簡単!ついにPCで104BのLLMも動かせるようになった!そして巷を騒がせるマルチモーダルも試した

    【西川和久の不定期コラム】 初心者も簡単!ついにPCで104BのLLMも動かせるようになった!そして巷を騒がせるマルチモーダルも試した
  • これをやると「言語化が苦手な人」と、意思の疎通がしやすいかもしれない。

    様々な会社に訪問していると、それなりの頻度で「言語化が苦手な人」に遭遇する。 例えばこんな具合だ。 「プロジェクトの基要件を一つにまとめてマネジメントしたいんだけど。 例えば、一部のプロジェクトで必要なリソースを最初に一つの大きな枠組みで決めて、それを全部に使う、そんな感じ。」 「言葉にできてるじゃない」と思う方もいるかも知れない。 だが、当に言語化の苦手な人とは、「言葉にはできているのに、その内容が、他の人にとって難解過ぎる人」なのだ。 「言葉が出てこない」 「説明しにくい」 「なんと言えばいいのか迷う」 というのは、実は「言語の苦手な人」よりもかなりマシである。 なぜならば、「言語化できていない」という認識を自分自身で持てるからだ。 それに対して、真に言語化の苦手な人は、自分自身で「言語化が苦手」と気づいていない可能性が高い。 前職にもこんな人がいたが、 「あの人、あたまが良すぎて

    これをやると「言語化が苦手な人」と、意思の疎通がしやすいかもしれない。
  • 「ユーザー感性学事典」を発行しました | 統合新領域学府 ユーザー感性学専攻

    2021.06.01 「ユーザー感性学事典」(全210ページ)を発行しました。ユーザー感性学専攻の10年を振り返り、さらに次の時代を見据えながら、これまで取り扱ってきた多様なイシューをキーワードの形で可能な限り網羅した事典です。収録した493のキーワードは、すべてユーザー感性学専攻に携わる教員たちが執筆し、ユーザー感性学の守備範囲の幅広さと、常に問い続ける姿勢を象徴しています。専門分野を横断、越境しながらユーザー感性を探求するための手がかりとなる1冊です。 この度、コンテンツをダウンロードできるようにしましたので、ぜひご覧ください。 「ユーザー感性学事典」に収録したトピックについて、著者である専攻の教員たちが専門を横断・越境しながらオンラインで語り合うトークセッションと入試説明会も企画しました。6月7日(月)18:30〜です。詳細とお申込みはこちらから。

  • GitHub - azu/textlint-rule-web-plus-db: [unofficial] WEB+DB PRESS用語統一ルール for textlint