More Related Content
さくらのナレッジの裏側
- 1.
- 2. 法林 浩之 • フリーランスエンジニア •さくらインターネットに常駐中 (6年⽬) • 社内外のイベント対応(協賛/出展/登壇/取材) • さくらのナレッジ編集⻑ • ⽇本UNIXユーザ会 幹事 (元会⻑) • 多種多様なコミュニティとイベントを共同開催 • くわしくは「法林浩之」で検索 @hourin
- 3.
- 4. 記事の傾向・本数 • エンジニア向け • 最近は⼤半がこちら •技術解説やノウハウ紹介など • 初⼼者向け • さくらのレンタルサーバ関連の記 事が多い • イベントレポート • ⾃社イベント • 社員が登壇した外部のイベント • 著者は社員と社外が半々 • ⽉に4-8本ぐらい公開
- 5. • 編集担当：2⼈ • 他の業務と兼務 •来⽉から⼤物Z参戦予定 • システム担当：2⼈ • Webマーケティング担当：1⼈ 運営体制
- 6. • 題材や著者を探して執筆を依頼 • 著者が原稿を書く •⼊稿⽅法/原稿フォーマットは⾃由 • 編集部にて編集/確認 • 基本的に2⼈で確認 • 公開 記事ができるまで
- 7.
- 8. • 反応が良い記事 • オープンな技術の解説(例： JavaScriptの⾮同期処理) • サービスの宣伝ではない社内業 務の舞台裏紹介 (例：ゼロトラ ストの取り組み) • 反応があまり良くない記事 • サービスの宣伝臭がする記事 • イベントレポート • 特に技術⾊の薄いもの • 分野が多岐にわたるもの (話題が 散漫になり内容が薄くなる) アクセス傾向から推測される読者の要望
- 9. • 理想 • 社員エンジニアが、業務で使っているツールの紹介や、 オープンな技術の解説記事を書くのが、反応も良さそう だし、さくナレの主旨にも合致している •現実 • 社員著者数は1年間で10⼈程度 (社員数は約700⼈＝1.5%) • 技術記事を速く⼤量にかけるエンジニアは極めて希少 • 開発や運⽤の業務が優先され記事執筆の優先度が低い • 会社の媒体に書くよりもQiitaやブログの⽅が気楽 理想と現実
- 10.
- 11.
- 12.
- 13. 作業⼿順(概略) • 発表の動画か⾳声を⼊⼿ (YouTubeでも可) • 動画を再⽣しUDトークで⽂ 字起こし •⽂字起こしデータをもとに 原稿を作成 • 発表資料から図などを差し 込んで記事完成 • 発表者と編集部で確認/修正 して記事公開
- 14.
- 15. • 発表内容には専⾨的な⾔葉が多く含まれる • 技術⽤語(例：Kubernetes) • ⾃社サービス⽤語 (例：Tellus) • ⽂字起こしの前に発表資料を⼊⼿ • 資料に⽬を通して、専⾨⽤語/⾃社⽤語を単語登録 • 読み⽅が複数ありそうなものは両⽅登録 UDトークに単語登録
- 16. • マイクで⼊⼒すると雑⾳が多く認識率が激減 • オーディオインターフェースを使ってライン⼊⼒ •ノイズが⼊らず認識率が激増、⾳声レベルも調整可 • 機材例：iRig2 • UDトークをONにして動画を再⽣ • 発表終了まで放置しておけば⽂字起こし完了 UDトークへの⾳声⼊⼒ オーディオ 端⼦ スマホ タブレット オーディオ 端⼦ PC
- 17. • ⽬的は⽂字起こしではなく記事制作 • ⽂字起こしデータはあくまでも素材 •誤認識や⾔い直しも多い • 発表は⼝語だが記事は⽂語なので変換が必要 • 発表をもう⼀度聞きながら、⽂字起こしデータを 編集して⽂章を作成 原稿作成時の⼯夫(1)
- 18. • 本題から外れる話は省く • ⾃⼰紹介、会社紹介、余談など •⼝癖や頻出する⾔い回しの置き換え • みんな何かしら癖がある • それを忠実に⽂章化するとくどいので 適宜表現を変える 原稿作成時の⼯夫(2)
- 19.
- 20. • 15-20分の発表で6000-8000⽂字 • 45分の発表だと15000-20000⽂字 •さくナレの記事は2000-6000⽂字が⽬安 • 15分も話せば記事1本分ぐらいの⽂字数になる • 45分の発表は2本に分割 発表時間と⽂字数
- 21. • 単語登録と⽂字起こしで1⽇ • 原稿作成に1-2⽇ •著者/編集部との確認/修正で1⽇ 記事制作の所要時間
- 22. • 現在はこの作業ができるのが法林のみ • 他の⼈でもできるようにしたい •作業⼿順のマニュアルを⽤意するとか • 特にエンジニアが⾃分で作れるようにしたい 今後の野望
- 23.
- 24.