- スペシャルコンテンツ
- 一万改善プロジェクト
一万改善プロジェクトが存在しなかった頃、全員が、こう思っていました。
「個人もチームもビジネスモデルも、もっとレベルアップさせたい」「仕事への取り組み方も、社内の環境も、まだまだ見直すことができるはずだ」と。
しかし、具体的に案を出す人はいませんでした。仕組みがなかったからです。走りながら考える癖の付いた私たちには、そうした改善活動に充てる時間はほとんどないようにも思えていました。だから、「これをこうしたほうがいい」という問題意識や課題意識を鬱憤に変えてしまう社員もいたのです。
このままではいけないと、代表や部門管理者が話し合いをしました。会社は経営者のものではなく、みんなのもの。新人もベテランも関係なく、誰もがフェアに意見できる仕組みをつくろう。「時間がない」は言い訳だ。
こうしてリスペクトの“一万改善プロジェクト”が誕生しました。発案から完成までは、本当にあっという間でした。
一万改善プロジェクトは、社員一人ひとりが会社の根幹に関わることのできる仕組みです。全社員に会社をより良くする使命があり、その気があれば誰でも主役になることができます。
リスペクトでは社員が会社の一員であることを自覚し、改善投稿の仕組み自体の改善を繰り返しながら、業務の効率化や生産性の向上を図るための改善案、新規事業のアイディアを投稿し続けています。
リスペクトにある機会平等の文化の根底には、一万改善プロジェクトがあるといっても過言ではありません。全社員の案が会社の代表と上層部から直接評価されるシステムを持った会社はあまりないでしょう。代表も部門管理者も、膨大な時間をかけて一つひとつの改善案を審査します。それだけに評価基準は厳しいですが、採用されればリスペクトの新たなルールや事業となります。
ただし、一万改善プロジェクトは新規事業コンテストでもなければアイディアコンテストでもありません。採用がゴールなのではなく、ルールとして根付かせ運用させる必要があります。自分の改善案を実行するためには自分で計画を立て、必要であれば他部門の人間を巻き込み、責任を持って遂行しなければなりません。しかし、個人には改善案のオーナーになれる資格と、職種や立場による制約を受けない裁量権が与えられるという大きな特典があるのです。
これまでに投稿された改善案は3,000件強。そのうち約300件が採用され、実行されています。一万改善プロジェクトを運営し続けることにも、改善案を実行することにも、もちろん苦労は伴います。しかし、それを乗り越えてこそ、より良い会社が実現します。一万改善プロジェクトにまつわる多くの社員の物語が、現在のリスペクトを形づくっているのです。
- スペシャルコンテンツ
- 一万改善プロジェクト
プロジェクトを支える
縁の下の力持ち
一万改善プロジェクトになくてはならないものがある。それが“改善投稿システム”だ。これは社員全員が改善案を投稿・閲覧でき、然るべき人間が管理・評価できるようにプログラミングされたリスペクト独自のシステムだ。
このシステムを設計し、プログラミングしたのは、当時リスペクトに入社したばかりのWebプログラマー、木村だった。会社標準のフレームワークに慣れるという目的もあったが、新人であるにもかかわらず社内プロジェクトの根幹となるシステムの構築を担わされたことに、木村は燃えた。
もちろん、プレッシャーを感じなかったわけではない。しかしそれ以上に、初めて設計から任された仕事がうれしくて、自分の思うようにプログラミングできたことが楽しかった。
改善案を審査するフローが固まるのを待ちながらの作業となったが、設計からコードを書き上げるまでは1ヶ月しかかからなかった。その仕事ぶりに対して、「今ならもうちょっと早くできるかもしれません」と木村は謙遜している。
ひとまずシステムをリリースすることができ、木村はホッとした。ほかの社員たちからは褒められた気もするが、とにかく「成し遂げた」という達成感のほうが大きかった。ゼロからひとりですべてをつくる、ゴールまで辿り着くという経験は、木村にとって新鮮なものだった。
「自分のつくったシステムを誰かに使ってもらってるところなんて、なかなか見られないじゃないですか？だから、みんなが使ってるのを見て、普通にうれしかったです。まあ、かなりハラハラドキドキでしたけど（笑）」
社員は木村を存分に労った。存分に労ってから、大量の注文を付けた。
「こうしてほしい」「ここが使いづらい」「これはどうにかならないの？」
最初にリリースされた改善投稿システムは、決して使いづらくはなかった。ただ、決して使いやすいともいえなかったのだ。木村はこれまでユーザーインターフェースを考慮したプログラミングを行ったことがなかった。普段の業務であれば役割が異なるため、それでも問題はない。ところがこれは社内プロジェクトだ。協力者はいるが、改善投稿システムのプログラミングは木村ほぼひとりに任されている。
木村はフロントエンドエンジニアやシステム部門の管理者など、多くの人にアドバイスを請うた。悪戦苦闘した。次から次へと要望が来た。それでもスピーディーな対応でシステムを改良していった。木村にとってのこの仕事は、ユーザーの使い勝手を考慮しながらプログラミングをすることの重要性を知った機会でもあった。
社員からの意見を反映することで改良を重ねた改善投稿システムは、一万改善プロジェクトの根幹を担うものと全員に認められることで、真の完成を見たのだった。
「そのあとも実はちょいちょい直してるんです。もっと良くできるはずだし、今後もこの会社で使われていくシステムだから」
木村の手によって完成されたリスペクト独自の“改善投稿システム”は、日々ブラッシュアップされながら、今も一万改善プロジェクトを縁の下で支えている。
- スペシャルコンテンツ
- 一万改善プロジェクト
挑戦できる環境を
なくしてはならない
飛び抜けた発想力と、他者が気付かない課題への鋭い目を持ち合わせている人物といえば、ディレクターの吉田を置いてほかにはいない。代表の小原をして「一万改善プロジェクトの質を高めた」と言わしめた数々の改善案は実に独特で、誰が真似できるようなものでもなかった。なぜそこまで突飛なアイディアを次から次へと出すことができるのか。この問いに対し、吉田はこう答えた。
「突飛だとは思ってないけど、まじめに考えるのはつまんないね」
まるで天才のそれのように見える発言の裏には、実は吉田が日頃から行っている情報収集という努力が隠されている。仕事中も、休憩中も、休日も、彼はポケットに“ネタ帳”を仕込んでいる。リスペクトという会社を良くするために、もっと楽しくするために、吉田は常日頃からアイディアの種を収集しているのだ。
提案者としても然ることながら、吉田は管理者としても一万改善プロジェクトを牽引してきた。ディレクター部門の管理者である彼は、部門管理者による審査会議で社員の改善案を評価する立場にもある。
改善投稿システムにも審査フローにも綻びがないように思える一万改善プロジェクトだが、一度も立ち止まらずに運営されてきたわけではない。改善案の考案と投稿は限られた時間で行わなければならないため、個人の負担も大きい。投稿する側も審査する側も、どうにか時間を確保しなければならず、大変な思いをしている者も多かった。「もうやめようか」という代表や管理者たちの言葉を何度も耳にした。しかし吉田は、その言葉を聞くたびに「やめるわけにはいかない」と主張した。
かつて、制作系やマネジメント経験のない新人たちからの投稿が止まったことがあった。それは具体的なスケジューリングや人を動かすことに慣れていなかったためだ。そのときも吉田はなかなか採用されない人の案をブラッシュアップしたり、視点を変えさせたりという部門全体で協力する体制を構築し、全社に浸透させることで壁を乗り越えた。
吉田は一万改善プロジェクトについて、こんな想いを抱いている。
会社の根幹に関われるこの社内プロジェクトに、全員が参加してほしい。これほど完成度の高い改善投稿システムと評価の仕組みがあるのに、それを利用しないのはもったいない。これはリスペクトで社員に与えられている最も大きな権利だ。やめるわけにはいかない。
「一万改善プロジェクトは時間がかかるから大変だよ。でも、あるとき改善のルールを考えてるほうが楽しいと思う瞬間があったんだよね。普段やってるのは“業務”で、これが“仕事”なんじゃないかって」
自分で考え、自分で提案する。挑戦できるこの環境をなくしてはならない。吉田は改善のマインドを持つことの重要性を、情熱を持って訴え続けている。
- スペシャルコンテンツ
- 一万改善プロジェクト
会社の組織体を変えた
小さな問題意識
早坂はリスペクト初のチェッカーだ。入社当時は先輩も同僚もおらず、コーダーの一員という立ち位置だった。チェッカーという職種自体が未完成だったのだ。
チェッカーの仕事を簡単に説明すれば、制作が完了したコーディングデータに不具合がないかを検証・確認する役目だ。これにはチェック表が必須となる。早坂がチェッカーになったばかりの頃にもコーダーが使用していたチェック表は存在していたが、どうしてもそれが非効率に見えてならなかった。
当時、チェック表は2つあった。ひとつの案件に対し、2人がかりでチェックしていたのだ。早坂は2つのチェック表を統合したうえで、1人で行えるよう業務の効率化を図り、最新の案件にも対応できるように更新したいと思っていた。しかし、その考えを周知できなかった。自分の考えが最善ではない気がしていたからだ。悶々とするうちにチェッカーの数だけが増えていった。
そんななか、一万改善プロジェクトが始まるという告知があった。自分が投稿した改善案やアイディアが、代表やすべての部門管理者から評価されるらしい。「これだ」と思った。さっそく投稿した。初投稿の改善案は、しかし採用されなかった。
早坂の案は2つのチェック表を統合することで業務を効率化し、最新の状態に更新するというものだった。チェック項目の洗い出しを含め案件の特性ごとにつくり直さなければならず、完了までには半年もかかる。
そもそもチェック表が2つあったのはユーザー目線と技術的な目線からチェックを行うためで、ダブルチェックの意味も込められていた。チェックの質や精度が落ちるのではないかという懸念もあった。
“ミスを見つけ出す”という点から考えれば懸念は当然のものかもしれない。しかし、早坂が考えていたのは“ミスが起きる原因を探り、防ぐ”という、制作の体制を根本から改善するものだったのだ。
不採用が続いても、早坂は同じ内容を微調整して再投稿を繰り返した。同じ数だけ不採用の烙印が押されて戻ってくる。評価側の人間たちは当時を振り返り、「毎回同じ投稿内容で本当にしつこかった」と口をそろえる。当の本人はいたって前向きだった。
「問題に気付いた私自身がどうにかしなきゃ、どうにかしたいと思ったんです。でも、自分で考えた案じゃ不十分な気がして不安でした。だから、一万改善プロジェクトでいろんな人から知恵をもらえて、本当にありがたかったです」
早坂はチェッカーという仕事に誇りを持っていた。チェッカーの仕事は、チェッカーである自分が改善していかなければならない。それが、早坂が自分自身に課した使命だった。
当初は他部門からチェッカーの重要性をよく理解されていなかったということもあり、何度も同じ案を提出する早坂に半ば呆れている者も多かったが、ついに評価側も彼女の執念に折れた。詳細な計画書の提出を条件に採用されることになったのだ。
このときはまだ誰も、早坂本人も知らなかったが、この改善が多くの部門に好影響を与え、リスペクトの組織体を変えることになった。
チェッカーの業務効率が上がったことは予想通りだったが、それ以上に、制作を行うコーダーの質や精度までも高めたのだ。
早坂のチェックに対する問題意識がなければ、チェッカーはずっとコーダーの末端だったかもしれない。それが今や単なる制作物のチェックだけでなく、ミスが起こる原因の改善や対策を行う「品質管理」という独立した部門となるまでに成長を遂げたのだ。これは間違いなく、自分の仕事に誇りを持ち、自分の力で自分の仕事を改善しようとした早坂の執念が生んだ結果だった。しかし、品質管理部門に昇華させたことで挑戦が終わったわけではない。より良い管理体制を構築するための早坂の研鑽はこれからも続いていく。
