こんにちは。
正社員1年目の山田です。
去年の8月頃、会長の川上から「社内ポータルサイトを作っていこうと思います」と声がかかりました。
チームは先輩の有山と僕の2人です。
僕は社会人経験もほぼないような末端です。
末端なりにどう価値を出せるのか頑張って考えたことをまとめます。
ポータルサイトは今年の1月にリリースされ、今も順調に運用が続いています。
分量が多いので何回かに分けて書こうと思います。今回は準備編です。
0から考える
そもそも社内ポータルサイトって何でしょうね。
似たような言葉にイントラネットとかグループウェアなどがありますが、何が違うんでしょうか。
世間で言うところのイントラネットやグループウェアを社内にそのまま構築しても上手くいかないだろうというのはプロジェクトの当初から感じていました。
その原因は、イントラネットやグループウェアという言葉が僕にとってはやや古いニュアンスを持っているところにあると思います。
それらの言葉が生まれたときの問題意識を共有していないものを形だけ導入しては、言葉も方法論も思い入れも全て借り物のまま進めることになります。
ありものの言葉の定義より、自分たちが望んでいるものをゼロベースで考えていくことにしました。
ポータルサイトのパッケージツールを調査
最初にやったことは、既存のツールの調査でした。
導入するだけでポータルサイトが構築できるパッケージを提供している会社がいくつかあります。
それらはどれも素晴らしいシステムでしたが、次の理由から採用には至りませんでした。
- 不要な機能が含まれている
- カスタムしきれない部分がある
- デザインが選べない
そもそもソフトコムは社員数30人に満たない小規模の会社です。
フレームワークを全員に強制するよりも、小回りが利くシステムを細かく改善していく方がずっとうまくいきそうに思えました。
正直僕は既存のパッケージを入れてポータルサイトが運用できるビジョンは初めから全く見えていませんでした。
可能性を省く目的の調査でした。
この時点ではスクラッチ開発も視野に入っていました。
達成したいことの優先順位を決める
次にやったのが、解決したい課題とその優先順位を決めることです。
何のツールを使うのかということは後から考えればよいことでした。
ところで、パッケージのポータルサイトツールが提供している機能は概ね次の範囲です。

しかし、これらの全てがポータルサイトとして提供される必要はありませんでした。
既にソフトコムで使われているツールのいくつかは業務にぴったりマッチしているものがあり、これらをポータルサイトに置き換える価値はありません。
学習コストや移行による混乱、過去の情報の損失を考えると、非効率な割に大きく生産性が上がる見込みがないからです。
また、いろいろな機能が一度に提供されることはリスクでもあります。
なぜなら、複数の機能がある場合、使われない機能が出てくるからです。
使われていない機能が散見されるポータルサイトは、とても活気があるようには見えません。
このことを考えると、会社が本当に必要としている機能をミニマムで実装していくことが最適解です。
そのために解決したい課題とその優先順位を決めることが必要でした。
僕が当時考えた課題とその優先順位は次の通りでした。
- 社員が今、何をしているのかについて把握できるシステムがない
- 仕事のやり方が標準化されていない
- 情報が散らばっている、集約化されていない
- 案件にかける時間の計画がない
- どうすればより高い生産性を得られたのかフィードバックがない
そこからメンバーで相談し、最終的に3つのゴールにまとめました。
- 会社の仕事のやり方に関する標準化
- 全員にオープンな透明性を持った情報の可視化
- 社内規定の掲載
ここで、これらのゴールが先ほどの図でいう「静的/ドキュメント」志向を強く持っていることに気が付きました。
これは、次のような事情を反映しています。
- 社内依頼には別のツールが既に運用されていてポータルサイトに必要とされていないこと
- SlackやSkypeといったチャットツールを(非公式ながら)各々使っており、それらの利便性を超えるアプリケーションがポータルサイト上に構築できるイメージが持てないこと
GitLabハンドブックを知る
このような静的/ドキュメント志向をもつ社内サイトを運用している会社として、Gitlabを知りました。
同社が運用する「Gitlabハンドブック」には、仕事のやり方や組織運営に関するドキュメントがまとめられており、社員がそれを参照することによって大規模なリモートワークが実現されています。
早速『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』という本を購入。会長の川上にも読んでもらいました。
「GitLabハンドブック」に学ぶべき点は、標準を決めてドキュメント化しようとする意思です。
ソフトコムの業務はクライアントに対して臨機応変に対応することが多く、標準化するのが難しいケースが多々あります。
個々の対応のマニュアルのようなものが、大抵はエクセル形式で社内サーバーに保存されていました。
しかし、そのままでは次のような問題点があります。
- 生産性を高めるための議論が起こりにくい
- 仕事が属人化しやすい
- 各社員の能力や性格によって仕事のクオリティにばらつきが出やすい
- マニュアルがどこにあるのか、そもそもあるのかは担当者しか分からない
- 新人が仕事を学びにくい
この問題を解消するには、標準をドキュメント化し、ポータルサイトに置いておき、個々のクライアントへの対応は標準からのイレギュラーな処理として考えることです。
標準ドキュメントを作る担当者には、多かれ少なかれ会社全体にある方法を強いるプレッシャーがかかります。
「GitLabハンドブック」のような成功事例があることは、心理的にも助けになりました。
導入フェーズを設定する
達成したいことが決まったので、実際にどう達成していくのかを決めていくことにしました。
ここで気を付けたのが、一度に全ての機能を導入しないことです。
先述したように、たくさんの機能が一度にリリースされると、受け手に負担がかかります。
使われない機能が多ければ多いほど、そのポータルサイトは寂れて見えます。
そのため、全体を5段階のフェーズに分け、段階的に導入していく方針を取りました。
導入する機能をフェーズで分けることにはいい面と悪い面があります。
いい面は、小さく運用を回していく分、成功したところが分かりやすく、上手くいっていないところへのリカバリーがしやすいことです。
一方、悪い面は、初期のフェーズで導入する機能の選択によって、社内のメンバーごとに利用度に差が出てきてしまうことです。
そのため、特に最初のフェーズでは社内の全員が使う機能を必ず盛り込んでおく必要があります。
ソフトコムでは、
- TOPページに自由にお知らせを掲載できるニュース機能
- お昼休みや外出中、会議中などのステータスを表示できるスタッフボード機能
の2つを初めから実装することで、この問題に対処しました。
終わりに
ポータルサイトを作る話が出てから手を動かすまでに、このようなことを考えて準備をしていました。
次は実際に構築していくときに、どのようなツールを使い、どのように設計したのかを書く予定です。
もし社内ポータルサイトを作ろうと考えている方が読まれておられましたら、参考になれば幸いです。