iPadだけで3日間仕事して、いけてるとこいけてないとこ

Macbookのキーボードが壊れました。スペースキーを押すと戻ってこないため凄い速さで変換されてしまい仕事にならないので修理に出しました。

それでせっかくの修理期間中なのでiPadで仕事をしてみることにしました。iPadでWorkSpacesという選択肢もあったのですが、最先端はネイティブアプリだろうという思い込みです。そこでの感想をまとめます。

環境

iPad:たぶん3年前くらいに購入した普通のiPad

キーボード:代表が持っていたLogicoolを借りる

ちなみにキーボードはMicrosoft社製のも2つほど借りて試して悪くはなかったのですが、iPadはそもそも英語配列の方がよいですね。そういう仕様みたいです。

f:id:takashihashiba:20171107105842j:plain

いけてるところ

軽い

キーボードも200gくらいのを使ったので軽いですね、電源も軽いのでMacbook軽いとはいえ更に軽いです。

意外とキーボード入力はいける

外付けキーボードに慣れてしまえば意外といけます。

ネイティブアプリまずますいける

主にBoxとSlackを利用しましたがBox内のOfficeファイルからの直接編集は問題なくできました。パワポとかExcelとか大丈夫すね。SlackもMacのネイティブアプリと遜色ないです。
ちなみにOneloginは主にブラウザから利用してましたがこれも問題ないです。

GsuiteのメールはブラウザでPC版表示して利用しました。現状ではGmailはブラウザでのタブレット版やネイティブアプリではショートカットに対応していません。メール処理をスムーズにするためにいろいろ試したなかで、結局はブラウザでPC版にすることでショートカットが効いたのでよかったです。

いけてないところ

マルチタスクがやっぱりちょっと厳しい

Macと同じようにcmd+tabでアプリケーションは切り替えられるのですが、iPadだと利用していないアプリケーションは停止状態になっているため切り替えからのアプリ復旧時間が数秒かかります。これイヤでした。

また、Boxのアプリを利用するなかで例えばBox noteを開きながらパワポ資料を開くようなことは現状できないので不便でした。

無線が遅い

BluetoothなのかiPadの性能なのか、多分両方だと思うのですがキー入力の反応はワンテンポ遅いです。微妙に後からついてくる感じ。

Wifiネットワークも遅かったです。10MBのファイルを開くと5分くらいかかりました。これは私のiPadの性能だと思います。

ブラウザの表示がPCなのかモバイルなのかコロコロ変わる

ブラウザでSalesforceやQuestetraを開くと、Salesforceは例えば稟議承認画面が急にモバイル表示に変わり詳細が見えないとか、よくありました。都度都度PC版をリクエストすればよいのですがちょっと面倒でした。デフォルト設定とかできたのかもしれません。

まとめ

今回の修理期間ではメール処理やOfficeとの格闘がメインだったのでそこそこ仕事になりました。初代iPadで昔試したときはハード面やネイティブアプリ面等々全く仕事にならなかっただけに進化していることを実感しました。ただ、今Macbookが返ってきてこうブログを書いていると、やっぱりMacbook最強です。iPad Proだとちょっと違うのかもしれません。またいつか試して技術の進化を実感してみたいと思います。

 

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

最近増えてきました、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法ともちょっと違います。実際に否定していないので否定されていることさえ気付かないでしょう。「ですよね」みたいなリアクションを付けてくれます。

 

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