これからの主流になるのか、マルチクラウドという設計

最近増えてきました、IaaSのマルチクラウドでインフラを設計構築したいという話し。なぜそういう話しが出てくるのか考えてみました。

マルチクラウドの動機

マルチクラウドにしたいとは例えばAWSとAzureを両方使える環境を整えたいというニーズになりますが、やはりベンダーロックインを回避したいという動機が主ではないでしょうか。オンプレミスにおけるデータセンターの複数拠点やハードウェアメーカーを複数用意するというような感覚に近そうです。ただ、データセンターやハードウェアは別であってもある程度標準化された技術で対応できますが、クラウドはソフトウェアなので同じ機能でもその仕様やAPIなどは異なり、スキルとしては二重に用意する必要があります。会計ソフトを冗長化するために勘定◯行と大蔵◯臣を両方使うみたいな、そんな印象です。

続きを読む

目的・現場・我慢、マネージャーに必要な能力

この前、マネジメントに必要な業務は方向を揃えることだと書きました。

hashiva.hatenablog.com

では、そのマネージャーはメンバーの方向性を揃えるためにどんな能力が必要か、3つ挙げてみたいと思います。

  1. 目的を深く理解する
    揃えようとしている方向性がそもそも間違っていたら元も子もありません。マネージャーは会社の事業の目的を深く理解することが必要です。なぜを繰り返すとはよく言ったもので、まさに何故を何度も繰り返し、目的を深く理解すること。深く理解するまで考え、上司や同僚とも摺り合わせを行い、予期しない事態には目的から判断ができることがとても重要です。

  2. 現場を深く理解する
    自分が関わる事業の現場を深く理解することがマネージャーには必要です。ほんとうはマネージャーでなくても必要ですが、マネージャーは特に現場に近いところにいてメンバーの状況を理解しつつ方向性を整えることが大事です。そもそもビジネスの現場がわかっていないと会社の方向性などわかるはずがないので、逆に言うとマネージャーは中間管理職という辛い立場だと言われがちですが、最も現場と方向性を理解しやすい立場なのかもしれません。
    たまにいますよね、現場わからないし普段は興味もなさそうで丸投げなのに、自分の都合が悪いことを聞きつけると突然権力使うマネージャー、そういうの見るとがっかりします。(あくまで一般論です)

  3. 絶妙に任せ我慢する
    我慢するというと誤解がありそうですが、我慢することはマネージャーの大事な仕事です。自分がやった方が早いという場面はマネージャーなら多々あると思いますしやりたくなってしまうのですが、メンバーに任せたのなら我慢です。ただし先のような丸投げはいけません。見届けること、必要に応じてフォローすることが大事です。絶妙に任せるということは方向性を整え任せることと同じです。この匙加減は私もわかっていないので、任せすぎて反省したり、やりすぎて反省したりを繰り返しています。

まだまだあるでしょうけど、私はこのへんを意識しています。ではでは。

一体何をするのが大事か、マネジメントの仕事

私はサーバーワークスで部長をしています。経緯は忘れましたがぶちょおと呼ばれています。

部長なのでマネジメントをしているのですが、個人的にあまりマネジメントをしている実感がなく、プレイヤーも好きなのでプレイングマネージャーをやっていることもあって、あまり意識していなかったのだと思います。ただ新任のマネージャーも増えてきたため、彼らが試行錯誤をしているのを見て、私のマネジメントってどうだったかなと考える機会がありました。というわけで現場マネジメント寄りの話しです。

 

結論から言うと結局は方向性を揃えるくらいしかやっていないなと。ただ方向性を揃えることがとても重要だとも感じました。

方向性とはもちろん会社の方向性であって、各メンバーがその方向に向かって仕事をしているかが大事です。この方向性って意外と難しくて、当然全体の方向は代表からとかちょいちょい共有していますが、やっぱり微妙に認識が違ってたりします。また、もちろんその先にはメンバー自身のスキルアップの方向性ともバランスしていることも必要ですが、個人的にはほんの少し会社の方向性を優先した方がよいと思います。理由は後ほど。

 

いろいろなメンバーを見てきて、方向性がずれる場合もいきなり明後日の方向にいく人は少なくて、少しずつ、少しずつズレます。これをほっておくと大きなズレになります。大きなズレになってくるとどうなるかというと、自分のやっていることは正しいはずなのに、なぜか社内で浮きはじめ、コミュニケーションロスが発生し、争うようになり、イライラし、モチベーションも下がり、結果も出にくく、もし結果が出ても長続きしません、たまたまです。こういうときは周りから見ても何故今その仕事?ちょっとそれ違くね?みたいな印象があるようです。

ズレるのはほんの少しずつなんです。そのズレを調整するのがマネジメントの大事な仕事です。これはマネジメントする立場の方が方向性が見やすいからです。例えば私は、おそらく代表とは最も会話をしているし、他のマネージャーと会話する機会も多く、他チームの課題や案件の話しも聞きます。縦と横のコミュニケーションが多いので会社の方向性は見やすいです。で、その方向と照らし合わせて、ほんのちょっとずつ方向性を調整します。

ではどう方向性を調整するのかというと、主には本人との定期的な会話による摺り合わせが大事ですが、それだけではなく、例えば横連携や縦連携などの同じ組織でも根回しが難しいときはその部分を支援したりきっかけを作ったり、難しい商談・案件には実支援することもあります。ちなみに根回しをしやすいのもマネジメントです、理由は上述のとおり。

 

ここで匙加減が難しいのが、どの程度方向性を調整して、どの程度支援するかということですが、私の感覚としては最低限でよいと考えています。ただし最低限ではあるものの定期的が大事です。基本的にマネージャーに得意分野があるように、メンバーにも得意分野があって、勝手に走らせた方が速いです。ただ、ちょっとだけ方向性を注意すればよいというイメージです。

先に出た、会社の方向性を少しだけ優先した方がよい理由は、結果が出た方が結局は個人の能力伸長に繋がり、前向きになり次に繋がるからです。あくまで確率の話しですが方向性を整えた方がいわゆる全社一丸になりやすく結果も出やすいですよね。少なくとも勝手に自分のやりたいように仕事して、制御する人もいなく、周りとのコミュニケーションも全くなく成果を継続的に出している人を見たことはありません。

 

まとめると、

  • マネジメントの仕事は方向性を整えること
  • メンバーには勝手に走らせた方が速いことを認識すること
  • ほんの少しを定期的に行うこと

が少なくとも私たちの会社規模のマネジメントの大事な仕事かなと。

ではでは。

 

取締役でも簡単!SA Proの取り方

以下のブログに触発されて、取締役版です。

AWSの資格である Solution Architect Professional は極端に難しい資格ではありませんが、簡単でもないようです。取締役の方々でも取得すれば自信に繋がると思います。

okeees.blogspot.com

 

ちなみに私は技術は好きですが営業一筋16年です。ただし決して営業が好きなわけではありません。

対象の取締役

  • インフラからアプリまで基礎技術は多少わかっている
  • AWSを触る時間はほとんどない
  • でもやっぱりAWSは最高だなと思っている

勉強すること

  • AWS Black Belt Tech WebinarのSlideShareを見る
    取締役は時間がないと言いがちなので、せめて以下のBlack Beltについて一通り目を通すとよいと思います。

    aws.amazon.com

  •  設計例を見ておく
    取締役とはいえ取り締まってばかりいないで設計イメージを膨らませておく必要があります。Black Beltだと各サービスの理解は深まりますが、全体設計でのイメージをもう少し湧かしておいた方がよいので事例における設計例を見ておくとよいです。このあたりがよいかと。

    国内のお客様の導入事例 Powered by AWS クラウド | AWS

  • 例題や模試を受けてみる
    取締役はプライドが高いので例題は模試は基本的には受けません。ただし一般的には受けてみた方がよいと言われています。

当日

  • よく眠る
  • 朝ごはんをちゃんと食べる

 

以上です。取締役とはいえちゃんと勉強することをお勧めします。

AWSをもっと企業に、Amazon Web Services 企業導入ガイドブックを読みました。

3日間のAWS Summitが終わりました。事例の話しや技術的な内容など含め魅力的なコンテンツが多く、出展していた私たちとしてはお祭り気分でした。

その中で、先行販売していた「Amazon Web Services 企業導入ガイドブック」を早速読みましたので、感想を書いてみたいと思います。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

 

一言でどんな内容か

その名のとおりAWSを企業システムに導入する際における分析手法からオンプレとの考え方の違い、よく聞く挫折ポイントからの対処方法などが広く書かれています。企業システムのAWS導入に関わる方であればユーザー企業であれSIerであれ全ての方に一読をお勧めできる内容です。

誰が読むとよいのか

先に書いたとおり企業システムのAWS導入に関わる全ての人になりますが、特に中規模〜大規模のシステムにおける導入に携わる方々の方が合ってます。サーバー台数で言うなら30台以上が目安になると思います。

なぜ読んだ方がよいのか

著者陣が著者陣なこともあり特にAWSの概念がよく理解できます。概念が理解できると導入のアプローチが変わってきますので、よりAWSにフィットした導入が検討できます。私もまだまだ見かけますが、企業システムのAWS導入を検討されている中で、ただのハードウェアリプレース先のいち候補としてのみ位置付けられていることがあります。半分間違ってはいませんが、そもそもハードウェアではありませんので半分は間違っています。その理由が丁寧に説明されていて、それを理解した上での導入プロセス例が記載されているので導入までのイメージが明確になってくると思います。

この本の足りないところは

AWSの各サービスの説明や技術的な部分については軽く触れるに留まっています。そもそもフォーカスが違いますので、他で補完すればよいです。

 

以上です。画面キャプチャやソースコードは殆どない中で、このボリュームは大変だっただろうなと。それと少しコンサル領域にも関わる内容も含まれているので、一貫性を持たせつつ自然な流れにすることも難しかっただろうなと。著者陣の方々お疲れ様でした、非常によい本です。私たちの今後の提案にも活かしていきたいと思いまっす。

 

Slackでイラッとしない、コミュニケーションのコツ

社内コミュニケーションツールとしてサーバーワークスではSlackを使っています。

Slackは便利な一方でテキストでのコミュニケーションは注意が必要なため、以下のようなガイドラインがあります。

  • 否定しない
  • 叱責しない
  • 2回で伝わらなければf2f

これはこれで大事なのですけど、やっぱりちょいちょいイラッとすることってありますね。言葉の言い回しってテキストではより重要です。文章はニュアンスが伝わりづらいので誤解を招きやすく、それを見た相手が不愉快さを感じるとその後に少なからず影響する。それが積み重なるとコミュニケーションロスが発生する。悪い循環です。

Slack見てると、それが上手い人と下手な人っています。でもよく見るとちょっとした言い回しくらいしか違いがありません。3つほど紹介します。

1. 語尾をちょっと緩める

語尾を少し口語というか緩い感じにするだけで随分違います。

***してください。よろしくお願いします。

この文章、普通ですが実は命令口調に感じる場合もあります。

***してくださいまし。よろしくお願いしますー。

女性向けですがこれだと大丈夫そうです。2-3文字の追加で違いますね。

***してもらえると助かります。よろしくお願いしまっす。

この「まし」とか「すー」とか「まっす」などの語尾でずいぶん違うと思います。気にする人は気にするもんです。

2. 依頼時ははじめにクッション

コミュニケーションツールでは依頼事は飛び交うものです。依頼するときは、はじめにクッションがあるだけで随分違います。

***の対応をお願いします。

普通の文章なのに冷たく感じます。

すません、***の対応をお願いします。

これでずいぶん違います。はじめにクッションを入れるだけで表現が柔らかくなります。

すません、***の対応をお願いできますと助かりまっす。

ここまでくると、冷たい印象やイラッとくることはなくなると思います。純粋にその対応についてできるかできないかの判断ができます。命令調だとそれだけで断りたくなるのは人間の心理です。人によっては無駄な労力に見えるかもしれませんが、人間だものそうはいきません。

3. ちょっと肯定する

うちのガイドラインでは否定しないと明記されているのですが、やっぱりちょっと否定したくなるときってありますよね。そんなときは否定文を使わずちょっと肯定して自分の意見を通してみることをお勧めします。

そうではありません。***だと思います。

完全に否定なのでうちのガイドライン違反です。

 ***はその通りですね。ただ***じゃないかなと思いまっす。

こうすると意見通りそうです。Yes but法ともちょっと違います。実際に否定していないので否定されていることさえ気付かないでしょう。「ですよね」みたいなリアクションを付けてくれます。

 

他にも色々ありますが、こういう細かい気遣いが円滑なコミュニケーションに繋がり、リモートワークのメンバーともスムーズに業務が遂行できると思います。ここに文章力は必要ありません、気遣いが必要です。クラウド専業ベンダーとして、働く場所はもっと自由にしていきたいと思ってます。その中でも高いパフォーマンスを発揮するためにはメンバー同士の円滑なコミュニケーションは必要で、コミュニケーションツールでやりとりする場合のちょっとした気遣いが自然とできるようになるといいですね。

 

サーバーワークスに入社して丸10年が経ちました

サーバーワークスに入社したのが2006年4月24日でした。なので丸10年経ちました。当時の社員はたぶん5-6名だったと思います。せっかくなので簡単な歴史を書いてみます。

  • 2006年4月
    営業一号として入社しました。部は存在していませんでしたが名刺のタイトルは法人営業部主任だったと思います。IEは辛うじて知ってましたがFirefoxは知らず、エディタも知らず文章作成はWordを使い、Excelは多少使ってましたがPowerPointを使ったことはありませんでした。代表からコマンドプロンプトでgetコマンドを見せてもらい完全に業界を間違えたと認識しました。
  • 2006年5月
    当然教育プログラムみたいのはなく、先生役と聞いていた新井守という人が何も教えてくれないので自由度の高い教育方針であったため自習する力がつきました。日経NETWORKとか日経SYSTEMSとかSoftware Designとかの過去3年分くらいを延々と読んでいました。
  • 2006年8月
    某馬の案件とか宅食の案件を担当し始めたのこのあたりでした。
  • 2006年12月
    第一回の社員旅行。新井守と梶原誠二という人が相撲をとっていました。
  • 2007-2008年
    いろいろあって某案件のサーバー構築とか1人月程度の簡単なアプリケーションを一人で実装して納品しつつ、NetScalerの外販を始めました。プライベートでは合コン席順システムなども作り、2回ほど実戦投入しましたが成果は出ませんでした。
  • 2009年
    インフラリーダーの新井守という人が辞めると言うので、インフラリーダーも兼任することになりました。基本は応援に徹し、最も応援したのはある検定協会のPtoV案件でした。その結果、インフラメンバーが驚異的に成長したので1年で兼任を解除されました。
    AWSの外販をスタートしました。たくさんまわって素晴らしさを伝えましたが成果は出ませんでした。
  • 2010年
    CloudworksというAWSの日本語操作ツールをプロダクトマネージャーとしてリリースしました。でもリリース後3ヶ月で営業に専念して欲しいとのことで外れました。
  • 2011年
    震災対応をしました。
    事実上2人目の営業メンバーが入ってきました。これが後に料理ブログで有名になりました。
  • 2012年
    事実上3人目の営業メンバーが入ってきました。これが後にクラウド婚で有名になりました。小室さんもこのあたりでの入社かな。営業サポートメンバーも女性だったので一時女子バレー部の監督と呼ばれていました。
  • 2013年
    取締役になりました。
  • で今に至ります。

前職は食品業界で業務用食材の営業をしていたので、IT業界知識ゼロの私にとってサーバーワークスへの入社は運がよかったと思います。前職でも営業が食材知識を勉強していたので、営業一号でしたが周りは全員技術を知っている人達だったこともあり、何も疑わずに自然と技術を勉強できました。

何をやるかより誰とやるかっていい言葉で、環境はとても大事だと実感しています。まだまだ課題はありますが改善を続けよりよい仕事環境を作りつつ、皆が勉強し新しい技術を楽しみ学び切磋琢磨しながらよいものをお客さんに提供し続け、とはいえ仕事人間にならずプライベートな時間もしっかり楽しもうという文化はこれからも大事にしたいと思います。