大石蔵人之助の雲をつかむような話

株式会社サーバーワークス 代表取締役社長 大石良

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年はエンタープライズ用途でのクラウド利用元年」と言える年になったのではないかと思います。

サーバーワークスもお陰様で4年連続プレミアコンサルティングパートナーに認定され、「エンタープライズ向け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 AutomatorAmazon Connectとを接続することで、電話によるAWSの操作にも使える」ということを試してみたいと思います。

Cloud Automator側の準備

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

 

Lambdaの準備

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

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

 

試してみる

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

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

働き方改革 < 関係性改革

こんにちは、大石です。

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

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

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

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

f:id:swx-ceoblog:20200803145027p:plain f:id:swx-ceoblog:20200803145044p:plain

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

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

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

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

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

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

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

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

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

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

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

こんにちは、大石です。

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

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

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

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

 


 

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

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

こんにちは、大石です。

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

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

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

f:id:swx-ceoblog:20200803145321p:plain

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

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

 

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

 

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

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

 

若手社員≠お客様

 

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

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

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

逆に言えば、

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

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

 

シルバーワークス構想

 

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

f:id:swx-ceoblog:20200803145432p:plain

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

 

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

 

私達のチャレンジ

 

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

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

 

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

 

まとめ

 

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

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

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

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

新しくマネージャーになる皆さんへ

当社は3月から新しい期に入りますが、来期に向けた新しい組織やマネージャーも決まり、何人か新任のマネージャーも誕生することになりました。

以下はあくまで社内向けのメッセージですが「サーバーワークスではこんな考えでマネージャーを任命しているんだ」ということを知っていただく意味でも、こちらでシェアしたいと思います。

マネージャーのみなさんへ

新しくマネージャーに就任された皆さん、おめでとうございます!みなさんは、今素晴らしいチャンスを手にしています。

マネージャーのチャンス

  • 知ることができる範囲が広がる 私たちは「原則オープン」の会社なので、マネージャーしかしらない情報というのはあまり無いのですが、それでも「マネージャーだから集まる情報」というものは一定程度あると思います(例えば評価の情報)。社内での情報差は少なくとも、社外の方は「マネージャーに伝える」「マネージャーだから伝える」という行動を取るでしょうから、必然的に得られる情報の範囲が広がります。多くの情報が得られるということは、多くの選択肢を得られるという意味で良い機会だと思います。
  • 自分の能力を開発できるチャンスが増える 当然ですが、「やれること」を続けても能力は伸びません。能力開発・成長とは「できるようになる範囲が拡がる」ことを言います。自分のやれていないこと、やってこなかったことにチャレンジして、できるようになって、はじめて成長したと言えるわけです。マネージャーという新しい仕事は「自分がやってこなかったこと」に対するチャレンジという意味において、成長の機会といえます。
  • キャリアの幅が広がる 良いか悪いかはこの際おいておいて、課長は課長として、部長は部長として転職する機会がほとんどです。一人として「転職してほしい人」などはいませんが、(逆説的ですが)「サーバーワークスでしか生き残れない人」はマネージャーとして適任とは言えないと思います。能力をポータブルにすることはとても大切で、「いつでも転職できるけど、それでもサーバーワークスでマネージャーとして活躍する道を選んでいる」という状態であってほしいと強く願っていますし、「自分はいつでも転職して別なキャリアを形成することもできる」という状態を保つことは、精神衛生上も好ましいことだと思います。その意味で、マネージャーになるということは「キャリアの選択肢が拡がる」といえます。
  • 給与があがる(かもしれない)
    上役が下より高い給料をもらうのは、優秀だからではない。上役の方が責任が重いからだ。その責任の中には、必要なときに手を貸すこと、手に負えない事態から救うこと、守ることが含まれている。 ---カーリー・フィオリーナ
    当社の場合、役職とグレードを分離しているので、「マネージャーになったからといって給与があがるとは限らない」制度になっていますが、マネージャーに任じられるということは少なくとも期待はされているわけですから、給与があがる可能性が高いということはいえます。

私の知る限り、マネージャーに昇進することによるデメリットはほとんどありません。一部の会社では管理職になって残業代がつかなくなる、などということがあるようですが、当社の制度がそのようになっていないことはみなさんご存じの通りですし、そもそもマネージャーが残業代で稼ごうと思うような会社に未来があるとは思えません。ほとんどの場合「知らないから恐れている」だけだと考えられます。そこで、「知らない恐怖」を少しでも払拭するべく、以下に10のガイドを記したいと思います。

マネージャーへの旅を楽しむガイド

(1) 期待が変わったことを理解すること

みなさんはこれから「メンバー」から「マネージャー」というロールに変わります。ロールが変わるということは、期待も変わる、ということになります。 殆どのケースで、マネージャーは実務能力が高いからマネージャーに選ばれているのだと思います。実は これが大きなワナ です。今までは個人での実務を期待されていたのに、これからは突然「チームでのパフォーマンス」を期待されるのです。この変化に気づくことはとても重要です。マネージャーに任命された方は「チームメンバーのみんながあなたの様に成果をあげられるようになってほしい」「チームとして成果をあげてほしい」ということを期待されているのであって、「今まで通りにやってほしい」ことを期待しているわけではありません。まずこのことを再認識しましょう。

(2) 高い目標を設定すること

特に新任のマネージャーにありがちですが、感覚がわからないために「できること」に絞って小さな目標を設定してしまうケースが散見されます。が、これはあまり良いようには思えません。マネージャーへの期待という点では、「高めの目標にチャレンジし、結果として未達だったとしても、マネージャーも、チームメンバーも、会社もみんな成長することができた」という姿が理想的な姿です。「目標を達成したかどうか」よりも「全体として成長できたか」の方がより大切です。10%成長の目標を110%で達成したマネージャーよりも、30%成長の目標を95%で未達だったマネージャーの方が私は「優秀」だと考えます。 例えば野球で「出塁率」の様な小さな目標を立ててしまうと、ツーアウト2・3塁でフォアボールを選んで喜ぶようなことがおきてしまいますが、それよりもスリーベースを打ってさらにランニングホームランを目指したが、結果ホームでアウトになってしまった。でもチャレンジして2点とった、というぐらいの人の方が、チーム全体のパフォーマンスという点では期待には沿っていると思います。

(3) 会社のリソースは借り物であることを忘れないこと

特に新任のマネージャーは、メンバーをとても大切にする傾向があります。これ自体は良いことなのですが、意図せず「チームを不必要に護ってしまったり、さらに外界と隔絶されたガラパゴスを作ってしまう」ことが起こります。その結果、マネージャー自身の評価が下がってしまったり、メンバーが異動しにくい・他のチームと交流しにくい状況が生まれてしまっては「メンバーのためを思って」した行動が裏目になってしまいます。 メンバーや予算といったリソースは所有物ではなく、あくまで「借り物」です。会社の都合で期中で増減しなければいけないことも起こりえます。そうした場合に「取られた」とか「押し付けられた」などという感情が湧き上がったら要注意です。そうした感情は「チームは自分のもの」「自分のリソースは自分のもの」という思い込みがあるから湧き上がっているのだと考えられます。 リソースは「借り物」であることを忘れず、いつどんな場合でも、手持ちのリソースでベストを尽くすことに常に意識を集中しましょう。

(4) 他のマネージャーを大切にすること

マネージャーになって視座が高くなると余計に感じるものと思いますが、基本的に仕事で「自分のチームだけで完結する」というものはほとんどありません。仕事というものは、本質的にマーケ、営業、技術、総務、経理、人事、役員、いろいろなチームの人たちが連携して動いて、初めてうまくいくものです。しかも他の部署のマネージャも、たくさんの業務やいろいろなミッションを持っており、同じような悩みや苦労を抱えています。こうした「同じ目標に向かいつつも、同じ悩みをもつ同志」を大切にして、仕事の連携を良くすることで、結果として全体のパフォーマンスがあがるわけです。 特に新任のマネージャーは、どうしても「自分のチームのパフォーマンス」を気にしてしまいますが、会社全体で見るとパフォーマンスというものは「チームとチームの間のパイプの太さ」によって既定される場合がほとんどです(ボトルネック)。

下の図はこの考えを示したモデルです。 f:id:swx-ceoblog:20200803145603p:plain (1)でチームのパフォーマンスを倍にするよりも(それはとても大変なことですが!) (2)の様にチーム間の連携をスムーズにする方が、会社全体のスループットは上がるということを示しています。

こうした「チーム間のパイプを太くする動きをすることで、全体のスループットがあがる」という認識があると、他のマネージャーを大切にすることの意味も理解できると思います。その認識と行動が、あなた自身によりよい結果をもたらすはずです。

(5) メンバーの能力を引き出すこと

先の「借り物」のところでも言ったとおり、メンバーはあなたの所有物ではありません。ですが、能力と成果を引き出すことについては、マネージャーにその役割が期待されています。「部下を思い通りにコントロールする」という発想を捨てて、メンバーにどのような能力があって、その能力をどのように引き出すとチームのパフォーマンス(成果)につながるのか、メンバーの成長が促されるのかを常に意識しましょう。

(6) 会社の意向を咀嚼して、実行に移すこと

マネージャーになると、会社からの要求が一段抽象的になります。例えば会社のトップが「火の用心」というビジョンを示した時に、マネージャーがメンバーに同じように「おい、火の用心しろよ」というだけでは、なんの実効性もありませんし、マネージャーが居る必要性もありません。 会社が「火の用心」と言っている場合、他の部署と連携して、誰かが水槽を用意すれば、自分の部署はポンプを用意する。別な部署が火災報知器を用意したら、他の部署は消防車を用意する。そしてそれが常に稼働するような計画を立て、実際に実行する、といった具合に、抽象的な目標やビジョンを、具体的な行動に咀嚼(翻訳)して計画と行動に落とし込む必要があります。これを今までと同じように「やるべきことが降ってくるもの」と思っていては、1の「会社の期待が変わったこと」に対応できませんし、5の「メンバーの能力を引き出す」こともできません。 こうした「会社のビジョンを仕事のアクションアイテムに翻訳する」こともマネージャーの大切な役割の一つだと認識しておくと、自分への期待、やるべきことも一層はっきりするものと思います。

(7) 新聞を読むこと

マネージャーになると高い視座が求められます。そしてそのような視点を持っていると、会社の方向性、ミッション、お客様の意思決定など、実に様々なものが「流れ」の中で決定されることがわかってくると思います。こうした「社会の流れ」を掴んで置くことは、マネージャーが様々な意思決定をする上でとても大切です。なぜ今「はたらき方改革」なのか。なぜ今AIが注目を浴びているのか。クラウドは社会からどのように認識されているのか。1社1社歩いて聞いてきても同じ情報が得られるかもしれませんが、マネージャーにそんな時間的な猶予はありません。新聞の様な、より効率的かつより公平なメディアから情報を得ることが、高い視座を持つ上で有効に機能すると思います。 (ちなみにtwitterfacebookなどは「流れ」を見るためには不適なメディアです。こうしたSNSは基本的に同じクラスターの人が集まりますので、自分のクラスターに不都合な事実は隠蔽されてしまったり、過小評価されてしまいます。流れを見るためには情報の偏りを避けることが大切で、そのためにあえて「新聞」と言っています)

(8) 判断の評価軸を明確にすること

マネージャーになると(それまでよりも)いろいろな決定に関わる機会が増えることになります。その時、メンバーに「あのマネージャーは、こういうときは○○と判断するはずだ」と認識されているか、それとも「聞いてみないとわからない」と認識されているのかは大きな違いがあります。 判断の軸がまちまちであったり、気分によって回答が違ったりすると、メンバーは気分が回復するまで相談を躊躇したり、都合の悪い情報を隠蔽したりするようになるかもしれません。これでは正しい情報が集まらず、チーム全体の意思決定のスピードも遅くなってしまいます。 幸いサーバーワークスでは「行動指針」という形で意思決定の大指針が提示されていますが、それでも行動指針は大きな枠組みであり、細かい判断はまだまだマネージャーに委ねられているのが実状です。そうなると、「自分のチームでは、こういう軸で判断する」という評価軸を明確にし、それを自分の気分や思いつきで変更しない運用をすることが、メンバーが精神的に安心して相談できる環境の醸成につながります。

(9) 自分の成果を見える化すること

今までメンバーだったときは、自分が「課長に見てもらう」立場でした。今度からはメンバーを「見る立場」に変わるわけですが、ここで「そうはいっても、会社全体から見られる立場になった」ことを忘れてはいけません。自分の役割や仕事に誇りや自信を感じていればなおのこと、「自分はこのような成果を成し遂げた」ということは誰からも明らかにするべく、見える化しなければいけません。 4の「他の課長を大切にする」でも述べた通り、会社全体のスループットという観点では、実は「チームそのもののパフォーマンス」よりも「チームとチームの間の連携」の方がパフォーマンスに与える影響は大きいのです。ところが一般的に評価というのものはチームのパフォーマンスに焦点が当たっていますから、自分たちの行動の結果、連携がどのようによくなって、どの程度会社全体のスループット向上に貢献したのかは、マネージャーが率先して公開しないとわからないものなのです。 サーバーワークスであればQuestetra BPMを使ってチーム間のワークフローを自動化していますが、例えば「ワークフローを作ることで、業務が省力化された」とか「ワークフローの改善でデリバリーまでのスピードが短縮化された」といった事実は、マネージャーが意識的に見える化することで初めて認識されます。これは、会社全体のためにも、メンバーのためにも、そして何より自分の評価のためにも大切なことです。

(10) マネージャーという役割を楽しむこと

仕事の肩書きというものは、あくまで会社運営が楽になるように考えられた「役割」です。「ロミオとジュリエット」に2人も3人もロミオが居ては劇は成り立ちません。誰かがロミオに、だれかがジュリエットを演じて、他の誰かがエスカラスやロレンスを演じることで初めて劇として成立するわけです。 同じように、役割というものも「会社」という舞台を成功させるために、あなたに割り振られた「役割」です。上の1〜9を参考にして見事演じきることで、更に大きな役割を与えられたり、場合によっては主人公に抜擢されることもあるわけです。 せっかくみんなで一緒の舞台に立っているわけですから、この劇が見事成功するように、自分の持ち場を演じきって、より大きな喝采をあびましょう!

 

マネージャー(課長、部長)への昇進、おめでとうございます!一緒に新しいロールを楽しんでいきましょう!