大石が最近書いたこと

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

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

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

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

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

マネージャーのチャンス

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

    上役が下より高い給料をもらうのは、優秀だからではない。上役の方が責任が重いからだ。その責任の中には、必要なときに手を貸すこと、手に負えない事態から救うこと、守ることが含まれている。 ---カーリー・フィオリーナ

    当社の場合、役職とグレードを分離しているので、「マネージャーになったからといって給与があがるとは限らない」制度になっていますが、マネージャーに任じられるということは少なくとも期待はされているわけですから、給与があがる可能性が高いということはいえます。

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

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


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

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

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

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

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

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

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

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

下の図はこの考えを示したモデルです。

(1)でチームのパフォーマンスを倍にするよりも(それはとても大変なことですが!) (2)の様にチーム間の連携をスムーズにする方が、会社全体のスループットは上がるということを示しています。

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

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

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

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

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

(7) 新聞を読むこと

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

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

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

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

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

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

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

 

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

新年のご挨拶

謹んで新年のお慶びを申し上げます。
旧年中に賜りましたご厚情に、厚く御礼申し上げます。

既に各所で報道されているとおり、2016年もAWSのマーケットは順調に成長し、当社も歩調を合わせて成長することができました。日頃より当社をご愛顧くださっているお客様、パートナーのみなさま、素晴らしいサービスを提供してくれているアマゾンウェブサービスジャパンの皆さま、そして成長を支えてくれている社員とそのご家族の皆様に、この場をお借りして厚く御礼申し上げます。

例年この場で「去年のn大ニュース」の様なことをお伝えしていたのですが、実は昨年は「ビッグニュース」が少ない1年でもありました。ニュースらしいニュースというと「3年連続のプレミアコンサルティングパートナー」くらいなのですが、実はある程度想定できていたことで、今年に向けていくつかの大きな取り組みを仕込んでおり、そのためもあってニュースの少ない年になりました。
ジャンプの前にはしゃがむことも必要ですので、今年のサーバーワークス・ジャンプをぜひご期待いただければと思います。

個人的には、家族の事情があって生まれて初めて東京で年越しをすることになりました。年末年始は新潟で過ごすことが恒例だったのですが、今年は東京でないとできないことをやろうと思い、ご近所の護国寺で除夜の鐘を横目にお参りをしつつ

img_4235

念願のスターバックス福袋を入手しました!

img_4239

(当社にはスタバ部という謎の部活があるのですが、早速部長にも報告しておこうと思います)

まとまった休みの時は家族4人でカタンという人気のボードゲームをするのが好例なのですが、ついに子供が強くなり勝てなくなってきました。狡猾な手口で狙い撃ちにされたり、予想しない戦略で痛めつけられると本気でイラっとします。このゲームほど子供の成長を喜べない遊びはないと思いますので、お子様が大きくなってきたご家族はご注意下さいませ。

私はカタンをやるときに「最長交易路」という「最も長い道を作る」戦略を立てることが多いのですが、私たちの仕事にも似たところがあるのではないかといつも思っています。
道無きところに道を作り、開拓し、発展する。ボードゲームをやりながらも、自分たちの仕事に重ね合わせ、同じように楽しんで行きたいと考えております。

今年も一年、公私共々どうぞよろしくお願い致します。

日経ビジネス特別版で、ワールドホールディングスさまの事例を公開しました

こんにちは、大石です。

11月21日発売の日経ビジネスに「ビジネス革新を加速させるクラウドサービス」という特別版が同梱されていますが、こちらに当社のお客様であるワールドホールディングス様のAWS活用事例を公開致しました。

ワールドホールディングス様は、人材派遣業で業界4位、連結従業員1万4千人近くを擁する大企業です。こうした企業が「インフラは全てAWSに移行する」「そのためのパートナーとしてサーバーワークスを選択する」という判断をして下さっています。こうしたお客様のサポートができることは私たちとしても誇りに思いますし、事例として公開できることになりテンションも上がっています。

お客様からの問い合わせや案件数を見る限り、企業でのAWS導入はかなり進んできている実感はありますが、それでも未だ多くの方から「オンプレの方が安いのではないか?」という意見を頂くことがあります。

当然ワールドホールディングス様にもこのような疑問はあったはずなのですが、私がインタビューさせて頂いた時に、「当社はもともと人材派遣業がメインだったため、クラウドを使う判断は簡単だった」というお話を伺いました。つまり、

  1. 人材派遣とは「コアコンピタンスに集中し、コアでない業務はアウトソースする」ために利用するもの。当社がそうした事業を営んでいる以上、自分たちも「コア業務には集中する。それ以外(ITのケースでいえば、サーバーやインフラの所有・維持)は積極的にアウトソースするべきだという考えが元々あった
  2. 人材派遣業では時間の感覚を厳しく持っているため、IT資産を持つことによって発生するシステムの維持管理コストを厳しく見ている。その結果、クラウドに移行した方が大幅なものTCO削減が実現できると試算した。実際に移行したところ、80%ものTCO削減が実現できている

 

私も企業経営者として「時間よりも貴重な資源はない」と思うのですが、ワールドホールディングス様のように「業務にかかる時間をシビアに計算する」という考え方がもっと広がれば、クラウドの活用が進むだけでなく、 社員に無駄な時間を使わせない という意識にもつながり、残業の抑制やブラック化の歯止めにもなるのではないかと思うのです。

これをご覧の皆さまも、もし会社で「オンプレの方が安い」などと言われたら

「では会議で配る資料も手書きにしますか?」

と問うてみて下さい。

複写機を使った方が圧倒的に早くコピーできるので、多少の投資をしてでもみなさん複写機を使っていらっしゃるのだと思います。

comparison-between-onpremise-and-cloud

同じことはITの世界にも言えます。見た目の目的はオンプレとクラウドで変わらなそうですが、実際には「所有することによってまとわりつく不必要な業務」が大量に発生します。こうした違いは、結局のところITインフラの維持コストに、最終的には企業の競争力に影響してきます。こうしたムダを省き、より迅速に、変化に適切に対応できるインフラを持つことは、企業経営として自然なことの様に思われます。

 

人生とは時間そのものです。時間より貴重な資源はないと断言できます。

少しでも多くの人が、ハードを持ってしまったばかりに生じた「何も生まない」仕事から解放され、より人間的な、生産的な活動に従事できるようにするため、これからもクラウドが持つ “Super Power” を皆さんにお伝えし続けようと思います。

サーバーワークス アドベントカレンダー1日目 – re:Invent 2016の会場より、プレミアコンサルティングパートナー認定のお知らせ!

こんにちは、大石です。

早いもので今年も12月。サーバーワークスのアドベントカレンダー初日を迎えました。

今年もAWSが主催するワールドワイドカンファレンス “re:Invent 2016” がラスベガスで行われており、このブログもラスベガスの会場から書いております。

ここで毎年、AWSのパートナーランク最上位である「プレミア コンサルティング パートナー」の発表が行われるのですが、当社も2017年のプレミアパートナーに認定されました!

Premier Partner in 2017

パートナーの成長についてもいくつかユニークな数字が発表され、

  • Fortune 100社のうち90%以上がAPNパートナーを使っている
  • MSP認定パートナーは年間130%成長している

といった事実が紹介されました。

一般的に「米国では自社で開発・運用を行うのでSIerに頼む習慣がない」と言われますが、現実的にAWSのサービス規模と顧客がAWSに期待する効果から考えると、米国の企業ですら、自社でAWSのエンジニアを採用したり育成したりするよりも、AWSパートナーに頼んで早くクラウドトランスフォーメーションを進めよう、と考えていることが分かります。

日本からも新たにNTTデータ、NECの2社がプレミアコンサルティングパートナーに加わり、AWSとしてもエンタープライズ用途での利用拡大に期待していることが窺えます。私たちは2009年から エンタープライズグレードのお客様にAWSを効果的にお使い頂くサポートを専門で行ってきた 知見を活かし、これまで以上のスピードで、事業の拡大とお客様に提供できるサービスの質・量のアップを図って参ります!

現地時間の11月30日にはAWSのCEO アンディ・ジャシー氏によるキーノートスピーチも行われ、AI, IoT, ビッグデータ分野でそれぞれAWSらしい、ユニークなサービスの発表がありました(個人的にはRekognition, LEX, Greengrass, Athenaに注目しています)。

発表の内容については、当社の技術ブログでこれからレポートする予定になっているほか、大阪では R3さんと共同でre:Invent解説イベントを行うなど、各種イベントを通じて皆様にもお伝えする予定ですので、ご興味のある方はぜひこちらもご覧下さい。

AWSの成長は本当に驚くべきスピードで、2016年もYoYで55%成長とのこと。売上1兆円の企業が50%以上の成長を達成しているということも驚きですが、これだけの規模で拡大している場所でビジネスができることは、当社にとっても、当社ではたらくエンジニアにとっても大きなチャンスと言えます。会社にとってはもちろん成長と発展が見込めますし、エンジニアにとっても、新しいサービスやイノベーションが起きている爆心地の近くで仕事をすることで、より早く新しいサービスに触り、技術力を磨く機会が継続的に存在することになります。

これからもこの 恵まれた環境を活かし、成長にコミットして、そして私たちの「クラウドで、世界を、もっと、はたらきやすく」というビジョンの実現に邁進していきたいと思います。

これからも応援のほど、どうぞよろしくお願い致します!

クラウドジャーニー(AWS Summit 2016を終えて )

こんにちは、大石です。

今年もAWS Summitが開催されました。当社も4年連続ゴールドスポンサーとして出展しまして、国内クラウド業界で最大規模となったお祭りに出展者側として参加いたしました。
既に沢山のレポートがあがっていますので詳細はそちらに譲るとして、私が印象に残ったことを1つだけ挙げるとするなら、AWSJ長崎社長のキーノートで提示されていた「クラウドジャーニー」というキーワードです。

「全ての組織はユニークだが、クラウド導入における共通のパターンはある」

 

そのパターンとして
1. プロジェクト単位での導入
2. 本格的に導入する前の基盤整備
3. 移行
4. AWSへの最適化
の4つの段階があることが示されました。

 

cloud-journey.png

 

これは私たちの実感とも完全に一致しています。特に最近は1-2の段階から「実際に数十〜数百のサーバーやシステムを、どうやってAWSに移行するのか?」という課題が増えてきており、クラウドジャーニーもいよいよ「移行」がメイントピックになりつつある、と感じています。

中間解としての “Lift-and-Shift”

こうした状況を踏まえて、当社からは「Lift-and-Shiftという移行アプローチ」についてご説明させて頂きました。どうしてもAWS移行というと、Redshift, LambdaやDynamoDBといった「イケてるマネージドサービスを使うのが善で、それ以外は悪」のような風潮がありますが、実際に大きな規模の会社や巨大なシステムで一挙にクラウドネイティブ化をすすめようとしても、組織の問題やアプリケーション書き換えの問題などで頓挫してしまうことも考えられます。
そのため、「まずはas-isでAWSに移行して、それから順次マネージドサービスに切り替えていく」というアプローチが採られるケースが増えている、というお話をさせて頂きました。

実際、私たちが過去のAWS Summitで発表させて頂いた丸紅様、横河電機様などの大規模な事例も、このように「まずLiftして、それからクラウドらしくShiftしていく」というアプローチを採られています。

サーバーワークスからの発表

そして、当社からはこうした状況も踏まえて以下の発表を行いました。

1. Cloud Automatorに「構成レビュー自動化」を追加
これまでCloud Automatorは「ジョブ自動化」に特化していましたが、さらに「構成レビュー自動化」の機能を追加致しました。

 

 

お使いのAWS環境が、予め決められたポリシーに従って運用されているかどうか、Cloud Automatorが自動的にチェックする、という機能です。

 

2. 新サービスpieCeの発表
これまで「課金代行サービス」と称して、AWSの利用料を円建て・請求書払いを受け付けるサービスは提供して参りましたが、これを拡充し、「AWS構築ガイドライン+Cloud Automatorの全機能+東京海上日動火災保険が提供するAWS保険」をセットにして、今までと同じプライスで提供するAWSの請求代行サービスを提供致します。

 

3. 社内ツール Yambda のお披露目
最後に、これまで外部にお伝えすることが殆ど無かった社内プロジェクト “Yambda” についてもご説明させて頂きました。当社ではこうしたツールを使ってCloud Formationのテンプレート、ドキュメント、テストコードなどの生成を自動化しているから、素早く、そして正確なデリバリーができるということをお伝えさせて頂きました。

 

yambda.png

 

実際、社内では既に90%近いプロジェクトでこのツールによる構築の自動化が実現できています。

 

そして(具体名は出しませんでしたが)、移行ツールの拡充によって「ダウンタイムの極めて短いAWS移行サービスを今夏に提供する」ことも発表させて頂きました。当社は先日「移行コンピテンシー」の認定も取得しましたが、サードパーティーとの連携も強化し、移行サービスもさらに拡充して参ります。

来年は・・・?

来年はIoTの実例がかなり揃ってくると思います。
また、IoTやAIといった新しいパラダイムを取り込むには「クラウドでなければ実現できない」という(既にクラウドに取り組んでいる人からしてみれば至極当たり前のことが)ようやく事実として広く認められる様になっていると考えられます。
私たちとしても、以前からお伝えしている「コードを書かなくてもここまでできる!」というお客様の実例を多数用意して、何年も前からコンセプトとして掲げてきた「作らないSI」、つまり「コードレスアーキテクチャ」が現実解であることをご覧に入れたいと今から意気込んでいます。

 

 

ところで・・・
今回のAWS Summitの1-2日目は風邪を引いてしまいまして、ダウンしてしまっておりました。わざわざブースにお越し下さった方がたくさんいらっしゃったと聞いております。大変失礼致しました。来年はばっちり体調を整えて、3日間フル参戦したいと思います!

システム内製化の罠

こんにちは、大石です。

先日JAWS DAYSというJAWS(AWSユーザー会)の会合があり、私もパネラーの一人としてお話する機会がありました。そこで既存のSIerを袋だたきにしようという企画があり、そのときの内容が日経ITProで記事になったようです。こちらのパネルディスカッションの内容について、話しきれなかったことをお伝えしたいと思います。

最近いろいろなところでシステムの内製化なるキーワードを耳にします。要は「システムは社内で作った方がいいからその為の人は自社で抱え込もう」という話です。
こういう話が出てくる背景には、いくつかの典型的な要因が考えられそうです。

  • ベンダーへの不
    昨今ユーザー企業とITベンダーとの間の巨額な訴訟問題がニュースになったり、品質の低下やスピードの欠如など盛んに喧伝されています。外部のベンダー(SIer)に対して様々な不満がたまっているであろうことは想像に難くありません
  • リソースの逼迫
    更に頭が痛いのが「リソースの逼迫」です。ベンダー側も人手不足で、単金があがったり場合によっては仕事を断られたりして、必要な時に想定されるコストでオーダーする「便利なアウトソース先」としての利点が薄れています。ベンダー側もこれを補うために経験不足のスタッフをいれたりオフショアしたりした結果、品質の低下を招いてしまうといった悪いスパイラルが生まれています
  • ビジネスのデジタル化への遅れ
    ユーザー側には「もっと新しいことを提案して欲しい」という要求があるにも関わらず、なかなか具体的な行動には繋がっていないようです。これは仕方が無い部分もあると思うのですが、新しい技術というものは本質的に既存のやり方を壊したり効率的にするものなので、運用費用の低下を招いたり、既存の技術が使えなくなるなど「既存のベンダーにとって痛い方向性に進む」ものが殆どです。既存のベンダーに「君の会社に払うお金を少なくする提案をもってきてね(にっこり)」と言っても「いやいやいやいや」となるのが関の山です。こうした利益相反が「ベンダーからは新しい提案が出てこない」「ベンダーが先端技術に詳しいわけではない」という不満に繋がっているようです


こうした課題は大小を問わず多くのユーザーが抱えているようで、メディア等の記事を見ても「システム内製が正義で、外部のSIerを使うのは古くてダサい、間違った選択だ」という論調を目にする機会が増えてきました。
ですが、私はそうは思いません。
長期的に見れば、ユーザー企業によるシステムの内製化はうまくいかないと考えています。
これは、私たち自身が過去内製を行ってきた経験を踏まえて到達した、一つの結論です。

 

システムの内製化に何を期待するのか?

当然システムの内製化を試みる企業には、上であげたような一定の課題や不満があるわけです。そうした課題に対する解決策として内製化を期待することは合理的な判断に思えます。

  • スピードへの期待
    社内のリソースを使うわけなので、外部ベンダーの選定や契約手続き、業務理解といったプロセスを省くことができ、スピードが期待できる
  • コストへの期待
    外部リソースを使えばベンダーが得る利益の分システム開発コストが浮く。従ってアウトソースするよりも安く開発することができる
  • デジタル化への期待
    社内のメンバーであれば業務のことを理解しており、かつ最新のITにも詳しければ、クラウドの利用やIoT活用、O2Oモデルの確立などビジネスのデジタル化を進める上で最適である

 

なぜ内製化が答えにならないのか?

しかし、私たち自身が(小規模とはいえ)過去に内製化を行ってきた実績や、実際に大規模に内製を行っているユーザー企業の実態を見聞きした結果として、こうした期待は裏切られる確度が相当に高いと考えられます。

  • スピード要求に応えられな
    当たり前の話ですが、スピードを高める為には一定の頭数が必要です。ところが内製という選択をしてしまうと、自社で採用できているメンバー数がキャパシティの最大値になってしまう、オンプレミス状態が発生してしまいます。更に、社内の場合契約関係が発生しないため社内での流動性が高く、特定の忙しい部署にどんどん人が割かれてしまいます。SIerが「空いている時間でサービスを開発しよう」と思っても結局受託が忙しくて何も作れない、というのと同じ理屈です。こうした力学が、スピードを下げる方向に向かってしまいます。
  • コストは安くできない
    全てのIT企業が「人手不足」と言っている中で、「今から内製化します」というユーザー企業に優秀なエンジニアが集まるほど採用は甘くありません。現実的には人事部が多大な労力を割いて、高額な紹介料や採用媒体費用を負担して、サインアップボーナスを払い、ようやく採用できるのが現実です。配属先の部署はこうしたコストを負担しないため「やっぱり社内の方が安いじゃないか」と錯覚しがちですが、現実的には会社が採用のためのコストを負担している、つまり企業全体としてはコスト安にはならない訳です。
  • 社内だから業務に(もしくはITに)精通しているとは限らない
    間の時間は平等です。社内業務に精通している人はITに割ける時間が短く、ITに精通している人は業務に割く時間が短い。当たり前のことです。つまり、「最初から両方に精通している人をあてにする」行為自体が戦略の不完全さを現してしまっているのです。社内で業務に精通している人はそれだけITに割ける時間が少なくなります。これはIT戦略が不完全になってしまうリスクを伴っています。


実は私たち自身、過去にこうした問題を解決するためにシステムの内製化に取り組んでいたことがありました。クラウドインテグレーションという新しい事業を始めるにあたり既存のシステムでは対応できないため、新しい顧客管理システムを自作しようとしたのです。ところが、実際にシステム内製をはじめてみたところ、スピードは頭数に限定されるので開発スピードは上がらず、結局メガベンダーが開発しているクラウドサービスの方が、製品の成熟スピードも、自分たちの業務にフィットさせるためのスピードも早いということに気づいたのです(この話はSalesforce導入の話です。こちらに4年前のインタビューがありますので興味がある方はぜひご覧下さい)。

こういう話をすると、かならず「IT先進国アメリカではSIerというものが存在せずユーザー企業が自分でIT部門を抱えている」という反論がなされます。ですが、それは半分正しく、半分は間違っています。なぜなら「米国企業のIT部門が1万人のエンジニアを雇用していたとしても、その1万人の中身は10年前と今とでは全く人が違う」からです。
ですから、上の問いに対する私の答えは以下の通りです。

もしあなたの会社で、米国と同様に、いつでも契約を終了できるエンジニアを大量に集めてIT部門をつくることができるのであれば、米国と同様のインソースが可能でしょう。ですが、日本の雇用環境でそうしたことは事実上不可能です。米国企業が社員個人個人とJob Descriptionに基づき利用技術や業務内容を定めて契約行為を行うことと同じ事を、日本の企業はSIerとやっているだけです(もちろん成果物の責任をどちらが持つか、という違いはありますが)

この違いを理解せずに、米国の成功モデルを語ることは非常に危険です。
日本では一般論として雇用契約を会社都合で簡単に終了したりすることはできません。ですから、今ユーザー企業が「AWSを使うから」といってAWSのエンジニアを大量に雇用しても、5年後にAWSを使わなくなった時には全く別な技術を覚えてもらわなければいけないわけです。米国では、こういう場合にAWSエンジニアとの契約を終えて人を入れ替えるので、インソースしてもリスクが限定的なわけです。つまり、内製化がうまく行かないと考えるのは、ユーザー企業個別の事情ではなく、国内の雇用環境がそうさせてしまうことが理由だと言っているわけです。

じゃあどうするのか?

理想は 雇用の規制緩和を進める ですが、この実現には相当高いハードルが予想されるので、現実的には今のコンディションで最善を尽くすことになります。ユーザー側の選択としては以下の様になるかと思います。

  1. システムは原則として作らずに「使う」
    上記の通り、優秀なエンジニアの獲得はどこも難しい。しかもこれから少子化で労働人口も減っていくことを考えれば、アウトソースできるところは徹底的にやる、というのが基本原則です。メールやカレンダーといったコモディティーはもちろん、サーバーのお守りや物理セキュリティの確保などに貴重なエンジニアのリソースを割くべきではありません。こうした業務は社内のエンジニアにやらせるより、もっと大規模に、かつ精緻に行っているAmazonやMicrosoftに任せるべきです。
  2. 作るものを「競争力を向上させる」ものに限定する
    解が無いように言いますが、私は「システムは必要ない」といっている訳ではありません。優れたシステムは、企業の成長を支え、差別化し、競争力を獲得するために絶対に必要です。そして、システムのうち「何が自社独自の価値を生み出すもので、何はそうではないのか」を切り分けることが非常に大切になってきます。これはアイデンティティーの問題なので、社内で行われるべきです。
  3. ベンダーを戦略的に使う(アウトソースとパートナーシップの融合)
    ることになれば、徹底的に良い物を作るべきです。そして、業務への理解を少しでも深めつつ自社にフィットするシステムを作ってもらうためにも、アウトソース先に積極的に自社業務を理解してもらう必要があります。そのためにも、これまでのように都度都度コンペをするような使い方から、ベンダー側にも同じ担当者を長く担当させるモチベーションが働くような契約が求められます。例えばユーザーから発注する際に、EC2でいうRI(Reserved Instance)の様な契約体系にして、ブロックで発注する代わりに特定のSEやチームを貼り付けることで、業務理解を進め、IT専門家と中期的な関係を作りつつ、長期のリスクはオフロードするような契約体系がアイディアとして考えられます。


これに対して、ベンダー側の選択として考えられるものは大別して以下3つになろうかと思います。

  1. これまで通り)エンジニアリソースのバッファとして機能する
    繰り返しになりますが、日本の雇用環境下でユーザー企業が内製エンジニアを大量雇用するというアプローチは現実的ではありません。そのため、リソースのバッファとしてのSIerはかなり長い間ニーズがあると考えられます。
  2. クラウドサービスを提供する側に回る
    そうはいっても「作るよりは使った方が良いケースが増える」ことは間違いありません。これまでオンプレミスやパッケージ型、買い切り型で提供されていたものをクラウド化していくというのは、ユーザーの実状に即したよいアイディアだと思われます。
  3. クラウド利用の課題を解決する側に回る
    たちの様なクラウドインテグレーターはこの部類です。複数のクラウドを組み合わせるケースなど、現実世界とクラウド環境とをフィットさせるためには相応の技術とノウハウが必要とされます。実際、米国でもクラウドの複雑さにはユーザー企業が自力で対処できる範囲を超えていると認識されており、2012年のre:InventでもGartnerから「米国のクラウド利用企業が求めているサービスTop3」の1位に「インテグレーションサービス」がリストされているような状況です。この分野はクラウドの活用が進むにつれて大きな市場になると認識されています。

 

こうした現実的な選択によって、ユーザーとベンダー双方がよい関係を構築し、ユーザーはクラウド、IoTといったトレンドを取り入れビジネスのデジタル化を進め、競争優位を確立していくという流れは(内製に頼らずとも)実現できると私は確信しています。

いろいろなネットや雑誌記事などを見ていると、「問題に対する焦点の当て方が間違っている」と思われる言説が多数とびかっています。「問題はユーザーだ」「いやベンダーだ」と言い合って悪者探しをすることで、いっとき溜飲は下げられるかもしれませんが、根本的な解決には至りません。
私たちはクラウドというテクノロジーを用いて企業の課題を解決する会社です。問題に対する焦点が間違っていれば当然解決策も間違います(歴史的に見ても、ホロコーストや大躍進政策など、焦点の当て方が間違って悲惨な結果を招いた例は枚挙に暇がありません)。
私たちは常に、何が根本的な原因なのかを明らかにし、解決出来る物は解決する。独力で解決不能なものはそれを受け入れ、与えられた条件下でどうベストを尽くすのか考える。そういう集団で在り続けたいと願っています。その為にも、不毛な論争を打ち切り、前を向くための灯台となるべく筆を執った(キーを叩いた?)次第です。

震災から5年

今日で震災から丸5年が経ちました。

今でもあの揺れと、その後の痛ましい映像を忘れることはできません。
特にヘリコプターから撮影されていた名取市の津波は本当にショックで、私が学生時代に家庭教師をしていた地域が黒い渦に飲み込まれていく様は、恐怖と悲しみと無力感とでやりきれない気持ちになったことを今でもよく覚えています。
犠牲になられた全ての方のご冥福をお祈りすると共に、まだ避難生活を余儀なくされている全ての方々に、心よりお見舞いを申し上げます。

昨日、「震災の記憶を風化させないように」とのことでアマゾンさんが「会社の枠を越えたウェブサイト復旧支援 ~東日本大震災時にAWSユーザーグループのメンバーはどう行動したか~ (記憶の継承)」という無料のKindle本を出しています。
こちらの本とも内容は一部重複しますが、私たちが震災後に行った支援活動について、改めて日本赤十字社様から当時のお話を伺い、インタビュー記事に纏めております。

>>日本赤十字社様特別インタビュー「無関心を超えた先にある繋がりのある社会へ」<<

私たちは当初、日本赤十字社様に行った支援活動について公表していませんでした。ところがある日、西島部長から「この事例は公開すべきだ。公開して、利益を出して、そして税金を払うなり義援金を払うなりして欲しい。それこそが真の復興であり、真の社会貢献だ」と諭されたのです。

日本赤十字社様のキャッチに

人間を救うのは、人間だ


というものがあります。

西島部長から復興のあり方について指摘されたとき、(おこがましい物言いは承知で言うと)「人間を救うのは自分の行動なんだ」ということを改めて思い返し、それが今の私たちを突き動かす原動力となっています。

5年も経つと、本当にいろいろなものが変わります。
記憶も少しずつ、薄れていきます。
ですが、形あるものが壊れ辛い記憶が風化しても、明るい未来をつくるという気持ちだけは変わらずに、私たちの仕事が少しでも日本と世界の将来に繋がることを信じて、生かされた毎日をしっかりと歩んでいきたいと思います。

人事制度と「まんじゅう」

こんにちは、大石です。

当社では、楽天とそのグループ会社で8年間人事課長を勤めておられた新井さんという方と「会社が成長するための人事評価制度」というものを一緒に作っているのですが、先日制度のレビューを一緒に行っている中で面白い議論がでてきました。

それが、「成果ってまんじゅうだ」という話です。

私たちが人事制度を導入している目的は

(1)公平かつ納得感のある評価を行うことで、業務に専念しやすい環境をつくること
(2)評価を通じて個人と会社の成長をたすけること

という2つなのですが、その中で「成果をどのように評価すべきか」という議論になったときに出てきたメタファーがこれです。

  • 皿=人として基本的な資質
  • まんじゅう=成果の大きさ・会社への貢献度合い
  • 皮=当然やるべき仕事
  • あん=個人毎に特徴づけられる達成目標

 

私たちの会社では「定量的な目標設定」と「行動指針に基づく定性評価」の2つを軸として評価を行っているのですが、実際に運用してみるといろいろな課題にぶつかります。

例えば、「行動指針の評価がどのように成果につながるのかがわかりにくい」という声だったり「目標を設定してそれを達成してもすぐに給与に反映されたりするわけではない理屈が納得できない」といったような(どこの会社にもありそうな)話がやはり当社でも出てきます。

それに対する新井さんの答えが、

1. MBO制度を取り入れてすごくうまく行っている、という企業の話は聞いたことがない。それでも『やらないよりはやったほうがマシ』というのが殆どの企業における現状

2. 目標設定をすると、会社の業績に直結しない目標を設定するケースがかなり見受けられるが、1次評価者の側にも確証がないので、それが漫然と受け入れられているケースが多いのではないか

とのことでした。

会社としては本来「業務を通じて会社に貢献してくれた人」を評価したいハズだが、「目標設定」を行うと「業務としてやるべきことをやる」といった当たり前のことが抜け落ちてしまい、目標の達成度に応じて評価が決まるという矛盾が生じたり、目標を達成したのに評価されないという不満がでてきてしまうとのこと。

マネージャーの経験がある方だったらだれでも同意できると思いますが、例えば「資格を取得する」といった目標を立てたエンジニアAさんとBさんがいたとして、Aさんは目標を達成しなかったが、業務を通じてとてもチームに貢献してくれている Bさんは目標を達成したが業務での貢献度合いが希薄だった、というケースでは、当然Aさんを評価しますよね?ところが目標管理による評価をすると、逆にBさんが高く評価されてしまう様なことが起きてしまう、という問題点が起こりえるとのこと。

このような議論をしていて、本質的に成果というものは「まんじゅう」の様なもので、明文化されることは少ないが成果の大半を占めている「皮」の部分と、個人を特徴づけ、かつ目標管理プロセスの中で明確化される「あん」の部分との2つで成っている、という話になったのです。

manju

そして「あん」は「皮」からはみ出てはいけない。あくまで会社の業績向上につながることで(つまり皮と一緒にいただくことで)はじめておいしくいただけるものだ、ということと、逆に「あん」だけ出されてもダメで、あんも「皮があっておいしくいただける」つまり、業務による会社への貢献が第一義だということに気づいたわけです。

エンジニアのみなさんも、「勉強会とかでは活躍しているけど、会社の評価は低い」という人のウワサを聞いたことがあるかもしれません。勉強会などではお互いに「あん」を見せあうので美味しそうに見えますが、やはり本当に評価される人というのは、あんと皮がバランス良くセットになっているのだと思います。

私たちの人事評価制度に対する理解:

  • 評価制度というものは、どうやって「人の成長」を助けるかという仕組みのこと。まんじゅうのメタファーで言うと「どうやってまんじゅうを大きくするか」という話
  • 皿が大前提。人として、チームとして一緒にはたらくことができるかどうか、といった人間的な本質(当社でいえば行動指針)。ここが大きくならないと、そこにのるまんじゅうはこぼれてしまい、大きくできない。例えば、チームメンバーの売上を横取りしてとってきた成果など「皿に載っていないまんじゅう」はそもそも皿に載っていないので食べることすらできない
  • 皮が最も大切。当たり前すぎて評価制度などで明文化されることが少ないが、これこそがまんじゅうの大きさ=成果の大きさを決定する要素
  • あんはアクセント。もちろん、まんじゅうをいただくにはあんを目指して食べていくが、皮があることが暗黙の前提。あんだけ出されてもおいしくない
  • 評価とフィードバックのプロセスを通じて「皿を大きくし」→「皮を大きくし」→「あんを大きくする」これによって結果として「まんじゅうが大きくなる」これが評価制度の理想

 

というわけで、人事制度の運用を通じてお皿を大きくし、その上でつくられる成果を大きくする。それをリピートすることができる人財の育成に、より力をいれて取り組んでいきたいと思います。

貴重な時間を割いて有意義な気づきを与えて下さった新井さんに改めて感謝します。まだコンサルは受けられるそうですので、興味のある方は問い合わせされることをオススメします!

棚上げ力

いやぁ、最悪ですね。


何が最悪かって、例の宮崎議員です。
私が「宮崎さんが言ってることは正しいから頑張れ!」と応援ブログを書いて、厚切りジェイソンとかサイボウズの青野社長とか業界有名人のみなさんが「そうだそうだ!」と後押ししてくれたのにこのザマです。なんということでしょう・・


失望とはこのことです。
辞職も当然ですね。
「政界復帰にふくみ」なんて言っていますが、もう信じる人はいないでしょう。

 

・・・

 

ですが、それでもやっぱり、私は彼のやろうとしていたことは正しいと思います。

私がもっとも懸念するのは、この件で「国会議員でも育休をとる」という議論が封殺されてしまうことです。国会議員が育休を取れれば、民間企業につとめる人、公務員として働く人、いろいろな人がもっと育休を取りやすい環境が作れたハズです。
そうした議論が暗黙のうちに霧消してしまうのは、誰のためにもなりません。
この件に限らず、私は議論をする際に「誰が言ったのか」ではなく「何を言ったのか」で判断すべきだと信じています。

昔、漢の高祖劉邦は「姉嫁と不倫している」「ワイロを受け取っている」など不逞の輩というウワサがあったものの、知謀に長けた陳平を最後まで使ったことで中国を統一したそうです。
秦の秦王政は、鄭国が韓のスパイ(韓への進行を遅らせるために秦に治水工事を薦めていた)と知りつつも、メリットがあるからという理由で治水工事を行ったことで、結果として秦を強国に押し上げました。

「その人のふるまい」と「言っていること、考え」を分離することで成功した先人の話は、歴史が教えるところでもあります。

 

私の口グセのひとつに「棚に上げろ」というのがあります。
よく社内でも「それは棚に上げて伝えよう」とか「棚に上げて言うけど・・」といって議論をしたりします。
会社で「お前が言うな」という声が上がり始めたらアウトだと思っているのです。

「お前が言うな」が是とされてしまうと、ポジションが上だったり、経験があったり、技術力が上だったりと、聖人君子のような人からしか声が上がらなくなってしまいます。
ですが、会社のオペレーションや文化といった、些細な、しかし重要なことを正していくのは、業種業態にかかわらず「現場の声」のはずです。そうした小さなフィードバックをきちんと改善に活かせるかどうかが、企業として継続し、成長を続けるためには絶対に必要不可欠だと思うのです。
不正会社を起こした会社などは「何を言う」よりも「誰が言う」が優先された結果、現場の声は封殺され、トップ主導の会計不正が常態化してしまったのでしょう。

 

宮崎(元)議員の件は残念です。
残念ですが、私たちが学ぶこともありました。

  1. 国会議員といえども、育休は取り、子育てしやすい社会を作ることは(誰がいったかどうかに関わらず)国民が共有すべき課題であること
  2. 誰が言ったか、そしてその人の行いの是非は棚に上げて、良いと思うことは採りあげること
  3. 自分のことは棚に上げて、それが会社や社会にとって必要だと信じるのであれば、言うべきことは言うこと

 

 

最後に、

 

文春スゲー!

全体最適が苦手な日本人

こんにちは、大石です。

今日はスゴい雨と雪でしたね。
当社は天候によって出社が困難だったり、ムリな出社によって生産性が落ちると考えられる場合は、申請で在宅勤務もできるようになっていますので「今日は半分くらいが家で仕事するんだろうなー」と思っていたら、facebookで知り合いの方がこんな投稿をあげていらっしゃいました。

 hiroki

これを見て、昔アメリカ人の方に言われたことを思い出しました。

「日本人は非常に個人主義的だ。震災の時に特にそう思った。あれだけ駅前でタクシーを待っていても、誰も(同じ方向の人同士で)乗り合わせようとしない。自分が良ければいい、という考えの最たるものだ。よく日本は集団的、アメリカは個人的と言うが実際は逆だ。」

私も思わず「なるほど」とうなってしまいましたが、日本以外の方にはこう見えるようです。

言われてみれば、エスカレーターなんかも左側に行列して、右側はスッカスカ、ということがよくありますね。右側にも立てば理屈の上では行列が半分になるはずですが、居るか居ないか分からないけど急いでいる人のために全体の輸送効率が落ちる並び方を無意識にしてしまっています。

先のfacebookの投稿を見て、私たちには「思考のクセ」みたいなものがあって、全体の効率を下げていることが他にもあるのではないか?と考えてみました。

hikaku

もちろん「会社に出社する」という行為は非常に大きな意味のある行為、個人にとっての美徳だと私も思いますが、一方で「それが今日でなければいけないのか?」「それによって社会で失われているものはないのか」という問いについてはクエスチョンです。
どうしても私たち日本人は「個人の美徳」に目が行きがちで、実際そのような思考のクセというものがあると思うのですが、もっと全体としての効率や最適に目配りして意思決定しましょうと。その文脈で、システムも個別に最適化されたガチガチのシステムよりも、もっと柔軟でしなやかな「クラウドを組み合わせたシステム」にすることで、全体としての最適を目指しましょうという話だと思うのです。

こうした「美的感覚」の話に、ロジックで対抗することは困難です。実際、私も「エスカレーターで左側一列は非効率だから右側も使いましょう」と言われても「えっ?」となります。私たち自身、お客様にクラウドの説明をして個別最適から全体最適への変化を説明しても「えっ?」と言われることはままあります(例えば、今まではサーバー1台1台の可用性が重要だったが、クラウド時代ではインスタンス1台の可用性よりもシステム全体としての可用性の方が重要ですよ、という話とか)。
ですが、こうした思考の壁を乗り越え全体最適にたどり着くことが、今の私たちには必要な様に思われるのです。

 

これからオリンピックを迎え、日本人だけでは「左側一列」が当たり前だった世の中に「なんで?右も使った方が効率的じゃん」と考える外国人が(たぶん)大挙して押し寄せてきます。そんな時に、「日本のルールを守れ」と拒絶するのではなく、彼らが見ている全体最適の世界を見て、私たちも学ぶものがあるのではないかと今から期待しています。

TOP