はじめに
働き方改革とは
働き方改革とは何か。細かい定義や議論は省きますが、ここでは 今の前時代的働き方は WLB や QoL が犠牲になるほど杓子定規で非効率だから、もっと融通利かせよう、効率も上げよう(成果に要する労力を減らそう) という全社的活動を指すことにします。
アプローチは色々ありますが、方向性はおおまかに以下二つに分かれます。
- 効率化 …… 長時間労働(の一因になっている無駄・非効率的・非生産的な事物)を軽減する
- 多様化 …… 全社員の多様性(働き方、モチベーション、強み弱み etc)を活かしやすくする
いずれにせよ実現は簡単ではありませんが、実現の鍵は「ICT の活用」が握っています。つまり「テクノロジーを使ってもっと賢くやろうぜ」「テクノロジーを使えばもっと賢くできるぜ」ということです。
この記事について
この記事では、(特に何千何万という従業員を抱える大企業において)働き方改革を推進するための一つのアイデアを述べます。「"ICT の活用" といっても具体的に何をすればいいかわからない」という方向けに、「たとえばこういうことができますよ」「たとえばこんな風に考える必要がありますよ」という例を示せるものと期待します。
前提
- OS は Windows を前提としています
注意事項
- 主張を単純にするため、あえて断定を用いることがあります
- 本記事が対象とする業種、職種はあえて定めていません
つまり本記事は「私の言うことが絶対的に正しい」と言っているのではなく、「(当てはまらない/当てはまりづらいケースもあるだろうけど)私が思うに、働き方改革ってこういうことですよ」という一つの意見を示しています。
Strong Infrastructure
本記事では Strong Infrastructure について書きます。
Strong Infrastructure とは
Strong Infrastructure とは、何千何万という従業員を抱える大企業における、全社員が誰でもいつでもアクセスできるほど強固なインフラを指します(私の造語です)。具体的なアーキテクチャは無く、概念の話です。
Strong Infrastructure の上で稼働させたサービスは、全社員が誰でもいつでもアクセスできます。たとえば SNS を立てれば全社員が全社員とやり取りできますし、VCS を立てれば全社員がリポジトリを持ち、好き勝手に Fork して、Issue を立てて、Star をつけてといったことができます。これらサービスは可用性も十分整っており、何度もメンテナンスが入るとか、夜間早朝は使えないとか、曜日毎にアクセスできる社員が制限されるとかいったこともありません。
Strong Infrastructure は、一部のクラウドサービスにおいては既に実現されています。たとえばチャットサービスの Slack には Oracle で 14 万人が使っている 事例があります。14 万人という大人数が、誰でもいつでもチャットしてメッセージやファイルをやり取りできるわけです。
Strong Infrastructure が満たすべき AAAF
Strong Infrastructure は Anyone, Anytime, Anything, Flat(AAAF) を満たすべきです。
- Anyone
全社員誰でも利用できる。
- Anytime
全社員がいつでも利用できる。可用性を担保する(担保できるだけの投資と整備をする)ということです。
- Anything
すべての情報が読めるし、何でも書き込める。無論、ルールやガイドラインは必要ですが、承認制などといった不自由はせず、全社員一人ひとりが自由に行動できる裁量を与えるということです。
- Flat
社員から社員にリーチできる。上司の許可無く書き込めない、といったことは無しにします。
なぜ Strong Infrastructure が重要か
場所や時間という制約を超えて、何千何万という数の力を効率的に活かすためです。
最も身近な例はインターネット(上に存在する利用者の多い各種サービス)でしょう。インターネットがここまで発展してきたのは、以下の性質があるからです。
- 誰でも自由に読める(コンテンツを誰でも利用できる)
- 誰でも自由に書ける(多人数の意見や議論が集まる)
- 非同期的(各自が自分のペースで場所や時間に縛られず読める/書ける)
- コンテンツの価値が民主的に決まる(評価が多い/高い = 価値が高い)
Strong Infrastructure とは、言うなればこれのイントラネット版です。従来の縦割り社会や閉鎖的な村社会だけに依存するのをやめ、ICT システム上でもっとフラットかつスピーディーなやり取りと共有を行えるようにしよう、ということです。
Strong Infrastructure に載せるシステム
Strong Infrastructure はただのインフラですが、その上に何かシステムを立てねば意味がありません。
以降では Strong Infrastructure 上に立てるべきシステムとして、以下を紹介します。
- チャット
- フリーソフト
- Q&A
- Issues
- プロフィール
- ブログ
- VCS
紹介の仕方ですが、以下のように現状とその問題点を示した後、それをシステムでどうやって解決するかを述べます。
- 現状
- 現状の問題点
- 解決案
- 解決案に使えそうなソフトウェア・サービス
1. チャット
現状
コミュニケーションと言えば未だメールが主流です。
現状の問題点
メールという前時代的なコミュニケーション手段に頼っていることによる損失です。
まずメールはスピーディーな手段ではありません。Twitter や LINE を使っている方ならばよくわかるかと思います。また、Twitter や LINE が使えたとしてもまだ不十分です。あとで情報を探しにくいという弱点があります。
解決案
ビジネスにおいても Twitter や LINE のようなスピーディーな手段を用意するべきです。加えて、あとで情報を探しやすいという特徴も欲しいです。
解決案に使えそうなソフトウェア・サービス
Slack です。
Slack はチャットサービスであり、一言で言えば「チャンネル(部屋)ごとにタイムラインがあり参加者は誰でも発言できる」という利用イメージになります。用途毎にチャンネルをつくれば、関連する話題に絞って発言を交わしていくことができます。たとえば 部署 A チャンネル、プロジェクト A チャンネル、技術 XXX に関する情報共有チャンネル、雑談用チャンネルをつくって、その中で発言していくわけです。
Slack は使い心地も洗練されており、全世界で 1000 万を超えるユーザーがいます。効率や生産性にうるさいエンジニア集団も多数導入しています。ビジネスチャット界のデファクトスタンダードと言っても過言ではありません。
Slack は分水嶺
Slack を使わないという選択肢は基本的に無いと思います。私は Slack を使うかどうかが、働き方を改革できるかどうかの一つの境界線 だと考えます。
Slack を使うということは、以下を受け入れるということです。
- 働き方を変えるために少なくない金額(月額や年額)を支払い続けること
- 業務情報をクラウド上に格納すること、またクラウド上でやり取りすること
- コミュニケーションツールというクリティカルな手段を刷新すること(移行や学習の手間を受け入れること)
働き方を改革するためには、この程度の行動は必要になります。これができるかどうかが改革の成否を、もっと言えば生存の命運を分けるとさえ思います。あえてこの言葉を使いますが、Slack を使わない会社はヤバイです。
Slack が分水嶺であるという点については、以下も参考にしてください。
参考: Slackはただのコミュニケーションツールじゃない、企業の技術を映す鏡だ - Qiita
2. フリーソフト
現状
信じられないかもしれませんが、大企業では「個人便宜のためのフリーソフト(OSS やアプリを含む)」を利用するのに申請が必要であることが珍しくありません。以下に運用例を示します。
- フリーソフト利用時には原則事前申請を行い、承認されなければならない
- 申請内容は Excel、Word、Wiki などで管理し、申請時は十を超える細かい項目にすべて記入が必要
- 個人的な便宜や改善程度の理由では承認されない
- 申請可否は承認者(部長など)の裁量次第
- 承認者は ICT リテラシーが無く、リスクも負いたくないため承認には否定的
- 申請管理は部署ごとに独立しており、部署 A で使えていたものが部署 B で使えない
- 定期的(たとえば半年や一年)に再申請をしなければならない
SSH 接続で Tera Term を使う時、開発で Visual Studio Code を使う時、ブラウザで Google Chrome を使う時 etc……各自が勝手に使うのが普通と思いますが、これが許されないのです。いちいち申請書に記入して「何に使うのか」「なぜ Visual Studio Code でなければならないのか」といったことを(承認者に分かる言葉で)丁寧に書かないといけないわけです。加えて、一度申請が通っても、部署が変わったらまた申請し直しが必要だったりしますし、何なら定期的に再申請が必要だったりします。
現状の問題点
フリーソフト(OSS やアプリを含む)の恩恵を受けられないことです。
フリーソフトは各自が必要に応じて自由に利用することが当たり前です。そもそも PC を用いた仕事は本質的に複雑になりがちですし、数学のように「あるソフトウェアを前提として別のソフトウェアをつくりあげる」ことも当たり前に行われています。一方で従業員は(能力やスキルから性格まで)多様性に富んでいます。これらを踏まえると、フリーソフトを自由に使えるようにして、各自が必要に応じて、自分に合ったものを使っていくべきであることは自明です。
無論、リスクはゼロではありませんが、リスクはあらゆることに当てはまります。事故で死ぬ可能性があるから、と乗り物に乗ることを諦めるでしょうか。目や手指に負担がかかるからと、スマホを使うことを諦めるでしょうか。フリーソフトを使わないということは、それだけ極端な愚考を犯していると言っても過言ではありません。個人が私生活で使わないのは自由ですが、仕事ではそんな怠惰は(今の時代は)許されないでしょう。少なくとも、すでにフリーソフトを当たり前に使う人たちや、使わないと業務がままならない人たちの邪魔することがあってはなりません。
解決案
「フリーソフトに特化した KM(Knowledge Management)」システムを使います。
良い既存例が無いので、以下「こんなシステムがあると良い」という持論を書いておきます。
システムのイメージ
概要:
- このシステムにはフリーソフト一つ一つに対する専用ページがある
- 専用ページには入手先、承認状況、利用者コメント、いいね評価などが掲載されている
- 検索機能
- アクセス数、コメント数、いいね数などでソートも可能
- あまり詳しくない人でも、人気のあるフリーソフトに効率的にリーチできる
ページの新規(申請):
- ページが無い場合は、誰かが新規(申請)する
- 新規は誰でも行なえる
承認フロー:
- 承認はフリーソフトに詳しい(かつ融通が利く)専用部隊が行う
- 特別な理由(甚大な脆弱性があるもの、ファイル共有ソフト全般、明らかに関係のないゲーム etc)が無い限りは、無条件で承認する
コミュニケーション > ニュース機能:
- 脆弱性の発見やライセンスの変化といったクリティカルなニュースを共有するエリア
- 利用者が勝手に共有してくれることを期待するか、専用部隊を設けても良い
コミュニケーション > フォーラム機能
- フリーソフトに関する相談や議論が行えるエリア
ゲーミフィケーション:
- システムの利用者各々のプロフィールページがある
- プロフィールページには申請数、コメント/いいね数、被コメント/いいね数などが表示されている
- つまり活発に活動していることをスコアリングして表示することで、内発的動機付けを狙う
メンテナの存在
メンテナとは、このシステム上で活発に活動する人のことです。
活動例:
- ニュースやフォーラムで積極的に発言する
- ニッチなフリーソフトや使い方を共有する
- 不適切なコメントに対処する
- ……
他のシステムにも言えることですが、盛り上げと秩序のためにはメンテナが必要不可欠です。メンテナというと難しい響きですが、要するに「盛り上げ役」「監視役」「詳しい人」です。
メンテナには専用のインセンティブを与えてあげると張り切ります。たとえばメンテナだけで食べていくことを許す、貢献度トップクラスには部長級の高待遇を与える等。社内フリーソフトエバンジェリストがあっても良いかもしれませんね。むしろ私がやりたいくらい。
解決案に使えそうなソフトウェア・サービス
ありません。
私の知る限り「フリーソフトに特化した KM」を実現するソフトウェアやサービスはありません。逆を言えば、このようなソフトウェアが今の今まで生まれていないことが、このようなソフトウェアが要らないこと(つまりは管理すること自体が見当違いであること)の証左であるようにも思います。
とはいえ大企業にもなれば、管理をゼロにするわけにはいかないとも思います。専用ソフトウェアが無いとなれば、別のソフトウェアで代替するか自製するしかありません。開発したら流行りますかね。ソリューション化やコンサルなどの応用も効きやすそうですし。
3. Q&A
現状
従業員が時間をとられていることの一つが社内雑務です。
社内雑務とは社内に閉じた雑務作業のことで、たとえば勤怠管理、出張申請、交通費申請、休暇申請、リソース調達、イベントの運営や精算、その他福利厚生に関する申請など多数あります。
現状の問題点
社内雑務の実施、とりわけ不明点について素早く知ることについて、企業は以下のような問題を抱えています。
- 「ググって調べる」のように簡単に答えを知ることができない
- 答えを知るには、分厚く読みづらいマニュアルを読む必要がある
- そもそもマニュアルがどこにあるかもわかりづらい
-
そもそも「"ググって調べる" 程度で簡単にわかるのが望ましい」という世界観を知らない人が多い(社内雑務について知るのに何分何十分かかるのは当たり前だと思っている＆ここを削減できるという発想がない)
- つまりこの問題を認識さえしていない
ここで「人に聞けばいいじゃないか」と思われるかもしれませんが、それでは非効率的ですし非生産的です。聞かれた側がスマートに答えられるとは限りませんし、仕事をしているのにいちいち割り込むのは悪いです(逆に割り込まれるのは煩わしいです)。人に聞けばいい、という安直な怠惰を放置しているうちは改革なんてできません。
※もちろんケースバイケースです。たとえばお互い気心が知れていてゆとりがあるなら、雑談混じりに好きなタイミングで適宜「これどうやるんだっけ」と尋ねるようなやり方でも十分回せると思います。
ピンと来なければ、日常生活で考えてみてください。特に一人暮らしをされている方は家事、各種購入、手続き全般についてネットで調べると思います。調べたらすぐ見つかるので便利ですよね。もしネットで調べることができず、誰かに聞くことしかできなかったとしたらどうでしょう。相当不便だと思います。これと同じことが、社内雑務については平然と放置されているわけです。
解決案
Q&A システムを使います。
Strong Infrastructure の上に Q&A システムを構築すると、従業員は誰でも社内に関する不明点を質問できます。質問とは「出張申請画面のこのフィールドにはて何を入れればいいんだっけ」「メモリ増やしたいんだけど手続きどうやるん？」「XXX コードの一覧ってどこで見れるっけ？」といった簡単なものでも構いません。むしろ推奨します。質問はどんどん溜めます。
Q&A システムの特徴:
- 質問に対する回答が(全従業員という数の力のおかげで)すぐに来る → わからないことがすぐにわかる or そのうち誰かが答えてくれる
- 質問と回答が蓄積されていく → 検索して簡単に辿り着けるようになる
- 質問と回答には評価を行える → 検索時に(評価の高い情報を優先的に表示すれば)価値のある情報≒知りたいことにすぐに辿り着けるようになる
Stack Overflow を知っている人は、その社内雑務版だと考えれば間違いはありません。Q&A というと Q&A サイトの Yahoo!知恵袋、発言小町、あるいは Quora を思い浮かべる方がいらっしゃるかもしれませんが、Q&A システムとして洗練されているのはもっぱら Stack Overflow です。
以下に Stack Overflow の特徴を挙げます。
Stack Overflow が持つ特徴:
- ゲーミフィケーション
- 各人の活動実績を可視化＆バッジなどで「どれだけ頑張っているか」を強調
- 内発的動機づけになる
- メンテナ
- 的を得ない質問や重複した質問などに対処する人が存在する
- 良質な質問と回答のみが集まるよう、数の力で日々メンテするイメージ(Yahoo! 知恵袋など国内 Q&A サイトにはない視点)
要するに「動機付け」と「クオリティの担保」が秀逸なのです。
Q&A を軌道に乗せるために必要なこと
Strong Infrastructure に Q&A システムを載せただけでは活性化しません。全社員に積極的に使ってもらうためには数々の工夫が必要です。いくつか(実運用経験は無いので持論ですが)挙げておきます。
- (1) 発言のハードルを下げる
私は全社員が見れる場所だろうと遠慮なしにあれこれ書くタイプですが、そういうタイプは少数派です。誰もが日頃からネットで情報発信をしているわけではありません。たとえば「書く＝揚げ足を取られるヒントを残す」と捉え、一切書き込まないという口頭主義者もいたりします。
主義志向は人それぞれですが、発言に慣れてない方は慣れる必要があります。大人数に対する働き方を根本から変えるためには、このように「書いたことが残る場所に書く」「誰かが見る(読んだ人の役に立つ)」「誰かが返事する(情報が増える/広がる)」ことで回っていくエコシステムを構築するしかありません。
さて、慣れてない人たちのハードルを下げる方法ですが、あまり決定的な方法はわかりません。「まずは慣れた人が書き込みを増やして雰囲気を和らげる」「練習用のエリアを用意して内輪で試す」などもっともらしいことを泥臭く重ねていくしかないのかなとも思います。
- (2) 動機付けを行う
自ら積極的に質問、回答、評価したくなるような仕組みづくりが必要です。でないと「普段の仕事が忙しいのにやってられるか(便利だから調べる時は使うけど)」という人ばかりになってしまいます。そうなると、そもそも便利に使えるレベルにすら辿り着けません。
Stack Overflow であればゲーミフィケーションだけで十分(ユーザーは何十万という規模ですし意識の高いエンジニアが多数います)ですが、大企業ではそうもいかないでしょう。そこで動機付けです。
といっても私が思いつくのは経済的インセンティブですね。たとえば「メンテナだけで食っていけるような部署を用意する」「上位ランキングには特別ボーナス」などです。
あるいはスタッフ部隊をメンテナにしても良いですね。彼ら彼女らは従来メールや電話で対応していたのが、非同期的に Q&A システムで活動するだけで済むようになります(もちろん迂闊にメールや電話に頼る輩が振り回されないよう既存窓口縮小などの整備も必要ですが)。スタッフ部門のキャリアについても「半年で Vote up を 300 集めることを目指そう」といった、わかりやすい指標を使うことができます(成果主義的なので保守的社員は猛反発でしょうが^^;)。
ともあれ、動機付けのやり方は色々あるはずです。
- (3) 娯楽ネタを封じる
これは賛否両論分かれるかもしれませんが、娯楽ネタは封じた方が良いでしょう。
インターネットを例にすると、人気になるコンテンツは常に娯楽ネタです。Yahoo!知恵袋では関連質問ですぐアダルトネタや恋愛ネタが出てきますし、Quora でもビル・ゲイツがどうだのといった読み物ネタが人気です。
娯楽ネタを封じないと、社内の Q&A システムも同じことになりかねません。価値のある情報≒娯楽として面白い情報、になってしまい、社内雑務を解決する情報にリーチしづらくなります。
かといって、ガッチガチにしてしまうと逆に投稿しづらくなるので、バランスが難しいところです。
- (4)議 論ネタを封じる
これも娯楽ネタと同じく賛否両論が分かれるでしょうが、質問と称して議論をふっかける系のネタも封じた方が良いでしょう。
ふっかける系のネタというのは、たとえば自社の競合である B 社に関するニュース記事を張って「B 社はこうなのにうちはダメだよねぇ」「何がダメだと思います？」みたいな質問のことです。盛り上がることは間違いないですが、社内雑務というナレッジではありません。
(余談) Google のような検索システムは使えないのか
私が思うに、使えません。
Google のような優れた検索システムは Google のみが持っており、またオンプレ用のソフトウェアも提供されていません。もし Google を使いたいのであれば、情報はすべてインターネットに晒す必要がありますが、当然ながら論外でしょう。
かといって検索システムを自製したり、類似ソフトウェアで構築するのも愚の骨頂でしょう。せいぜい「単にキーワード一致した結果を表示するだけの使いづらい検索システム」にしかなりません。
最近では AI による自動回答も盛り上がっているようですが、まだまだ実用的ではないと思います(私が知らないだけかもしれませんが)。
解決案に使えそうなソフトウェア・サービス
ネット上の実例から考えれば Stack Overflow がベストです。
といってもオンプレ版は使ったことですし、大企業における社内雑務用として通用するかはよくわかりません。また、UI の敷居が高いので非エンジニアの方が慣れるコストが高い気もします。
参考:
- Enterprise Knowledge Management | Stack Overflow for Teams
- 「Stack Overflow For Teams」発表。開発チーム内で情報共有するためのQ＆Aサービス。昨夏発表しつつも開発に失敗し、名前を変えて再出発 － Publickey
少し古いですが、ヤフーでは Confluence を用いて社内 Q&A を実現しているようです。
ちなみに OSS もいくつかあります。
- Erudika/scoold: A Stack Overflow clone written in Java (self-hosted)
- q2a/question2answer: Question2Answer is a free and open source platform for Q&A sites, running on PHP/MySQL.
4. Issues
現状
全社的な改善や改革は、専用部隊を設けてそこに任せるという形態が主流です(主流だと思います)。
現状の問題点
- 従業員の意見を集める機会が乏しく、活動が専用部隊(あるいは部隊を統括するトップ)の自己満足になる
- 透明性が無く、どの改善や改革がどこまで進んでいるのかがわからない
- 改善案や改革案がまとまってもコミットメントが無いため進捗が遅い、どころかいつの間にか自然消滅する
解決案
Issue システムを導入します。
Issue システムとは、Issue(Ticketと呼ぶこともあります) を管理するシステムです。私の造語です。Issue は「話題」「課題」といった意味があり、ソフトウェア界隈では主にソフトウェアのバグ・課題・要件等の管理を行うために用いられています。一つ例を挙げましょう。
これは Go 言語の Issue です。いろんな Issue が投稿され、一件一件に対して対応内容や進捗などが議論・更新されていることがわかります。
この Issue システムを、全社的な改善や改革用途で用います。具体的には以下のイメージになります。
- Issue システムを Strong Infrastructure 上に立てる
- 全社員
- 誰でも意見を投稿する(Issueを立てる)ことができる
- 誰でも Issue に対してコメントを書ける、また評価(VoteUp/VoteDown や Emoji など)もできる
- 改善改革を行う側
- 評価の多い Issue から優先的に対応する
- 対応開始後の期限、アサイン、その他過程や進捗は適宜更新する
- 対応しない/できない Issue については、なぜしないのか/できないかの理由をちゃんと書いた上で Close する
- メンテナ
- 改善改革と無関係なネタや重複ネタなどを適宜対処する人を用意する(or ユーザーの善意に任せても良いが)
つまり Issue システムにより全社員誰でも意見を言える/評価投票できるようになり、かつ「各対応の状況」や「改善改革を行う側の事情や好み」なども可視化されます。
解決案に使えそうなソフトウェア・サービス
GitHub Issues です。
Issue システムは多数存在しますが、世界中で最も実績があり、使いやすいのは GitHub Issues だと私は思います(技術者向けなので見た目や操作感の敷居は高いですが)。この GitHub Issues ですが、GitHub の一機能なので、GitHub を利用できるようにする必要がありますが、クラウド版とオンプレ版があります。
- GitHub.com (クラウド版)
- GHE こと GitHub Enterprise (オンプレ版)
GitHub.com はたまにダウンしますし、アカウント自体はワールドワイドに晒されてしまう(晒されない手段もあるんでしたっけ？)ので、安定と閉鎖性を求めるなら GHE でしょう。しかしお値段は安くありません。
他の手段としては、以下があります。
他にも探せば色々あると思います。
5. プロフィール
現状
従来の働き方は「人材を画一的に扱う」ことでしたが、昨今では通用しなくなりつつあります。長所短所、業務経験、勤務地、働き方などは人それぞれであるため、各々を尊重した方が良いのではないか、というのが最近の主流です(主流だと思います)。
現状の問題点
- どの部署やチームで働けるかは運ゲーの様相を呈している(人材を表面的にしか見ない人事や上司の一任で決められてしまう)
- 「～～な人材が欲しい」場合に、簡単に探すことができない
- 「～～ならできるのに」という人が自己アピールできる場所がない
解決案
プロフィール共有システムを Strong Infrastructure 上に立てます。
既存のソフトウェアは思い浮かばないので、私の案をまとめておきます。プロフィール共有システムは以下のようなシステムです。
- 全社員各々のプロフィールが載っているシステム
- 全社員誰でも閲覧できる
- 全社員は自分のプロフィールを自由に編集できる
- 全社員は他の社員に直接コンタクトを取ることができる
- フォロー/フォロワー機能
- 全社員を対象に検索する機能(条件指定で絞り込みも可能)
編集フィールドについては以下のようなイメージです。
- 編集不可能なフィールド(人事情報等から自動反映されるもの)
- 名前
- 顔写真(ここは賛否両論激しいかも)
- 所属
- ……
- 自由に編集できるフィールド
- 強みや弱み
- 働き方の宣言(勤務時間、勤務場所、やりたい仕事/やりたくない仕事 etc)
- 求職ステータス(求職に積極的、好条件なら異動可、現状に満足している etc)
- 主要な成果(URLを張れると良い)(他の Strong Infrastructure 上システムの成果を直接表示できたらもっと良い)
- ……
- その他自己アピールや特記事項全般
つまりプロフィール共有システムとは社員の自己アピール、社内転職、お仕事探しなどを支援するシステムです。画一的な扱いや運ゲー配属から脱して、自分に合った場所やスタイルで仕事できるようにすることを実現できうるものです。
解決案に使えそうなソフトウェア・サービス
ありません。少なくとも私は知りません。
何らかのシステムで包含できそうな気はしています。SNS などですね。ただ、SNS は機能過多であり、「社員の自己アピール、社内転職、お仕事探しなどを支援する」ことに特化しづらいので、個人的には微妙かなと思います(あるいは運用次第でしょうが)。
6. ブログ
現状
自ら能動的に情報発信を行う社員はあまりいません。
また、発信したくても、発信できる場所や機会(さらに言えば時間/権限/裁量など)が与えられていないために発信できません。
現状の問題点
- 汎用的なノウハウが発信されないため、同じことで苦しむ社員が生じている
- 社員が意見をあげない(あげる場所がない)ため、改善や改革のヒントや本質がトップや専用部隊に伝わらない
- 実務よりもコンテンツ提供が得意な社員が生かされない
解決案
ブログシステムを Strong Infrastructure に立てます。
イメージとしては「はてなブログ」が近いです。あれの社内版を実現します。ただし、ブログだけだと価値のある情報にアクセスしづらいので、検索機能の他、ランキングや「はてなブックマーク」のように「価値のある情報にアクセスしやすくする仕組み」も必要です。
ブログシステムのイメージを以下にあげます。
- 全社員誰でも自分のブログを持ち、自由に情報発信できる
- 全社員誰でも他の社員のブログを閲覧し、コメントを書いたり評価(いいね等)したりできる
- 検索機能があり、全社員の全ブログから検索が行える
- その際、高評価＝価値の高い情報を優先表示するなどの絞り込みが行える
- ランキングなどゲーミフィケーションを導入し、社員の情報発信モチベーションを高める
ブログが扱うコンテンツですが、Q&A とは違って、幅広くさせます。その方がハードルも下がりますし、盛り上がりやすいです。ただし政治やアダルトなど主義思想や娯楽の強いものは避けます。例をあげると、以下のようになるでしょうか。
- 技術的な話題
- 機密性のある技術的話題(会社製品に関するノウハウ等)
- 会社に対する提言
- 社内雑務に関するノウハウ
- 日報
- 日記
- ……
もうひとつ、重要な視点が「実務よりもコンテンツ提供が得意な社員」を活かすことです。
会社はえてして実務能力を重視しがちですが、それでは改善や多様性は養われません。幸いにも、実務よりもコンテンツ提供を得意とする社員が存在するはずですから、彼ら彼女らに盛り上げてもらうと良いと私は考えます。たとえばライフハックや自己啓発に長けた人や、最新の OSS や業界動向に詳しい人がいても良いと思います。むしろブログ執筆を専任にしても良いくらいです。
解決案に使えそうなソフトウェア・サービス
これだ！というものは思い浮かびません。
理想は「はてなブログ」ですが、オンプレ用のソフトウェアは提供されておらず、プライベートなクラウドとして使うこともできません。
SNS システムには日記機能こそありますが、これは簡易的なものであり、上述したブログシステムのイメージを満たさないので役不足です。
前述した GitHub でもブログシステムは実現できますが、自前でビルドする必要がある、黒い画面を使う必要がある、設定ファイルを編集する必要があるなどハードルが高いのが難点です。ハードルが高いと、リテラシーに長けた人やエンジニア以外には使いこなせません。
7. VCS
VCS とはバージョン管理システム(Version Control System)のことです。ソースコードやドキュメントの変更履歴を管理したり、複数人で分担して編集＆マージしたりするのに適した手段です。CVS、SVN、Git などが知られています。
現状
- バージョン管理をしていない
- バージョン管理はしているが、CVS や SVN を使っている
- Git でバージョン管理しているが、バイナリファイルをそのままアップロードするなど単なるファイル置き場として使っている
- リモートリポジトリがチームや部署に閉鎖している
現状の問題点
以下二種類の損失があることです。
- バージョン管理しないことによる損失
- リモートリポジトリが閉鎖的であるがゆえの損失
以下詳しく見ていきます。
1. バージョン管理しないことによる損失
歴史的に最も優れたバージョン管理である Git があるのに、それを使っていないことによる損失です。
Git やバージョン管理について説明しだすと長大になってしまうので、ここではたとえを使います。
まずバージョン管理の歴史は以下のようになっています。
- 1: ソースコードの変更履歴を管理しない
- 2: ソースコードの変更履歴を手作業で管理する
- 例1: 文書やコメント中に日付や更新内容を書き残す
- 例2: XXXX_01、XXXX_02、XXXX - コピー のように複製して残す
- 3: ソースコードを CVS でバージョン管理する
- 4: ソースコードを SVN でバージョン管理する
- 5: ソースコードを Git でバージョン管理する
これは乱暴にたとえるなら、以下のように言えます。
- 1: 何も使わない
- 2: 黒電話
- 3: ポケベル
- 4: ガラケー
- 5: スマホ
スマホの利便性を知っている人は、ガラケー以下を使うなどありえないと思うのではないでしょうか。多少勉強してでもスマホを使うべきだと思うのではないでしょうか。同じことが Git にも言えます。歴史的に Git は最も優れたバージョン管理なのだから、これを使わない手はないです。
たとえばかりですみませんが、Git でバージョン管理しないということは、「別に電話がなくても出張とかして口頭で喋ればよくない？」とか「アプリってのはよくわからんけどガラケーで通話はできるんだし十分じゃね？」などと言っているようなものです。スマホという利便を知らないがゆえに、前時代的な不便に頼り続けることになります。
2. リモートリポジトリが閉鎖的であるがゆえの損失
まずはじめにリポートリポジトリについて簡単に書いておきます。知っている方は飛ばしてください。
Git にはローカル/リモートという概念があります。ローカル(手元)で各自が変更履歴を管理しつつ、出来上がったものはリモート(中央サーバー)にアップロードする、というモデルです。これによりリモートにマスターを集約して共有のしやすさと統一性の担保を実現するとともに、作業時は各自ローカルにダウンロードして各自のペースで作業できるという自由度を実現しています。……説明はこのくらいにして、本題に入ります。
Git のリモートリポジトリですが、チームや部署といった単位で閉鎖的に運用されていることが多いです。無論、扱うファイルによっては閉鎖的でなくてはなりませんが、閉鎖的だと問題となるケースがあります。それが 全社的に共有したい時 です。
有益なソースコード(もっと言えばツールやスクリプトやアプリ)やドキュメント(技術的なノウハウや手順書に限らず何らかの役に立つ文章全般)は、社員全員が見れる・編集できるに越したことはありません。その方が発展しやすいです。OSS はまさにそうですよね。
リモートリポジトリが閉鎖的だと、この恩恵がありません。この恩恵を授かるためには、全社員が誰でもアップロード・閲覧・ダウンロードできる規模のリモートリポジトリが必要です。
解決案
Git と GitHub を使います。
Git はバージョン管理システムのソフトウェアです。各人の PC にインストールすると、ローカルリポジトリが扱えるようになります。
しかしローカルだけだと他人と共有できないので、リモートリポジトリ(サーバーやプラットフォーム)を用意する必要があります。リモートリポジトリの手段としてデファクトスタンダードなのが GitHub です。
GitHub を導入すると、全社員は Git という共通言語でソースコードやドキュメントを管理できるようになります。学習コストは易しくないですが、手作業による管理よりも何倍、何十倍と楽できます。また、社員全員に対して共有することも可能となります。目まぐるしい発展を遂げてきた OSS のような世界を、社内でも実現できます。
解決案に使えそうなソフトウェア・サービス
Git と GitHub です。
使うためには以下の下準備が必要です。
- 各人の PC に Git クライアントをインストールする
- 各人が push/pull を行えるリモートリポジトリプラットフォームを整備する
- 例1: GitHub.com を使う
- 例2: GitHub Enterprise などをオンプレで運用する
- リモートリポジトリプラットフォームとしては以下を準備する
- 1: 関係者のみが見れる単位のプラットフォーム(チーム内、部署内など)
- 2: 社員全員が見れるプラットフォーム
ちなみに GitHub は 2: を実現したものですが、別途アクセスコントロールを行うことで関係者のみが見れるエリアをつくれます(つまり 1: も実現できます)。
おわりに
大企業の働き方改革案として Strong Infrastructure というコンセプトを紹介し、7 つほど具体的なシステムについて述べてみました。
長々と書きましたが、要はインターネットやオープンソースのようにオープンで、自由で、インタラクティブで、透明性の高い仕組みを活用しようというだけの話です。ソフトウェアエンジニアの方なら、既に当たり前に触れている概念や手段でもあります。
これらを大企業で導入するハードルの高さは想像に難くないですが、これくらいしなければ改革はできないのではないか、と一大企業社員の私は思います。