はじめに
こんにちは。フォルシア株式会社エンジニアの宮本です。
社員全員が見られるWikiにナレッジを蓄積していくことは業務の効率化のために重要です。しかし、その運用を継続し全体に浸透させるのは簡単ではありません。
私の所属するフォルシアでは情報共有サービスのesaを利用しており、知見共有が比較的うまくいっている方だとは思いますが、一方で私は「記事を書くのが億劫だな。みんな書いていてすごいな。」と思うことが多々あります。このブログでは、そんな記事を書きたくない私が頑張って記事を書くために工夫していることを紹介します。
自分のために記事を書こう
記事を書くのが億劫になる要因の一つに「自分が知っていることを書いて何になるんだ？」という気持ちがあります。自分が知っている情報を記事に書いても新しく何かが学べるわけではありません。他の人に読んでもらえるのであればまだよいものの、検索にヒットせず読まれなくなるといよいよ何のために書いているのかわからなくなります。
私は「人のために書くのではなく自分のために書く」と思うことでモチベーションを保っています。
（１）自分が忘れないようにする
備忘録としてはObsidianやNotionなどのツールがよく知られていますが、新しいものをキャッチアップして使いこなすのは少し大変です。私は使い慣れているesaに情報管理上問題ない範囲でメモ取りをしており、そのメモが副次的に社内に公開されています。正直自分しか読まないだろうなという記事あります。
（２）同じことを何度も説明しないようにする
1つの案件に携わるメンバーは流動的です。新しく参画したメンバーに同じことを何度も説明することはお互いにとって無駄が多いため、基本的な情報はできるだけ文書化しています。
（３）記事を執筆して自分の不足知識を補う
書きたいことがらを理解していないと文章を書くことはできないため、記事を執筆する際にいろいろ勉強して知識を補えます。また、記事を書いていく中で「ここの部分であまりちゃんと考えたことなかったけど整理した方がいいよね？」「この作業ってよく考えたら自動化できるよね？」といった気づきから思わぬ業務改善につながることもあります。
記事の執筆に時間はかけない
記事のクォリティやディテールにこだわりだすといくら時間があっても足りません。私は完璧を目指さず、できるだけ短時間で書ききるようにしています。
たとえば、以下のように平文を避けて見出しと箇条書きのみの構成にすることで、文章の流れや接続詞などを一切無視できるので記事の執筆時間を短縮できます。
# おいしいカレーの作り方
この記事ではカレーの作り方を紹介する。
## 材料
- カレールウ、肉、じゃがいも、にんじん、玉ねぎ、サラダ油、水
## 手順
- 野菜と肉を一口大に切る
- 大きさを揃えると火の通りが均一に
- 鍋に油をしく
- 肉を炒める
- 肉の色が変わったら野菜を加えて炒める
- 中火
- 玉ねぎがしんなりするまで
- 水を加えて沸騰させる
- アクを丁寧に取り、具材が柔らかくなるまで煮込む
- 火を止めてカレールウを入れる
- ルウが溶けるまでよく混ぜる
- 再び弱火でとろみがつくまで煮込む
- 鍋底が焦げ付かないよう時々混ぜる
見出し、箇条書き以外には次の工夫によって記事の執筆時間を短縮しています。
図、画像
図や画像があると読み手にとってはわかりやすいですが、以下の理由から私はあまり使いません。
- 図の作成やメンテナンスに時間がかかる
- 図の文章化をあえて試みることで思考が整理できる
- 箇条書きと見出しだけの構成の場合、図が全然なくても全体に圧迫感が出ない
なお、図の作成やメンテナンスにかかる時間については draw.io を利用して効率化している人が多いようです。
リンク
自分が書きたい内容を既にほかの人が書いている場合はリンクを貼って二度手間を避けています。ただし、リンク先の記事の情報が古い場合があるので、リンク先の記事を修正したり、元の記事で補足します。
- アクを取り、具材が柔らかくなるまで煮込む
- アクの取り方は `[○○さんの記事](URL)` を参照。2021年の情報なので注意！
アラート構文
補足情報を箇条書きに収めるのが難しい場合はアラート構文を使用します。
# おいしいカレーの作り方
この記事ではカレーの作り方を紹介する。
> [!CAUTION]
> 会社でカレーを作るときには部長の許可を取ること
記事を分割するか？まとめるか？
Wikiに内容を追加するときに、新規の記事を作るか既存の記事に書き足すかは悩ましいところです。
私は、
- 新しいメンバーが見るべき記事は細かく分割せず1つにまとめる
- 古参メンバーが時々参照するような記事は別の記事に切り出す
という目安を設けています。
業務の基本的な内容については、「○○案件虎の巻」のような箱を一つ作り必要な情報を少しずつ書き足していきます。「システム概要・設計思想」「典型的な仕事の進め方」「トラブルシューティング」などを一つの記事（ページ）の別々の見出しにまとめるような感じです。これらの内容は特に新しく参画した人にとっては頻繁に参照する必要があり、複数の場所に情報が散逸していると検索性が落ちてしまうからです。
一方で1つの記事の分量が増えすぎるとメンテナンスが難しくなるため、頻繁に参照するわけではない情報（作業手順、意思決定の経緯、細かな機能の説明）は別の記事に切り出しています。
自分の書いた記事をアピールしよう
書いた記事を読んでもらうための工夫も欠かせません。
- タイトルを工夫する[1]
- 書いた記事をslackの個人チャンネルで事あるごとにアピールする
- slack上で質問に回答する際には「ここに書いてますよ」と記事を引用する
などの宣伝活動で記事を埋もれないようにして、執筆やメンテナンスのモチベーションを保っています。
年1回記事をメンテナンスしよう
せっかく書いた記事でも時間がたつと信頼性が落ちるため、メンテナンスが必要です。自分の経験ではだいたい1年が記事の鮮度の目安になっているため、「年1回のメジャーリリース」と「頻繁なマイナーリリース」に分けることで記事を管理しています。
年1回のメジャーリリース
年に1回、メンテナンス対象の記事の中身をすべて精査して最新の情報に書き換えます。
その際、記事のタイトルに年号を含めることで、「記事の品質が最後に保証されたのはいつなのか？」を一目でわかるようにしています。
- 2024年5月 : 「おいしいカレーの作り方メモ 2024」執筆
- ～2024年12月 : 「おいしいカレーの作り方メモ 2024」の品質が担保されており安心して読むことが出来る。
- 2025年1月 : 記事全体の内容を見直して削除・更新し、「おいしいカレーの作り方メモ 2025」にタイトルを変更
- ～2025年12月 : 「おいしいカレーの作り方メモ 2025」の品質が担保されており安心して読むことができる。
頻繁なマイナーリリース
当然1年経過しなくても情報の更新が必要なことはあるため、気づいたときベースで『マイナーリリース』しています。
- 記事に記載されている内容が変更された場合
- 新しくチームに参画した人から記事に書いていない質問を受けた場合
esaに救われていること、会社の方針に救われていること
ここまでは自分が工夫していることを紹介しましたが、esaそのものの機能やフォルシアの運用方針の恩恵を受けている部分もあります。
esaでは記事にStarを付けることができる
esaには他の人が書いた記事にStarをつけることができます。
自分の書いた記事にStarがつくととても嬉しく、お互いにStarしあうことで執筆のモチベーションが維持できています。[2]
また、記事の執筆者のアイコンがタイトル部分に大きく表示されるため、自分が記事を書いた成果を社内にアピールできるのもよい点だと感じています。
下書きのままの記事や重複記事もどんどん書ける
一般的にWikiといえば特定のことがらに対して解説を体系的に記載する「百科事典」をさしますが、形式に縛られすぎると筆が進まないということはありがちです。
esaには『WIP: Work In Progress』機能で下書き状態の記事を投稿できます。記事を書きたくなったときに自分の好きなテーマでドラフトを書いて一旦WIPで公開するということができるため、執筆のハードルが下がっています。
ナレッジに限らず社内の文書をesaに残す文化がある
社内Wikiを発展させるためには、日常的にWikiにアクセスして記事を読んだり書いたりする文化が不可欠です。フォルシアでは、適切な情報管理の下で、ナレッジに限らない日報や議事録にもesaを使用しています。そのため、esaに知見を共有することにも抵抗がない社員が多いように感じます。
この記事を書いた人
宮本 唯
2022年新卒入社
この記事では知見を溜める知見を紹介しました。今後も引き続き知見を溜める知見を溜めていきたいです。
Discussion