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

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

パワハラ・セクハラは「受けた人だけが決める問題」では無い

こんにちは、大石です。

最近「ブラック部活」や「パワハラコーチ」などの報道が世間を騒がせています。少し前ですが大分の暴力剣道教師や、今年話題になった日大アメフト部の違法タックルなど、選手の人間性や将来を無視して暴力で選手を無理矢理強くさせようとする指導者の存在が、日本のスポーツに暗い影を落としています。 今回報道された体操のパワハラコーチも、報道によれば日常的に馬乗りになって暴力を振るったりと言語道断ともいえる指導を繰り返していたとのこと。 ですが、この問題が今までの報道と少し違う点が、当の選手が以下の様なメッセージを発したところにあります。

暴力は良くないことだとはわかっていますが、私は速水コーチに対して、パワハラされたと感じていませんし、今回のことも訴えたりしていません。

わたしはこれを読んで「長年一緒にやってきたコーチを急に失って気の毒だ」とは思いつつも、強烈な違和感を覚えました。 ハラスメントの問題を1対1の問題に矮小化しようとしている、と感じたからです。

私たちもハラスメントのない会社を目指してコンプライアンス委員会を立ち上げていますが、その場で毎回私から、

コンプライアンスとは「法令遵守」と訳されるが、これは間違っている。 法令遵守は当たり前のことで、真のコンプライアンスとは「社会からの期待値を理解し、それを上回ること」

という話しをしています。

よくセクハラについて「受け手によって感じ方は変わるから難しい」などという人がいますが、その認識は間違っていると思います。ハラスメントとは「受け手との1:1」の話ではなく、それを見た人、知った人がどう思うかという「1:n」の話しであることの理解が足りていないように感じられます。

仮に今回のパワハラコーチの問題が「1:1の中で容認されたから良い」「これまでもそれでやってきた」という理屈で正当化されてしまえば、暴力の拡散を認めてしまうだけでなく、この選手が将来コーチになったときに「自分もこれで強くなったんだから、教え子も暴力で強くしよう」という理屈が正当化されてしまいます。

今回の暴力コーチの件も、当人とコーチの間ではそれが常識でも、世間一般でそれが常識で無ければ立派なハラスメントです。その点で「ワンアウトチェンジ」を選択した日本体操協会の判断は正しかったと私は考えます。

スポーツは「ただ勝てば良い」というものではありません。決められたルール内で、高いスポーツマンシップを表現してこそ社会的に存在価値があると認められるわけで、これがスポーツに対する社会からの「期待」です。何をしてでも勝てば良いのであれば、ドーピングも暴力的指導も(日大アメフト部で問題になったような)意図的に怪我をさせる行為も許されてしまうことになってしまいます。 日大アメフト部の監督が信じられないほどに愚かだったのは、カレッジフットボールに対するこうした期待を全くといって良いほど理解していなかった点にあります。

そしてこれはスポーツに限った話ではなく、ビジネスの世界も一緒です。単に儲かっているとか競争に打ち勝つだけでなく、市場のルールは守っているのか、そのビジネスに社会的な意味があるのか、会社や社員の振るまいが社会の期待にマッチしているかどうかがとても大切で、こうした期待に即していなければいくら利益が出ていても会社の存在意義そのものを問われかねません。

ハラスメントの話になると、よく「最近はあれもこれもハラスメントで息苦しい」と仰る方をお見受けしますが、私はそうは思いません。禁煙化が世界的な潮流で後戻りできないことと同じで、ハラスメント撲滅も「(物理的・精神的両面から)暴力を排除しよう」という不可逆的な流れです。禁煙化が進んだ社会が以前よりも住みよい環境になっていることと同様に、ハラスメントがなくなった社会は、もっと住みよい、はたらきやすい世の中になっていると確信できます。

1日も早く、暴力や恐怖の連鎖を撲滅し、社会の期待にそった明るい未来をみなさんと一緒に創っていきたいと強く願ってやみません。

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

こんにちは、大石です。

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

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

f:id:swx-ceoblog:20200803143331j:plain

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

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

ZOZOTOWNのビジネスとして

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

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

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

エコシステムの拡大

もう一点、「レモンスカッシュアプローチ」が画期的だと思う点として、これを使えば「身体のサイズ測定だけでなく、身体の動きも正確に測定できる」という点にあります。 例えば(想像すると若干滑稽ですが)100m走のランナーがこれを着て走れば、筋肉の収縮と動作が同時に測定できますので、より速く走るためのフォーム改造と筋肉量の変化が効率よく測定できそうです。ゴルフのスイング改善にも効果的でしょうから、このスーツを着させて専用アプリでスイング計測を行うゴルフスクールなんかも出てきそうです。フィットネスクラブでは「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年はエンタープライズ用途でのクラウド利用元年」と言える年になったのではないかと思います。

サーバーワークスもお陰様で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も使う頭の機能が似ているんです。

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

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

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

 


 

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