- はじめに
- そもそもクローズ環境とは?
- クローズ環境の目的
- クローズ環境運用時の体制
- クローズ環境の要件
- クローズ環境のプラットフォーム
- クローズ環境から本番環境への移行要件
- クローズ環境で得られたもの
- おわりに
はじめに
先日、はてなブログMediaの利用事例インタビューを受けまして、先日、2022/2/7に公開されました。
本記事では、インタビューで答えきれなかった、「企業技術ブログの本番運用前にクローズ環境で運用した時に何を考えていたか?」についてまとめてみたいと思います。
そもそもクローズ環境とは?
本技術ブログは2022年3月から開始していますが、それに先行して3か月間ほど、社員のみがアクセスできる環境を用意し、そこで技術ブログの運用を行っていました。
社員のみのクローズドな環境だったので、「クローズ環境」と呼んでいます。
クローズ環境の目的
次の3点を主な目的としました。
- 記事の作成に慣れる
- 実際に記事を書く記者の方に「外部向けの技術記事を書く」という事に慣れてもらう
- 運用ルールや懸念点を洗い出す
- 編集やレビューなどの記事公開までのフローや、レビュー時にどういった点をチェックするかなどのルールや懸念点を洗い出し、本番に向けたルールの策定を行う
- 必要な機能や要件を洗い出す
- 外部公開に際し、必要になる機能を洗い出し、外部公開時のサービスやプラットフォーム選定に反映させる
- SNS公開用機能、分析機能、記事エディタの機能、権限管理などを想定
クローズ環境運用時の体制
クローズ環境での運用時は、投稿する方は、技術文章をある程度書きなれている方を中心にお願いしました。
その他の運用体制は本番運用時と基本変わりませんでした。
クローズ環境の要件
クローズ環境の要件として以下の点を定めました。
- 社員外の人がアクセスできない事
- 社員がアクセスする際には記事の参照のみ出来る事(記事投稿は登録した人のみに限定)
- 社員が参照する際にブログ用のID作成を必要としない事
- 社員が参照する際に共有IDを入力する必要が無いこと
- ある程度長期間(数か月)環境を維持できる事
社員だけのアクセスとしたのは、パブリックに公開する前に一度ブログのプラットフォーム上に記事を載せることで、こちらが想定しているガイドラインやルールが適切かどうかを見定め、必要に応じて追加、修正をすることが狙いでした。
一方、社員が参照する際にID作成などをさせたくなかった理由はいくつかありますが、一番の理由は、IDを作るというひと手間がかかるとブログを参照する人が減ると考えたためです
クローズ環境とは言え、社員には見てもらってフィードバックをもらいたかったので、この辺りは早い段階から考えていました。
クローズ環境のプラットフォーム
この時点で利用する外部サービスは確定していませんでした。また、確定していたとしても、数か月間を評価版的に使う事も難しかったので、本番サービスとは別にする事を考えました。
クローズ環境の要件と、僕の持っているスキルセットを活かせるもので考えた結果、以下の様な構成になりました。
- Azure の Web Apps 上に WordPress 環境を構築
- Azure Web Apps に対して Azure AD 認証を設定
社内の SharePoint に書いてもらう事も考えたのですが、それだと社内で閉じて終わってしまう懸念があったので、外部に公開することを意識して、あえて WordPress を使いました。
参考:
- AzureでWordPress環境を作成する話 ~ARM Templateを添えて~ - JBS Tech Blog
- Azure Web AppsでAzureAD認証を利用する - JBS Tech Blog
クローズ環境から本番環境への移行要件
最終的に技術ブログを外部公開することを考えて活動はしていましたが、クローズ環境運用前は特に、「実際に記事が投稿されるのだろうか?」という懸念は常にありました。
企業の名前を背負って技術ブログを運用する以上、あまり投稿頻度が低いと会社のイメージ低下につながる恐れがありました。また、記事が投稿されても特定の人だけが書いていると、これもまた企業の技術ブログとしてはあまりイメージが良くないと考えました。
そこで、下記の様な条件をクローズ環境での運用中に満たせなかった場合は、公開を見直す、あるいは延期することを考えていました。
- 一人の人だけが書いているような状況ではない状態にする。
- 具体的には、一ヶ月の記事数に対する1人当たりの記事数の占める割合が50%を超えないようにする
- 最低でも3人以上の投稿者がいる
- 営業日の50%以上は投稿がある
幸いな事に、当初の想定以上に投稿者も記事も集まったので、ここは考えたものの杞憂で終わりました。
クローズ環境で得られたもの
クローズ環境での運用を通して、本番公開後に利用するルールであったり仕組みであったりを固める事が出来ました。
クローズ環境で作成された記事の活用
外部公開後、クローズ環境で書かれた記事も少しずつ公開する形で活用する事が出来ました。
その代わり、記事の移行はちょっと大変でした。
参考:
記事レビューから公開までの流れの確立
WordPressとはてなブログMediaで多少異なるものの、以下のポイントは共通でした。
- やりたかった事
- 記事の公開は編集部でレビューした後に限定したい
- システム的な制限
- 投稿者が記事を書いた後でレビュー完了とする仕組みや、それを通知する仕組みがない
そこで、Forms を使ったレビューの仕組みを Power Automate で用意しました。
この時作った Power Automate のフローは改善を重ねつつ現在も使用しています。
参考:
運用ルールやガイドラインの制定、最適化
技術ブログとして外部に記事を載せる際のルールやガイドラインも、クローズ環境での運用中に固めました。
実際には、クローズ環境での運用開始時点でも定めてはいたのですが、運用を進める中で「これも触れておいたいい」といった項目を追加して本番時には改めてルールとガイドラインを定めました。
また、ルールやガイドラインへ同意して投稿を開始するまでの流れを、これもまた Power Automate で作成し、今でも利用しています。
参考:
レビュー時の方針策定
編集部がレビュー時にどういった点を見ているか、という点について、クローズ環境での運用中にある程度で揃ったものをまとめました。
今のところ利用頻度は低いのですが、今後、編集部を拡大していくときには有益な情報になると思っています。
おわりに
ということで、事例紹介をきっかけに、クローズ環境での運用中に考えたことや得たことをまとめてみました。
もしこれから企業技術ブログをはじめよう、という方の参考になれば幸いです。
舟越 匠(日本ビジネスシステムズ株式会社)
人材開発部に所属。社内向けの技術研修をしつつ、JBS Tech Blog編集長を兼任。2024年8月からキーマンズネットでPower Automateの連載を開始。好きなサービスはPower AutomateやLogic Apps。好きなアーティストはZABADAKとSound Horizon。
担当記事一覧