Kiwami

これまで『WebPerfect CMS』と呼称していた弊社製品の名称を『WebPR CMS』と改称いたしました。

WebPerfectの申請・承認ワークフローや高度なニュースシステムが広報向けであったことと、Web広報を行う上で活用しやすいテンプレートや、ソーシャルメディアとの親和性を高めたことにより、広報CMSとしての自信を深めたためです。

広報CMSといっても、企業の広報部門での活用はもちろんのこと、『Web広報』という広い意味で、様々なシーンで活用していただけるものと自負しております。

今回、弊社サイトもWebPR CMSをベースに全面リニューアルいたしました。ニュース機能だけでなく、弊社実績ギャラリーもCMS化しております。例えば貴社製品紹介などをこのようにCMS化し、ソーシャルメディア上でどんどん拡散することも期待できます。企業アカウントでブログを書くことはいまや一般的ですが、ブログのPV（ページビュー）を自社サイトに活かせないのはもったいないことです。そこをWebPR CMSのサイト内ブログを活用することで、自社サイトのPV向上やブログに日々綴る文章でサイトの検索性アップも期待できます。さらに、WebPR CMSは承認ワークフローがベースであるため、企業ポリシーに相応しくない記事も公開前に発見し、管理画面上で修正を促すこともできます。ひとつのブログ記事やTwitterのつぶやきが会社を窮地に追い込むことがニュースとなる時代、承認ワークフローはCMSに必須な仕組みだと考えております。また、社内ブログは数名持ち回りで書くケースが多いですが、記事末尾に名前を入れるだけでなく、このようにアイコンで視認できるのも分かり易くてよくないですか？（笑）

WebPerfect改め、『WebPR CMS』の情報をこれからも発信させていただきます！

WebPerfectの「ニュースシステム」は、上場企業の開示情報をコントロールするために開発したものをベースとしています。そのため、承認ワークフローと併せて、かなり厳重で高度な機能を保有しているのですが、ここでも柔軟性を失わない事に力を入れています。

最適な表示形態を自動判別するニュースシステム

ニュースシステムを備えたCMSは数多くありますが、表示形態を制限するものが多く見受けられます。例えば、ヘッドラインをクリックすると詳細情報にリンクするシステム、ヘッドラインをクリックするとPDFが表示されるシステム等、特別な機能を持たせるほど表示形態を制限する傾向が見受けられます。

WebPerfectのニュースシステムは、専用フォームのどの項目に情報を入力するかで、自動的に最適な形態を判別します。

他にも、画像や圧縮ファイル等を組み合わせたり、ニュース種別を分類するためのラベル機能、表組を作成するためのツール等、企業が必要とするあらゆるニュース機能を備え、それらを混乱することなく最適な形で掲載するところが、WebPerfectニュースシステムの強みです。

承認ワークフローについての３回目の記事として、敢えて削った機能について書きたいと思います。

WebPerfectの承認ワークフローにメール通知が無い理由

WebPerfectの承認ワークフローには、他社の申請・承認機能でよく採用されている、「申請しました」「承認しました」のメール通知機能が付いていません。ここは社内でも議論になりました。ちなみに僕は「メール通知もつけようよ」と言っていました。他社製品に付いていて自社製品に付いていないのが不安だったわけです。

ここは僕が論破されました。システムを設計する際にはコンセプトがあります。WebPerfectの承認機能は内部統制であると同時にワークフローであることはしつこく語ってきた所です。そのコンセプトは、

「能動的なサイト更新」

に、あります。これはデモサイトで適当なページを申請している限りは気付かない所かも知れませんが、実際にコンテンツを制作するときには自分がいいと思ってからでも、見直せば気になる所がポロポロ出てくるわけですね。その都度メールで通知されてしまうとどうなるでしょう？なかなか気軽には申請できなくなると思います。「一度で完璧にやれよ」等と上司に言われてしまうと、次第に申請する時に萎縮します。神経の太い人なら気にせず送るのでしょうが、ひとつの記事を申請するのに自主的に申請メールが3通も4通も届いてしまえば、通知メールを迷惑メールに分類したくなる衝動にかられる事と思います。もしくは申請メールの重要度が低くなり、真面目に目を通さなくなってくるわけですね。申請したコンテンツの申請取り消しができないシステムもあるようですが、僕は論外だと思います。WebPerfectでは、申請の取り消しはもちろん、承認の取り消しもできます。判断するのは人間ですから、そこを縛ると結局慌てて電話で「待った！」を掛ける事になると思うからです。

このメール通知を外してしまうという決断は、少しオーバーですがAppleの姿勢を参考にさせていただきました。機能を盛り込みたい衝動はあれど、そこを削ることで実用的にしたわけです。AppleのiPodに至っては電源ボタンすらありませんでしたね。WebPerfectでは能動的なワークフローを優先するために、必要と思われそうなメール通知を「申請の負担になる」「通知が形骸化する」と判断して削ったわけです。通知したい時は、本当に承認して欲しいと思ったときにメールするか、声を掛ければいいと思っています。

昨日の記事を書いた時点で、まさかすぐに（その２）を書く事になるとは思ってもいませんでした。すぐに（その３）も書きます。何かが発覚したとか、そういうわけではありません。ひとつ書くと次々に書きたい事が出てきてしまう、単に僕がおしゃべりなだけでございます（笑）

小さな会社に承認機能は必要ない？

実は最近まで僕もそう思っていました。「内部統制」という意味での承認機能と考えると、ある程度大きい会社がWebPerfectの利用対象者になると想定していたのです。社内でもそのように話していました。考えが変わったのは実際に触りはじめてからです。

（その１）でも少し触れましたが、WebPerfectの承認ワークフローは、申請・承認システムであるだけでなく、ワークフローであることを意識して開発しています。「サイト更新をいかにストレス無く管理画面を使って行うか」を課題に設計したのです。それがいかに開発効率を無視したものであったかは（その１）でも触れた通りです。もう一度言います。苦労をお掛けしました（笑）

通常サイト更新をする際、まずillustratorまたはPSD等でカンプ（レイアウト見本）を作る事が多いです。会社によってはWORDやEXCEL、PowerPointで作成される所も多いでしょう。そこでまずチェック（承認）が必要になります。そしてHTMLファイルを修正または作成します。そこでもまたチェック（承認）が必要になります。最初にチェックしたはずの事が２度目にはチェック洩れする可能性も少なくないと思います。実際我々もお客様のサイト管理でそういうミスを犯した事があります。無論、怒られます。そして修正の場合、今回の修正以前に直したはずのものが元に戻っていたりする不思議が、サイト更新ではよくあるのです。これはサイトファイルの管理ミスによるもので、特にサイトファイルを複数の会社で共有していたり、サーバーとローカルの別々で管理していたりすることで、以外と頻繁に起こりえます。

承認ワークフローに限らず、CMS（サイト更新システム）のいいところは、サイト管理が見えやすくなる事です。さらに承認ワークフローがあると、コンテンツのチェックが１度で済みます。率直に、設計当初は承認ワークフローを挟むということは工程をひとつ増やすことで効率を犠牲にして公開情報の信頼度を維持する事だと思っていたのです。「内部統制」側面からの考え方です。ただ実際には、元々アナログで承認していたわけですから、そのアナログな作業の効率化と精度向上に役立っていたわけです。盲点でした。

WebPerfectの承認ワークフローは、少人数の会社でもサイト更新の効率化をもたらします！

好きな事を書こうと思うと肝心な製品についてなかなか触れない気がしてきましたので、本日２件目の投稿です。（その１）としましたが、多分（その２）もあるだろうな、という事で深い意味はありません。テクニカルなことは弊社杉山がそのうち投稿してくれるものと思いますので、僕は使い勝手とかそういう事をご紹介していきたいと考えています。

まず、最初にご紹介したいのは「承認ワークフロー」です。

一番開発に苦労したところでもありますし、ワークフローの名のとおり、システムの基幹としてインタフェースとしてもバックボーンとしても大きく関わる部分です。ステイタスは「未申請」「編集中」「申請中」「承認済み」「否承認」「公開待ち」と6種類あるのですが、これも当初は「編集中」というステイタスが無かったり、公開中のデータを編集する場合と新規でデータを編集する場合で別々に処理する必要がある事に後から気付いたりと、開発スタッフには本当に苦労を掛けました。プログラム処理としては12種類のステイタスで管理しています。

使い勝手としてまずお伝えしたいのは「楽しい♪」です。

WebPerfectでは、承認者用とコンテンツ作成者用と管理画面の機能を分けております。承認者用の管理画面は「タスクマネージャ」というシステムだけが存在し、公開許可を求めて申請されたコンテンツを「承認」か「否承認」するだけのシンプルなものです。手前味噌かも知れませんが、本当に誰でも操作できると思います。ブラウザやメールソフトより簡単です。否承認の時はもちろんの事、承認時にもコメントが残せますので意思の疎通が確実です。否承認された時はコメントの指示を見ながら修正できます。当然うちの会社では私、荻野が承認者です。サイトの更新をスタッフに任せても、自分の予期しないものが勝手に公開される事が無い安心感があります。そして「承認」するのが楽しいのですね。「却下（否承認）」する時は、もっと楽しいです（笑）この小さな優越感が「社長やってよかった」と、感じさせてくれます。

あとは辛い事ばかりです（笑）

話がそれそうになりました。実際、この承認ワークフローは効率がいいです。比較的大雑把な指示をスタッフに与えても、スタッフとしても気楽に作成できるようです。そして申請されたものに対し、直接指示を書き込めます。指示する側は手取り足取り教えなくてもいいし、スタッフにはいい訓練になります。会社の情報ポリシーを共有する機会にもなります。そしてコンテンツを直接チェックするので、確認用のJPEGやPDFのような中間ファイルも必要ないし、紙を無駄にすることもありません。そして何よりも、紙やJPEGでは了解したけど実際に公開されたファイルには転載ミスがあった、もしくは先祖還り（過去のファイルを触るので過去に直したものがまた復活している）していた、なんて事を誰でも一度は経験されてきたのではないでしょうか？

そういうリスクを排除できることが、承認ワークフローの実利的メリットです。

デメリットは何でしょう？思い当たる事といえば、会社が静かになったことでしょうか。いや静かなのはいい事だ！という方にはメリットですが、私にはデメリットです。サイトの更新が画面のやりとりだけでできる事がアタリマエになると、他のことまでメールで質問や報告を受ける事が増えました。3メートルくらいしか離れてないのに、です。会社には活気が必要だと思う僕には、ちょっと寂しい限りです。まあ、あんまり僕に話しかけられたくないスタッフには、仕事に集中できて良いようです。

性格上無駄口は減らせませんが、もっと僕を構ってください（笑）