Macbookのキーボードが壊れました。スペースキーを押すと戻ってこないため凄い速さで変換されてしまい仕事にならないので修理に出しました。
それでせっかくの修理期間中なのでiPadで仕事をしてみることにしました。iPadでWorkSpacesという選択肢もあったのですが、最先端はネイティブアプリだろうという思い込みです。そこでの感想をまとめます。
キーボード：代表が持っていたLogicoolを借りる
ちなみにキーボードはMicrosoft社製のも2つほど借りて試して悪くはなかったのですが、iPadはそもそも英語配列の方がよいですね。そういう仕様みたいです。
キーボードも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の性能だと思います。
ブラウザでSalesforceやQuestetraを開くと、Salesforceは例えば稟議承認画面が急にモバイル表示に変わり詳細が見えないとか、よくありました。都度都度PC版をリクエストすればよいのですがちょっと面倒でした。デフォルト設定とかできたのかもしれません。
今回の修理期間ではメール処理やOfficeとの格闘がメインだったのでそこそこ仕事になりました。初代iPadで昔試したときはハード面やネイティブアプリ面等々全く仕事にならなかっただけに進化していることを実感しました。ただ、今Macbookが返ってきてこうブログを書いていると、やっぱりMacbook最強です。iPad Proだとちょっと違うのかもしれません。またいつか試して技術の進化を実感してみたいと思います。
最近増えてきました、IaaSのマルチクラウドでインフラを設計構築したいという話し。なぜそういう話しが出てくるのか考えてみました。
マルチクラウドにしたいとは例えばAWSとAzureを両方使える環境を整えたいというニーズになりますが、やはりベンダーロックインを回避したいという動機が主ではないでしょうか。オンプレミスにおけるデータセンターの複数拠点やハードウェアメーカーを複数用意するというような感覚に近そうです。ただ、データセンターやハードウェアは別であってもある程度標準化された技術で対応できますが、クラウドはソフトウェアなので同じ機能でもその仕様やAPIなどは異なり、スキルとしては二重に用意する必要があります。会計ソフトを冗長化するために勘定◯行と大蔵◯臣を両方使うみたいな、そんな印象です。
続きを読むこの前、マネジメントに必要な業務は方向を揃えることだと書きました。
では、そのマネージャーはメンバーの方向性を揃えるためにどんな能力が必要か、3つ挙げてみたいと思います。
まだまだあるでしょうけど、私はこのへんを意識しています。ではでは。
私はサーバーワークスで部長をしています。経緯は忘れましたがぶちょおと呼ばれています。
部長なのでマネジメントをしているのですが、個人的にあまりマネジメントをしている実感がなく、プレイヤーも好きなのでプレイングマネージャーをやっていることもあって、あまり意識していなかったのだと思います。ただ新任のマネージャーも増えてきたため、彼らが試行錯誤をしているのを見て、私のマネジメントってどうだったかなと考える機会がありました。というわけで現場マネジメント寄りの話しです。
結論から言うと結局は方向性を揃えるくらいしかやっていないなと。ただ方向性を揃えることがとても重要だとも感じました。
方向性とはもちろん会社の方向性であって、各メンバーがその方向に向かって仕事をしているかが大事です。この方向性って意外と難しくて、当然全体の方向は代表からとかちょいちょい共有していますが、やっぱり微妙に認識が違ってたりします。また、もちろんその先にはメンバー自身のスキルアップの方向性ともバランスしていることも必要ですが、個人的にはほんの少し会社の方向性を優先した方がよいと思います。理由は後ほど。
いろいろなメンバーを見てきて、方向性がずれる場合もいきなり明後日の方向にいく人は少なくて、少しずつ、少しずつズレます。これをほっておくと大きなズレになります。大きなズレになってくるとどうなるかというと、自分のやっていることは正しいはずなのに、なぜか社内で浮きはじめ、コミュニケーションロスが発生し、争うようになり、イライラし、モチベーションも下がり、結果も出にくく、もし結果が出ても長続きしません、たまたまです。こういうときは周りから見ても何故今その仕事？ちょっとそれ違くね？みたいな印象があるようです。
ズレるのはほんの少しずつなんです。そのズレを調整するのがマネジメントの大事な仕事です。これはマネジメントする立場の方が方向性が見やすいからです。例えば私は、おそらく代表とは最も会話をしているし、他のマネージャーと会話する機会も多く、他チームの課題や案件の話しも聞きます。縦と横のコミュニケーションが多いので会社の方向性は見やすいです。で、その方向と照らし合わせて、ほんのちょっとずつ方向性を調整します。
ではどう方向性を調整するのかというと、主には本人との定期的な会話による摺り合わせが大事ですが、それだけではなく、例えば横連携や縦連携などの同じ組織でも根回しが難しいときはその部分を支援したりきっかけを作ったり、難しい商談・案件には実支援することもあります。ちなみに根回しをしやすいのもマネジメントです、理由は上述のとおり。
ここで匙加減が難しいのが、どの程度方向性を調整して、どの程度支援するかということですが、私の感覚としては最低限でよいと考えています。ただし最低限ではあるものの定期的が大事です。基本的にマネージャーに得意分野があるように、メンバーにも得意分野があって、勝手に走らせた方が速いです。ただ、ちょっとだけ方向性を注意すればよいというイメージです。
先に出た、会社の方向性を少しだけ優先した方がよい理由は、結果が出た方が結局は個人の能力伸長に繋がり、前向きになり次に繋がるからです。あくまで確率の話しですが方向性を整えた方がいわゆる全社一丸になりやすく結果も出やすいですよね。少なくとも勝手に自分のやりたいように仕事して、制御する人もいなく、周りとのコミュニケーションも全くなく成果を継続的に出している人を見たことはありません。
まとめると、
が少なくとも私たちの会社規模のマネジメントの大事な仕事かなと。
ではでは。
以下のブログに触発されて、取締役版です。
AWSの資格である Solution Architect Professional は極端に難しい資格ではありませんが、簡単でもないようです。取締役の方々でも取得すれば自信に繋がると思います。
ちなみに私は技術は好きですが営業一筋16年です。ただし決して営業が好きなわけではありません。
以上です。取締役とはいえちゃんと勉強することをお勧めします。
3日間のAWS Summitが終わりました。事例の話しや技術的な内容など含め魅力的なコンテンツが多く、出展していた私たちとしてはお祭り気分でした。
その中で、先行販売していた「Amazon Web Services 企業導入ガイドブック」を早速読みましたので、感想を書いてみたいと思います。
Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
その名のとおりAWSを企業システムに導入する際における分析手法からオンプレとの考え方の違い、よく聞く挫折ポイントからの対処方法などが広く書かれています。企業システムのAWS導入に関わる方であればユーザー企業であれSIerであれ全ての方に一読をお勧めできる内容です。
先に書いたとおり企業システムのAWS導入に関わる全ての人になりますが、特に中規模〜大規模のシステムにおける導入に携わる方々の方が合ってます。サーバー台数で言うなら30台以上が目安になると思います。
著者陣が著者陣なこともあり特にAWSの概念がよく理解できます。概念が理解できると導入のアプローチが変わってきますので、よりAWSにフィットした導入が検討できます。私もまだまだ見かけますが、企業システムのAWS導入を検討されている中で、ただのハードウェアリプレース先のいち候補としてのみ位置付けられていることがあります。半分間違ってはいませんが、そもそもハードウェアではありませんので半分は間違っています。その理由が丁寧に説明されていて、それを理解した上での導入プロセス例が記載されているので導入までのイメージが明確になってくると思います。
AWSの各サービスの説明や技術的な部分については軽く触れるに留まっています。そもそもフォーカスが違いますので、他で補完すればよいです。
以上です。画面キャプチャやソースコードは殆どない中で、このボリュームは大変だっただろうなと。それと少しコンサル領域にも関わる内容も含まれているので、一貫性を持たせつつ自然な流れにすることも難しかっただろうなと。著者陣の方々お疲れ様でした、非常によい本です。私たちの今後の提案にも活かしていきたいと思いまっす。
