背景
Qiitaには Organizationという機能があり、そのコンセプトは
Qiita Organizationは組織のナレッジや
技術力をアピールするための機能です。
となっています。
が、組織として技術記事を書くことにはそれ以上に以外にもメリットがあると考えています。
この記事ではそのメリットについて記載します。
前提：わからないことを調べるプロセス
何かわからないことがあった場合、下記のようなプロセスを踏むことが多いのではないでしょうか。
筆者の場合、
- 2.社内ナレッジが存在しない
- 3.わかる人を探すために、わかる人を知っている人を探すループが発生
というのも経験しています。
次項からは、組織のメンバーが技術記事を書くことで上記のプロセスがどう改善できるかを解説します。
組織のメンバーが技術記事を書くメリット
1. ググったら見つかる
これは社内に閉じたナレッジ共有の手段に対してパブリックな場が有効である理由です。
4.のわかる人がナレッジを適切にアウトプットしておけば、2. ~ 4. を省略することができます。
また、筆者は過去にSES・派遣をメインにする会社に所属していましたが、常駐先からは自社のナレッジにアクセスできない。ということがほとんどでした。
そうすると「誰も見てくれない、環境が変わったら見れない」という理由でアウトプットのモチベーションが下がります。
その点、ググって見つかるプラットフォームであれば環境が変わっても参照することができるので、アウトプットのモチベーションを保つことができます。
2. わかる人（わかりそうな人）が誰かわかる
仮にわかる人のアウトプットが不十分だったり、知りたいことがピンポイントでわからなくても、周辺知識についてアウトプットしている人がわかれば直接相談することができます。それによって 2. ~ 3. を省略することができます。
昨今リモートワークが普及し、以前より3. 4. のハードルが上がっていると感じます。
このハードルを下げるために 誰が何を知っているかをわかりやすくする のに有効ではないでしょうか。
また、アウトプットに対するフィードバックも受けやすくなるので、アウトプットの品質向上にもつながります。
気を付ける点
ガイドラインを設ける
組織で推奨している = 何を書いてもいい という発想にならないように一定ガイドラインを設けるべきです。
- 公開していい情報なのかの判断軸を設ける
- 機密情報
- 個人情報
- など
- コードや画面キャプチャに気を付ける
- プロダクトのソースコードを直接貼る
- AWSのマネコンのキャプチャを貼る際に、本番環境のものを使う
- など
利用するプラットフォームのガイドラインに従う
QiitaやZennは、記事の内容に対するガイドラインが存在します。パブリックなプラットフォームを使うからにはそのプラットフォームのガイドラインを守りましょう。