ZOZOSUITをレモンスカッシュにしたのは大英断だと思う理由

こんにちは、大石です。

みなさん、もうZOZOSUITはオーダーされましたでしょうか？ 無料で自分の身体のサイズを正確に測定できると言うことに加え、全身にセンサーが埋め込まれた近未来的なデザインということも話題になり、普段ZOZOTOWNのユーザーでない方でもオーダーされた方は結構いらっしゃったのではないでしょうか？ かくいう私もその口で、発表されるや否やすぐ登録して到着を今か今かと待ち望んでいましたが、結局半年経っても届くことはなく半ば諦めムードが漂っていたところに「センサーはやっぱりやめます。今度はドットが書かれたピチピチタイツにしますー」というニュースが飛び込んできた、というのが現在の状況です。

  元々発表時のデザインが 近未来的でサイバーなデザインに加え、ビジネス的にも「ザ・IoT」というコンセプトが興味をそそるもので、非常に期待が高かったわけですが、これが

こうなってしまったのは残念、という感覚は理解できます。 ネットでは「レモンスカッシュ」という声があがっているようです。 言い得て妙ですね・・・

ですが、これは以下3つのポイントから、非常に素晴らしい、イノベーションともいえる大英断だと私は考えました。

ZOZOTOWNのビジネスとして

当たり前ですが、センサーとバッテリーが埋め込まれた衣類を大量に配布するというのは、普通に考えて悪夢です。故障や異常、バッテリー切れ、スマホとの接続サポートなど、考慮すべきことが信じられないほど多く「ユーザーの身体のサイズを正確に測定する」という目的に対して合理的な選択なのか、傍目で見ても疑問が残りました。 それに対して、今回配布するものがドットがプリントされただけの衣類になりますので、大量に生産でき、コストも大幅に削減でき、かつアプリのバージョンアップによってできることも増えます（センサー内蔵の場合、センサーの性能や場所以上のことはできません）。ソフトウェアのバージョンアップでユーザー体験が継続的によくなる、という点でも、センサーを廃したことはZOZOTOWNのビジネスにとって大きなプラス要因になりそうです。

ITの潮流として「センサー ＜ 画像解析」

そもそもITの潮流として、「センサーで分かることもあるけど、今は画像で分かることが増えてきたので、できるだけ画像から分析することを優先しよう」という流れになってきていると感じます。 実際、昨年のAWSカンファレンス re:Inventでも、IoT事例よりも「画像解析」による事例の方が大きなウェイトを占めていました。例えばNFLでは、全てのゲームのイベント分析（パスキャッチ/インコンプリートの判別や、どの選手がどのように動いたのかの分析等）に、AWS＋動画解析を使っているそうです。従来は、ボールとフィールドにセンサーを仕込んで、そこから得られたデータを元に分析、という流れが多かったように思えますが、今はリアルタイムに動画を解析することも（AWSの様なクラウドを利用すれば）実現可能なので、そちらに寄せているとのこと。他にも、JFK空港で顔認証によるゲート通過を実装している事例や、キックボクシングでの応用例など、画像・動画の解析で分かることはそちらでやる事例が増えているようです。 ZOZOSUITの仕様変更も、こうした流れに沿ったものと言えます。

エコシステムの拡大

もう一点、「レモンスカッシュアプローチ」が画期的だと思う点として、これを使えば「身体のサイズ測定だけでなく、身体の動きも正確に測定できる」という点にあります。 例えば（想像すると若干滑稽ですが）100ｍ走のランナーがこれを着て走れば、筋肉の収縮と動作が同時に測定できますので、より速く走るためのフォーム改造と筋肉量の変化が効率よく測定できそうです。ゴルフのスイング改善にも効果的でしょうから、このスーツを着させて専用アプリでスイング計測を行うゴルフスクールなんかも出てきそうです。フィットネスクラブでは「ZOZOSUITのお腹のドットが楕円→円になることをコミットします！」なんてこともできそうです。 もちろん、身体のサイズはプライバシーの中でも非常にセンシティブな情報ですから取扱は注意が必要ですが、敢えてスーツとアプリを分離することで、ZOZOSUITを中心としたエコシステムの形成も期待できます。これは非常に大きなイノベーションになりそうです。

普通に考えるとここまで準備してきたものを全てキャンセルして（報道によると、ZOZOSUITの前バージョンのキャンセルのために40億円もの特損を計上するようです）、しかもネガティブなデザイン変更で消費者の拒否反応があることは明らかだったにも関わらず、ビジネスがスケールする方向に舵を切るという判断は、並大抵のことではないように思います。 トルコのことわざで「間違えたと思ったら、どれだけ遠くへ行っても引き返せ」というものがあるそうですが、まさにこれを地で行く判断に感服せざるを得ません。

イノベーションには反対意見や拒否反応がつきものです。ですが、レモンスカッシュアプローチはZOZOTOWNの未来にも、日本のITにも非常に大きなプラスの効果をもたらすものと思います。これからのITの行方を占う上でも、スタートトゥデイの英断に拍手を送り応援したいと思います。

ですが、剛力彩芽さんの件は許せません！！！

JAWS DAYS 2018にいってみた - コミュニティと会社

こんにちは。大石です。

いやぁ、JAWS DAYS 2018 すごかったですね。 コミュニティのイベントで1,400人近く集まるというだけでもすごいですが、会場の熱気も、その後の懇親会も、熱量がハンパではありませんでした（ASCIIさんなどでまとめ記事も上がっていますので、そちらもご覧下さい）。

サーバーワークスからもJAWSのメンバーやスタッフが10名くらい、一般参加者として来場したメンバーも含めると20名近くが参加して、盛り上がりに一役買えたのでは無いかと思います。

恒例となるAWS Samuraiも発表されたましたが、武闘派CIOとして私も尊敬するフジテックの友岡さんが選出されたり、われらがサーバーワークスからも、今回のJAWS DAYSの実行委員長を務めた森さんが選出されるなど、納得のSamurai選出だったのではないかと思います。

よく「サーバーワークスさんって、お金にならないコミュニティによくこれだけコミットできますよね？」と言われるのですが、私に言わせると「会社もJAWSもどっちもコミュニティなんだから、発展に貢献するのは当然」という感覚です。

会社は最後のコミュニティ

よく私は、社内で「会社って最後のコミュニティだ」という言い方をします。2-30年前は、親戚付き合い、近所づきあい、会社という3つのコミュニティがあって、それぞれに様々な役回りがあった。会社では偉そうにしていても、親戚では下っ端という様なことが普通に起こり得たわけです。 それが今は親戚付き合いは減り、近所づきあいはほぼ無くなった。コミュニティらしいコミュニティは会社だけになってしまった、という意味で、私はこれを あまり良くないこと というニュアンスでこのような言い方をしています。1つの役回りに固執してしまうと、考え方や行動がそれに縛られてしまい、柔軟さや想像力を失わせることになると思うのです。有名なスタンフォード監獄実験というものがありますが、長い間「自分は看守だ」と思い込んでいると、行動も（自分の本来の個性とは関係なく）看守として振る舞うようになってしまうということは、会社でも言えるように思います。 いろいろなコミュニティに属して、それぞれの役割を演じることで、客観的に自分の行動を見えるようになったり、会社というコミュニティを離れて社会的なイノベーションや貢献に想いをはせたりすることができるのではないかと思うのです。 ゲーテが「母国語しか知らない者は母国語すら知らない」と言ったそうですっが、そのロジックを借りれば「会社しかしらない者は会社すら知らない」となるでしょうか？いろいろなコミュニティに足を突っ込むことが、実は自社のように「今自分が所属しているコミュニティのことを客観的に判断する」ことの手助けになるように思うのです。

会社として「JAWSを盛り上げよう」などというお願いはしていませんが、当社のメンバーは「コミュニティあってのサーバーワークスだ」ということが肌感覚で分かっているのだと思います。みんなバランス良く、それぞれのコミュニティに属して、どちらも盛り上がるように貢献してくれている。その結果がこのような行動になっているのだと私は解釈しています。

What’s next?

次の大きなJAWSのイベントは 2018年11月3日の JAWS FESTA＠大阪です。 ぜひみなさんで参加して、そして興味のある方は運営やボランティアにもチャレンジしてみて、「普段気づいていないけど自分もコミュニティの一員なんだ」ということを実感して頂ければと思います！

新年のご挨拶（2018年元日）

みなさま、明けましておめでとうございます。旧年中に賜りましたご厚情に、厚く御礼申し上げます。

2017年もお陰様で順調に成長することができました。これも、日頃より当社をご愛顧くださっているお客様、パートナーのみなさま、素晴らしいサービスを提供してくれているアマゾンウェブサービスジャパンの皆さま、そして成長を支えてくれている社員とそのご家族の皆様と深く感謝致しております。この場をお借りして厚く御礼申し上げます。

昨年を振り返ると、私たちの事業にとっては「三菱東京UFJ銀行ショック」が一番の大きなニュースだったのでは無いかと思います。それまでクラウドのセキュリティやサービスの継続性といったところで二の足を踏んでいらっしゃった方々が、一挙にクラウドにシフトされるとともに、この報道以降「クラウドのセキュリティ」という話を聞く機会が圧倒的に少なくなりました。その点でも、振り返れば「2017年はエンタープライズ用途でのクラウド利用元年」と言える年になったのではないかと思います。

サーバーワークスもお陰様で４年連続プレミアコンサルティングパートナーに認定され、「エンタープライズ向けAWS専業」という独特なポジションが少しずつ認知されてきたのではないかと自負しております。また、昨年は「はたらきかた改革元年」ということもあり、「クラウドを活用して、あたらしい働き方を模索したい」というニーズも急激に増えた年でもありました。

私たちは「クラウドで、世界を、もっと、はたらきやすく」というビジョンを掲げておりますが、2018年はこうした流れが更に加速するものと考えております。少しでも多くの方にクラウドのパワーを届けて、クラウドによって場所と時間の制約から解放される、新しいはたらき方を拡げることができればと願っております。

今年もどうぞよろしくお願いいたします。

Amazon ConnectとCloud Automatorを接続して、電話からAWSを操作してみる（Advent Calendar 9日目）

★この記事は「Cloud Automator Advent Calendar 2017」の 12/9 日分のエントリーになります

こんにちは、大石です。

みなさんAWSのサービスは何がお好きですか？ いろいろありますが、私が今一番エキサイトしながら触っているのが「Amazon Connect」です。電話もAWSでできちゃうんです！ 2008年当時、私たちはAWSが出てきたので「サーバー購入禁止令」を引きましたが、今度はConnectのおかげて「電話購入禁止令」が出せそうです！ このAmazon Connect、「コンタクトセンターのクラウドサービス」と銘打たれていますが、コンタクトセンターだけでなく様々なアプリケーションとの連携も可能です。今日は「Cloud AutomatorとAmazon Connectとを接続することで、電話によるAWSの操作にも使える」ということを試してみたいと思います。

Cloud Automator側の準備

•  （何でも良いのですが）Cloud Automatorのジョブを作ります
  • トリガーは「HTTP」を選びます
  •  アクションは今回は「EC2インスタンスを起動」を選んでみましょう
•  ジョブを作成すると、このジョブ専用のエンドポイントが作成されます。
  •  ジョブの一覧から「詳細」をクリックして
  •  以下の画面にある「トリガー」のURLと「アクセストークン」を記録しておきます

Lambdaの準備

次に、 電話のボタンが押された際に今作成したCloud AutomatorのジョブをHTTP(S)経由で呼ぶLambdaを用意します。

• Lambdaのコンソールから requestCaJob という名前でLambdaを作成します
• この様なコードになります。コード中のURL, 認証情報（アクセストークン）は、先ほどCloud Automatorで作成したジョブで生成されたものになります。 なおこのブログにはコードブロックの定義がないので、Lambdaのコードはまさかのスクリーンショットです。昔はコードといえば雑誌を見ながら手で打ち込んだものです・・・
• Connectから呼ぶだす際にLambdaのARNが必要となります（Lambdaのコンソールの一番右上です）。これを記録しておきましょう
• Connectから呼び出せるように、今作成したLambdaに権限を付与します（ドキュメントはこちら）。AWS CLIがある環境から、以下の通り実行します

  aws lambda add-permission --function-name function:(Lambda関数名。今回の例ではrequestCaJob) --statement-id 1 \--principal connect.amazonaws.com --action lambda:InvokeFunction --source-account (AWSアカウントNo) \--source-arn (ConnecctのARN。Connectの管理画面ではなくAWSのコンソールから「インスタンスARN」が取得できます)

Amazon Connectの準備

次に、Amazon Connectをセットアップします。

•  Connectの管理画面から電話番号を取得する （なぜか本稿執筆時点2017/12/9 では日本の番号が取得できないようです。以前は取れていたので、一時的な問題かと考えられます。今回は以前から取得していた番号で試しました）
•  問い合わせフローを作る いよいよ本丸の「問い合わせフロー」です。Connectの管理画面の「ルーティング」から「問い合わせフロー」を選択して、「問い合わせフローの作成」をクリックします
  • かかってきた電話番号を確認する まずはじめに、かかってきた電話番号が、Cooud Automatorの操作を許可してよい番号かどうかを確認します。
    • 「ブランチ」の「問い合わせ属性を確認する」をドラッグドロップで持ってきます
    • エントリポイントの「開始」からドラッグして、「問い合わせ属性を確認する」と接続します
    • 「問い合わせ属性を確認する」のキャプション部分をクリックして設定画面に入り、電話番号のチェック条件を入力します。
    • 番号が一致していれば次に進みますが、一致していなければブチっと切ってしまいましょう。遠慮はいりません。「切断/ハングアップ」をドラッグ＆ドロップして、「一致なし」と接続します
  • 音声の設定を行う
    • 電話番号の認証がOKでしたら、いよいよ音声案内です。「設定」から「音声の設定」を配置して、先ほどの「問い合わせ属性を確認する」の「＝」の場合と接続します
    • 音声のデフォルトがJoannaになっています。けしからんですね。日本人であれば安定の「Mizuki」さんに変えましょう。これまでと同様に「音声の設定」をクリックして「日本語」から「Mizuki」を選択します
  • ボタン入力を受け付ける アナウンスを流してから、プッシュしてもらいたいと思います。「操作」から「顧客の入力を取得する」を配置して「音声の設定」の「成功」とつなぎます。
    • 「顧客の入力を取得する」をクリックすると、話す内容を設定できます。ここで「テキスト読み上げ機能」を選んで、テキストを入力します
    • 更にボタンをプッシュしたときの分岐を作ります。「別の条件の追加」を押すと「オプション」という項目が現れます。ここに今回は「1」を入れます。
  • Lambdaを呼び出す
    • 「1」が押された場合の処理として、Lambdaを呼び出しましょう。「統合」から「AWS Lambda関数を呼び出す」を配置して、「Pressed 1」と接続します。「AWS Lambda関数を呼び出す」をクリックして、「関数のARN」というところに、先ほど作成したLambda関数のARNを入力します
  • 終了
    • Mizukiさんに「処理しました」とお話ししてもらって終了しましょう。「操作」から「プロンプトの再生」を選んで配置し、接続します。
  • 最後に
    • Connectのフローでは、条件分岐は必ずどこかと接続されている必要があります。「顧客の入力を取得する」の例外も、プロンプトを再生して切断まで繋げてしまいます。
  • デプロイ
    • このフローを環境に適用しましょう。「保存して発行」を押すと、環境へのデプロイが行われます（保存だけの場合は、環境には適用されません）
• 電話番号とフローのひもづけ
  • Connectの管理画面にある「ルーティング」の「電話番号」にいき、今回有効にしたいフローの電話番号をクリックします
  • 「問い合わせフロー/IVR」を、今つくったフローに変更します

試してみる

これで準備が整いました！ さっそく電話をかけてみましょう。 ・・・おお！あのEchoで聞き慣れたMizukiさんの声がします！

案内の通り1を押すと「インスタンスを起動します」というMizukiさんのメッセージと共に無事にインスタンスが起動しました！ （Cloud Automatorのジョブ画面から「ログ」を見ると、HTTPで呼び出されたかどうかが確認できます） Cloud AutomatorではジョブのトリガーとしてHTTPを使うことができますので、電話をはじめとする様々なアプリケーションと簡単に連携し、手軽にAWS運用を自動化することができるようになる、ということがおわかり頂けたのではないかと思います。 ぜひみなさんもCloud AutomatorでAWSの自動化にチャレンジしてみてください！

働き方改革 ＜ 関係性改革

こんにちは、大石です。

最近、いろいろな場面で「働き方改革」についてお話する機会が増えてきました。 私達自身、過去6年に渡り様々なチャレンジを進めてきたので、トランアンドエラーの結果をお伝えすることは簡単にできるのですが、一方で「自分たちでは、働き方改革というキーワードは使わなかった」という事実とのギャップに戸惑ってもいます。 この戸惑い・違和感の正体はなんだろうか？と疑問に思っていたのですが、先日ある方のインタビューを受けていてようやく謎がとけました。

当社は13部署中6部署のマネージャーが女性なのですが、社内で「女性活用」というキーワードは出てきたことはありません。 ですが、インタビュワーの方に 「女性マネージャーがそんなにいらっしゃるなんてすごいですね。女性活用とかに取り組まれてきたんでしょうか？」 と聞かれたときにハッと気づいたんです。

よく日本語は「主語を省略する言語だ」といいますが、「女性活用」という言葉は、主語が「男性」なんですよね。 「男性が女性を活用する」と。 私達の会社で女性マネージャーが活躍しているのは、恐らくそういう視点が皆無で、純粋に能力・適性・動機・経験等を勘案してフェアに決めた結果だから、「女性にゲタを履かせる」ようなこともなく、みんな活躍できているんだと思うのです。

同じように、「働き方改革」というのも暗黙の主語が「会社」なんだと思います。 でも、別に今の若い人は（仕事を選びさえしなければ）いくらでも働き口はありますし、「会社が潰れたら転職すればいいじゃん」というのが普通の感覚なんではないかと思います。 つまり、「働き方を変えて生産性を上げてほしいのは、（今まで若手をこき使って利益を捻出してきた手法が使えなくなって）困っている会社側」なのであって、社員視点でみればサイボウズさんの広告のキャッチコピー

が本音なのではないかと思うんです。

これから人口、特に若い人が減って、人手に頼るオペレーションはほとんど不可能になります。人手不足で苦しんでいる会社が「人手が十分に足りている」という状況はもう二度と来ないわけです。 そう考えると、今変えるべきは「働き方」なのではなくて、「社員と会社の関係性」なのではないかと思うのです。

今までは、相対的に会社よりも若者の数が多かったので、若者が選ばれる側だった。だから入った会社に忠誠も誓うし、理不尽な命令でも従っていたわけです。 ところが、これからは若者の数が減って、若者に選ばれない会社は、老衰で死を迎えるしかなくなる。まさに死活問題になるわけです。

これは本当に本質的な変化です。 今まで業者だと思っていた会社が顧客になる。 弟子だと思っていた人が先生になる。 それと同等の大きな変化です。

だからといって「甘やかしてお客様扱い」するわけではありません。会社が潰れない約束など誰もできない世の中ですから、会社が社員に約束できる最大の報酬は「どんな会社にも転職できる能力をどこよりも早く身につける」ことだと思うのです。そのためにはお客様扱いするのではなく、きちんと機会とサポートを提供しなければいけません。これはこれからの日本企業の義務です。

一方で、理不尽な下積みや、ふるい落とし型の教育・育成はもう機能しません。あえて厳しい下積み・業務を経験させて「這い上がってきた奴を使おう」というスタンスでいると、若者の母数が多いうちは何人か残ってくれて会社に貢献してくれたのかもしれませんが、これからの社会では「そして誰も居なくなった」的なシャレにならない未来が待ち構えています。 私達でも、実際こんなことがありました。

当社では毎週月曜日に「朝会」と称して、私がとても「ありがたい」話を会社でするというとても「ありがたい」会があるのですが、その場に居なかった人でも私の話を聞けるように、新入社員が持ち回りでテキストに起こして社内Wikiに掲示する、というとても「ありがたい」仕事があったのです。 いわゆる「下積み」に近い業務ですが、一方で私の話を新入社員が耳ダンボで聞く羽目になりますので、私の想いを早く浸透させることができる、という効果を狙った「下積み」だったわけです。 ところが、新入社員にとってこれは苦痛以外の何者でもなかったらしく、ある日優秀な新入社員の一人から「この業務をお願いだからやめてくれ」という声が上がったのです。 昔の会社だったら「うるさい！いいからやれ！」で良かったのかもしれませんが、これから若手のパワーが何より重要になる社会において、若手の生産性よりも貴重は資源はありません。というわけで、今ではBox Captureで音声をそのままBoxに上げるというオペレーションに変えて、生産性と優秀な社員の動機づけ（どちらかというと離職の防止ですがｗ）につながった、ということがあったのです。

私たちはこのように考え、できるだけ「当社でしか通用しない業務」を排除しようと様々な工夫をしていますし、また「AWSの様な世界最先端のサービスを使い続ける」ことで、技術・営業スキル・人脈含め、自分の能力と経験を伸ばすために最高の環境を準備しようと努めています。

つまり、私達のはたらき方改革は、会社が命令してやってきたわけではなく、社員と会社との関係性を改革しようとして対話を続けてきた中で、結果として本気のリモートワーク活用やお昼寝スペースの設置、理不尽下積みの排除など、イマドキの働きかたになってきたというのが本当のところなのです。

私が、変えるべきは「はたらき方」よりも「社員と会社の関係性」と考える意図がみなさんに伝われば幸いです！

なぜエンジニアにはミュージシャンが多いのか

こんにちは、大石です。

先日BacklogやCacooでおなじみヌーラボの橋本社長と話していたら、ヌーラボさんでも元ミュージシャンやバンドマンが多いとのこと。 当社にも「ミュージシャンを目指していたが途中でくじけて（やむを得ず）エンジニアになった人」とか「今でも趣味でバンドをやっている人」が数多く在籍していますが、これは決して偶然ではないように思います。 自分も多少音楽をかじっていたので確信があるのですが、音楽もITも使う頭の機能が似ているんです。

音楽そのものは「瞬間的」「流動的」で「形がなく」「あいまい」で「人によって捉え方が違う」という右脳的なものですが、「楽譜」という共通ルールで符号化するという左脳的作業によって、「ロジカル」で、「あいまいさを排除」し、厳密なものにして「再現可能にする」なものになっていきます。 もちろん、これは一方通行ではなくて、楽譜に落とし込んだあとに「演奏して当初の意図通りか検証」したり「現実に合わせてアレンジ」したりといった、楽譜と実際の音とをいったりきたりする工程が必要です。

エンジニアの仕事も酷似していて「業務」とか「要件」という、形がなくてあいまいで人によって捉え方が異なるものを、「コード」という共通言語で符号化することによって「厳密」かつ「再現可能」にすることが求められます。そして、音楽と同じように「コード化したものが現実に即しているのか」を検証して、それを修正したり、またコード化したりと、現実とコードをいったりきたりすることを繰り返し、現実世界を精緻に反映したコードができていくわけです。

素晴らしい音楽家の音楽を聞くと、作り手の感情や情景といった「あいまい」なものが鮮やかに聞き手の頭に再現されるように、優れたエンジニアが書いたコードやシステムは、業務や課題といったあいまいなものが鮮やかに解決されるわけです。よいエンジニアにミュージシャンが多いのは決して偶然ではなく、こんな共通点があるからなのではないかと思います。

---

ところで、このエントリを読んで「右脳とか左脳とか間違いだから、本稿の議論は意味がない」と感じた方へ。 本稿で述べたいことは「優秀なエンジニアと音楽家に共通する能力は、現実世界を知覚する能力と、厳密に符号化する能力との架け橋にある」ということです。そして現実問題として「イメージは右脳、ロジカルな思考は左脳が処理する」と認識している人が多いわけなので、比喩として出したわけです。ここで言っている「右脳」とか「左脳」というのは現実世界をざっくりと切り取るためのメタファーで、「形がなく」「あいまい」なものです。現実の「あいまいさ」と「科学的な厳密さ」とをブリッジして読んで頂ければ幸いです ;-)

「国・政府」を「企業」に置き換えても違和感がなかった話

こんにちは、大石です。

経済産業省の「次官・若手プロジェクト」で作られた 「不安な個人、立ちすくむ国家」と題した資料がネットの話題をさらっています。

「よくやった」「そうだそうだ」という声と「データが間違っている」「何をいまさら」「処方箋が示されていない」という批判的な声の両方があるようですが、これは行政が作っているものなので、普通に考えて「処方箋出したらダメでしょ」と思います（「処方箋がないからダメだ」と批判する向きには「三権分立って知ってますか？」と聞いてみたいのですが・・）。 一般論で言えば、行政に携わる官僚の方が、選挙で選ばれる任期制の政治家よりも長期に渡って国の仕事をすることになるでしょうから、長期視点に立ち「このままポピュリズム的シルバー民主主義だとまずいよ。若者の教育に投資を振り向けてくれるまともな政治家に投票するムーブメントを一緒につくろうよ」というSOSだと見るのが妥当ととらえました。 そうして読めば、下手に処方箋という名の行政権を超えた提言をするのではなく、データに基づいた国家設計の1つの方向性を示して「国民の投票活動にポジティブな影響を与えよう」とするギリギリの努力が垣間見え、私は「すばらしい知的な努力の結晶」と感じました。

ところで、これを読んでいて気づいたのですが、ところどころ「国」とか「政府」などと書かれているところを「会社」と読み替えても違和感がないんです。

これには愕然としました。なんとなく、日本人の感覚として「国はだらしないけど、企業は国よりはマシ」という認識があると思うのですが、「本当にそうかしら？」と思うほど似ているのです。

当たり前ですが、組織が小さいほうが機敏に動けるので、私もよく「ベンチャーは社会実験だ」といろいろなところでいいますし、クラウドにしても社内の制度やはたらき方改革にしても、私達の取り組みがうまくいけばそれを大企業とか社会に伝えていくのが、企業人としてのミッションだと思っています。社会の変化は、どうしても組織のサイズという観点から「民→官」の順になると信じていました。 ですが、上の対比をみるにつけ、本当に「国よりも進んだ位置にいなければいけない企業で、将来に向けた取り組みができているんだっけ？」と思わざるを得ないわけです。

働き方改革から「関係性改革」へ

この資料でも何度も取り上がられている様に、これから日本では「若者が減る」社会になります。そしてそれは二度と覆らないわけです。そうした状況下で会社が「働き方を変えろ」と若手に言っているのは滑稽ですらあります。

今までは会社が若者を選別する時代でした。ところが、若者が貴重な資源となる今後は、若者が会社を選別する時代 になるわけです。 若者が減る時代の企業経営に求められることは「若手に来てもらう経営」であって、これをやらなければ（今まさに日本という国が老人とともに沈没しかけているように）企業も老人とともに年老いて滅びるしかない、ということを意味しています。 つまり、変えなければいけないのは「働き方」ではなく「社員と会社の関係性」なのです。私たちはこれを「関係性改革」と呼んでいます。 今まで業者だと思っていた会社が突然顧客になる。今まで生徒だと思っていた人が突然先生になる。それと同種の変化が、社員と会社の間に起こり始めていて、そしてそれは二度と逆転することのない不可逆的なものであるわけです。

若手社員≠お客様

ですが、それは「会社が若者をお客様扱いしろ」というわけではありません。 本資料のP32が示すように

「若者は貢献意識に溢れていて、何か役に立つことをしたいと思っている」

という意識は事実として示されていますし、私達の実感とも合致します。社会のためになる仕事をしたいという想いは、私が社会人になったときの同世代人よりも、今の新入社員の方により強いものを感じます。 しかし、そういう取り組みを支援する社会的な合意や基本的な仕組みが欠落している。そういう風に若手が捉えてしまい、「頑張っても報われない」と諦めてしまっている姿がすけて見えます。

逆に言えば、

• 会社がきちんと社会的に意義のあるビジョンを示して
• 若手でも活躍できるチャンスを与えて
• 将来に渡る持続的な居場所とつながりを提供すれば

会社という仕組みはまだまだ機能するし、若者も会社も活躍できる可能性を示唆しているわけです。

シルバーワークス構想

一方で「居場所のない定年」についてはとても解決の難しい問題です。すべての会社は、放置すれば人口動態に沿って年配の比率があがっていきますし、どんな人でもどんな会社でも、老いは避けられません。 私は、この問題を年齢層ごとの会社分割で解決したいと考えています（ちなみに分割後の会社の名前は「シルバーワークス」という名前にしようかと思っており、ドメインも取得済みですw）

• コンセプト
  • サーバーワークスの社員のうち、希望する55歳（くらい）以上の人がシルバーワークスに転籍できる
  • シルバーワークスは定年なし
  • サーバーワークスの仕事のうち、古いシステムの運用、過去の経験、古い知識などが求められる仕事を請け負う
  • シルバーワークス社長は（会社の中で相対的に）若い人がやる
  • 完全成果報酬型なので、逆に成果を出さなくても堂々と会社に居られる（会社の仲間とお茶のみ仲間の狭間）

はっきり言って、このアイディアがうまくいくかどうかはわかりません。ですが、私自身「シルバーの問題はシルバーでなければ解決できない」と確信していますので、自分のライフプランとしてやりきろうと思っています。資料でも提言されている「働ける限り貢献する社会」というイメージですね。 当社にも御年74歳の監査役がいらっしゃいますが、お元気ですし、何より貴重な戦力です。74歳になられても、ベンチャーに必要な人はたくさんいらっしゃる、ということを体現されていて、「あんな風に歳を取りたいなぁ」と私を含めてたくさんの人が思っているんじゃないかと思います。

私達のチャレンジ

この資料が示すとおり、「放置すれば老衰による自然死」が確定している現在の状況を指を加えて傍観しているわけにはいきませんので、サーバーワークスとしてもいろいろと手を付け始めています。

• いまやっていること
  • 関係性改革＝来てもらう＆居てもらう経営
    • 出社したくなる会社の設備（と、無理に出社しなくてもよい制度）
    • 転職したくなるような企業風土マーケティング
    • 新卒でも早くから活躍できる制度と文化
  • 事業の社会的な意義
    • 「クラウドで、世界を、もっと、はたらきやすく」というビジョンとそれに即した事業
  • はたらきやすい環境づくり
    • 本気のリモートワーク＋全システムのクラウド化
    • 時短でも正社員
    • 転勤0（ローカル採用・ローカル勤務）
    • 女性でも男性でも育児参加を支援
    • 叱責しないカルチャー（失敗を個人の責任にしないルール）
    • 自動化自動化アンド自動化
  • これからやろうとしていること
    • 「人が少なくなる時代の、企業のITインフラ」をクラウドで支えること
    • 自分たちのワークスタイルや成功体験を広めること
    • シルバーワークスの様な会社をつくって、若い人から年配の方まで、すべての人が永く活躍できる場をつくること

いろいろと端折って書いていますが、「来てもらう＆居てもらう経営」と「はたらきやすい環境づくり」については様々なトライ＆エラーの蓄積ですので、回を改めてこちらのブログでも書く予定です。

まとめ

この資料について「データの確からしさ」とか「言葉じり（上から目線？）」「100点の人生って何だよ」など枝葉にアレコレ言っている人は多く見受けましたが、「若者もシルバーも両方が活躍できる社会をつくろうぜ！」という幹の部分に異を唱える人はほとんどいないと思います。

私は企業経営者という立場から「私ができることをやる」というスタンスですが、資料P61の「意欲と能力ある個人が公の担い手に」とある通り、個人でも企業でも、いろいろとできることはあると思います。

サーバーワークスでは、オリンピック／パラリンピックの期間中はお休みにすることを明言していますが、それは「企業という社会の一員として、ボランティア活動をやることが相応しい時はボランティア活動をしよう」と考えているからですし、また今回提言されたような課題に対しては「社会の問題に対しては官も企業も個人もなく、オーナーシップをもって取り組もう」と考えた結果、小さいながらも上記の様な行動につながっているわけです。

少しでもよい社会を創るためにも、これを読んでくださった皆さんと一緒にできることから始められれば幸いです！