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

こんにちは、大石です。

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

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

ここで毎年、AWSのパートナーランク最上位である「プレミア コンサルティング パートナー」の発表が行われるのですが、当社も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つの段階があることが示されました。

これは私たちの実感とも完全に一致しています。特に最近は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のテンプレート、ドキュメント、テストコードなどの生成を自動化しているから、素早く、そして正確なデリバリーができるということをお伝えさせて頂きました。

実際、社内では既に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つで成っている、という話になったのです。

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

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

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

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

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

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

棚上げ力

いやぁ、最悪ですね。

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

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

・・・

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

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

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

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

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

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

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

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

最後に、

文春スゲー！

全体最適が苦手な日本人

こんにちは、大石です。

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

 

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

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

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

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

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

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

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

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