情報システム担当者って最近よく話題にあがってますよね。ロードバランスすだちくんは有名ですし、AWSのユーザー会でもJAWS-UG情シス支部が立ち上がっています。ちなみに私はロードバランサーが好きです。
ところでサーバーワークスには情報システム担当者が2名います。今日はこの2人は結構すごいなと思っていたので紹介してみます。
続きを読むHDEさんのペタバイト祭りに参加しました。
先週になりますが、HDEさんのペタバイト祭りに参加しました。HDEさん、AWS上でのディスク容量が1PBを超えたとのこと、すごいですね。
乾杯の挨拶はAWSJの都村さんから。都村さんすべってました、流石です。なかなか1PB超えのユーザーはいないようで感動されていました。
そのあとパネルディスカッション。HDE小椋さんのディスク容量増加に伴う技術的な苦悩の話しや、ソラコム玉川さんのソラコム事業におけるスピード重視の話しなど勉強になりました。
お土産いただきました、洒落たマグカップです。ありがたくうちの社内に寄贈させてもらいました。
以前に小椋さんから社内英語公用語化計画？を聞いていたのですが、周りを見回してHDE社員の方々の会話は日本語と英語が入り混じっている感じでした。実行して実現に近づいているって素晴らしいですね、うちも見習っていきたいと思います。
ではでは。
中間管理職だって楽しく働きやすく
先日こういうツイートを見かけました。
課長職面倒くさい。
— okeee (@okeee0315) 2015, 11月 6
@okeee0315 わかる
— あだ名がリーダー (@iara) 2015, 11月 6
中間管理職はメンバーを鼓舞したりなだめたりフォローしたり、案件のアサイン調整したりチームで持っている案件を広く管理したりする一方で、数字の報告をあげたり今後の対策を練ったり変な要望言われたりの対応もあって、これを楽しめればいいのですがそうもいかないこともあるかと思います。仕事なんだからしょうがないじゃないかというのは思考が止まっているので好きではありません。
そもそも管理職って管理という聞こえはあれですが、個人での成果よりもチームでの成果を追いたい人により適した職業です。理想でいうと個人技は一流でパスの楽しみを覚えチームで成果を出そうとしている仙道がイメージしやすいと思います。
中間管理職のない会社もあるそうですが一旦それは置いといて、中間管理職だって楽しくあるべきです。アイデアを考えてみました。
権限を増やす
チームとして成果を出すためには、メンバー個人個人の特性を見極めて各々最適な仕事のアサインや働く環境を整え、時には変化させる必要があります。それには会社のルールをできるだけ緩め、管理者の裁量を大きくし、メンバーごとに最適化しつつ全体で最大の成果を出そうと工夫し続ける。どうですかね、少しは楽しくなりそうですかね。確かに仙道はコートにおける監督に近い立場であり相当な権限が委譲されています。
報告を減らす
昨今のBIツールの進化もあり、特に数字の報告は減らせるでしょう。あとそもそも報告とは上長が現場を知らないがために発生するので、上長が知りにいけばいいじゃんと。仙道は田岡監督への報告は必要最小限に見えます。また田岡監督は報告を出させるというよりは自分で分析しようとしています。
調整作業を自動化する
仕事の状況は日々変化しているためアサインメンバーの状況把握やフォロー、追加で入った仕事の調整などは人がやる仕事であるかぎり完全自動化は無理で、これを根回ししつつうまく行うことも管理者として必要な能力でしょう。ただこの仕事は結構大変なのでもっと効率化するとより楽しくなるかも。各々のメンバーに様々なセンサーを付けて心拍数とタイピング数と加速度と脳波とかからメンバーの状況を見える化することができるようになると面白そうですね。ただ仙道が調整作業をしているとは思えません。田岡監督やマネージャーがやっているような気がします。そうするとそもそも管理者がやるのではなく調整作業の専任を置くといいのかもしれません。
部下に上長を置いてみる
上長とか社長とか、部下として置いてみることによって、まず上長からの無茶振りなどはそのまま上長にやってもらえばよくなるでしょう。少し楽しくなりそうです。ただし仙道は田岡監督が部下でいることは嫌でしょう、ちょっとこれは無理があるかもしれません。
以上、今思いつくがまま書いてみました。他にもいいアイデアあったら教えてください。
仕組み化と徹底は合わせ技
こんばんは、羽柴です。
サーバーワークスでは業務の改善が頻繁に行われていたり、行いたい状態だったり、いろいろあります。クラウドに特化していろいろチャレンジしている会社の宿命ですし、楽しいところの一つです。
で、当然改善したい側にはそれ相応の目的があり、それは実現すれば素晴らしい効果が出そうなものです。その実現方法も多種多様に存在します。
実現方法を検討していき候補を絞っていくとこんな感じの内容が残ってきます。微妙に感覚が違うのです。
- 業務フローとして少し難しそうだが徹底次第。
- 業務フローとしてこれならみんなできそう。
私個人の経験としては、 1. はうまくいきません。ちょっとした議論や数日の検討によって多少懸念がある場合、実運用に入るともっとたくさん弊害が出てきて、業務フローとして破綻します。これは色々な要因があります、作業内容が想定以上に高負荷であることや、自然に流れないフローになっていたりします。そうすると新しく入ったメンバーがそのフローを理解できず間違えてしまうということもあるでしょう。結局管理者が徹底しようとしても徹底できないほどの問題点があるので破綻します。
2. はうまくいくと思いきや、これも業務フローを定義しただけではうまくいきません。新しいフローは設計者にとってそれがどんなに簡単でも、浸透させていくには日頃の管理・教育・啓蒙という徹底活動が大事になってきます。
よくあるのが、フローをwikiに書いたのでそれを見ればいいじゃんという話し。wikiに残してくれることはとても素晴らしいことなのですが、それだけでは大概みんな（少なくとも私は）見ないのでなかなか浸透しません。
仕組み化と効率化を念頭に業務フローを改善し、頻繁に目的を伝え、そのフローに沿っているか細かく管理をし、何回も何回も伝えることが必要であり、みんなできそうなフローに対して徹底を行うことで新しい業務フローは浸透するんだと思います。
でもめんどくさがらず楽しみながらじゃんじゃん改善していきましょうね、サーバーワークスのみなさん。
