新年のご挨拶

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

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

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

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

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

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

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

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

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

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

こんにちは、大石です。

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

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

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

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

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

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

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

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

と問うてみて下さい。

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

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

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

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

サーバーワークス アドベントカレンダー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つで成っている、という話になったのです。

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

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

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

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

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

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