モビコム - ほっ!へ~や! - -4ページ目

モビコム - ほっ!へ~や! -

気が向いた時に書いてます。

第2回目の朝ゼミがありました。

今回は人事の曽山さんも参加して下さいました!


さて、今回は、

・前回の朝ゼミで決まったことを実践してみてどうだったか?
・前回共有できなかったチームの課題の共有

を行いました。




まずは前回決まったことを実践してみて、の共有。

僕的には確実に改善に向けて前進している手応えを感じることができましたが、

他メンバーも確実に改善に向かっているようでした。

1回目にしてこの効果、すばらしいです!


  #ランチセッティングしてくださったAさん、ありがとうございました!


また、前回の改善点に上がった、

「ベース業務の見直し」

に関して、曽山さん、長瀬さんからのアドバイス。


「定例MTGを定期的に見直す」
「徹底的に捨てる。」(残ったものが本当に必要なMTG)


これも現場に戻って早速実践してみます。





次に、前回共有できなかった課題です。

僕は

「チーム内でのクリエイティブな議論が若干薄い」

という課題を共有させて頂きました。

補足すると、エンジニア・デザイナーのアウトプットに対して、

より洗練させるために必要不可欠な「斜めからの視点」に欠ける。


これに関して、曽山さん、長瀬さんから厳しい指摘を受けました。

「ユーザーにサービスを提供する前に、作り手が斜めからの視点で見直さないことは悪。
 それはある意味ユーザーへの裏切りである。」

エンジニア・デザイナーにとっては耳が痛い一言でした。



この課題に対する次の一手としては、

・斜めからの視点で見ることができるような仕組みを作る

ということです。個々の意識だけでなく、チームとしては戦略的に行うことが重要。

具体的には、

・斜め読みシートの導入
 →言いづらい事は紙に書くと案外出てくる

・チームに一人、開発から離れて完全ユーザー目線で見る人をつける

・責任と権限を明確に
 →トップとしつこいくらい握る

早速実践していきます。





また、他メンバーからは次のような課題が上がりました。

・育て方が分からない
 →最低限レクチャーが必要(どこをマネすべきか)
 →課題を提示してあげる

・サービスやプロジェクト間の連携がうまくいかない
 →大前提として、「何をもって成果とするか、何をもって成功するか」が握れていない可能性大
 →トップ同士が握れているか?
 →下にきっちり浸透しているか?


これらに関して振り返ってみると、僕のチームでもてこ入れの余地がまだまだありそうです。





第3回目にまたいい結果が報告できるよう、がんばっていきます!




いよいよ始まりました、朝ゼミ!


第1回目は、各自が抱える課題を出し合い、議論し、

改善のための具体的なアクションを導くといったことをやりました。



まずは皆からあがった問題を次のように「組織」と「個人」の課題に大別しました。


■組織
・チーム間でノウハウの共有ができていない
・他プロジェクト、他チームとうまく連携できていない
・リソース(人・資金)不足

■個人
・MTGに時間をとられすぎ



特に皆が共感したのが「MTGに時間を取られすぎている」という課題でした。

改善策を考えるに当たり、

「ベース業務(MTG/調整)をできる限り減らし、コア業務に注力する!」

という考え方を頭に入れ、出てきたアクションプランは次の通り。


1.MTGは目的に応じて正しく効率的にやろう
  -「共有」目的のMTGはできるだけ短時間で。この場で議論するのはNG!
   議論が生じた場合「持ち帰って話しましょう」と勇気をもって言おう。
  -「議論」目的のMTGは、必ず事前に何を議論するかを確認し、準備をして備えよう。

2.ベース業務を定期的に振り返り見直す癖をつけよう
  -ほとんど振り返りをしていないのが現状・・・
  -月1で振り返り、ベース業務・コア業務に自分がどれだけ時間を費やしたか可視化してみる。
  -振り返りやすくする工夫を。(日報の書き方とか)

 ちょっとした小技として「メーラーを起動しっぱなしにしない」という案もでましたw
 確かに、起動しとくと気になりすぎて気が散りますね。


早速取り入れていきます!


ノウハウ共有や連携に関しては次回も掘り下げる予定ですが、

ひとまずすぐできることとして、とにかくコミュニケーションすること。

さっそく、ピグチームの先輩エンジニアとのランチを設定していただきました^^

こんな感じで、チームの壁を越えてコミュニケーションが活発になるよう、

まずは僕らが率先して動いていこうと思います。




本当に収穫の多い第1回目となりました。

上記のほかにも個人的に目からウロコなことがたくさんありました。
(これはまた別記事で書こうと思います。)

裏返せば、非常に参考になるインプットは多かったけど、

アウトプットは少なかったなというのが今回の反省です。

局長に頼りっきりです。



そこで一つ思いついたのですが、

朝ゼミの分科会を作ったらどうだろう、と思いました。

メンバー主体で、ロジカルシンキングやコミュニケーション力などの基礎力のテコ入れから、

個人的には「イノベーションへの解」 をハラ落ちするまで読み解いて

戦略脳を鍛えることまでできたらいいな・・・なんて妄想してしまいました。







認知心理学と社会心理学からの洞察によると、

  同じ現象を「機会」として示したときよりも、

  「脅威」として示したほうがより激しく強力な反応が引き出せる。

だそうです。



イノベーションへの解 収益ある成長に向けて (Harvard business school press)/クレイトン・クリステンセン
¥2,100
Amazon.co.jp

そして、「イノベーションへの解」によれば、

破壊的イノベーションはそもそも

既存事業にとって全く魅力的でない市場を対象としている。


既存事業の実績ある企業にとっては「機会」と位置づけても、

上層部の関心を引くことはできない。

・・・

先見の明あるマネージャが「脅威」と捉えたとしても、

本能的に破壊的イノベーションを脅威として捉えるがゆえに、

既存の顧客や事業の防衛に注力することになる。

将来、破壊から既存顧客を守る必要が生じたときに、

新技術を用意してその場に臨もうとするのだ。

この結果、組織は成長機会を逃すだけでなく、

最終的には、自らの破滅を招くような戦略を追求するようになり

・・・


また、P.F.ドラッカーによれば、

「問題ではなくて、機会に焦点をあわせろ」

マネジメント - 基本と原則 [エッセンシャル版]/P・F. ドラッカー
¥2,100
Amazon.co.jp




http://japan.cnet.com/column/contents-innovation/story/0,3800096235,20393206,00.htm



「トップデザイナー⇒アパレル企業⇒雑誌⇒消費者」

という流れの中で(またはこれを破壊して)、

僕らのサービスがどんなバリューチェーンを構築し、

世の中にどんな価値を提供することができるだろうか。。。
ジレンマは世の常。

既存ユーザーの要望に答えれば新規ユーザーが離れ、
営業が一番嬉しいことはメディアに悪影響。

打開するためには最後は熱い信念を貫くことが必要。
でも、その先を予測することがとても大切。



予測するには「理論」が役に立つ。



たとえば人類の飛行の歴史。

人類は、飛行可能な動物と飛行との間に「翼がある」という相関関係を見つけた。

そして腕に翼をつけて崖から何度も飛び降りたが、飛べなかった。

結局人類を飛行可能近づけたのはベルヌーイが流体力学を元に揚力の存在を見つけた。
理論を導き出した。

それでも人類は確実に飛べるようにはならなかった。

うまく飛べない原因を調べに調べた。

そうして、誰も予想だにしなかった飛行が可能になっていった。




日々の仕事を振り返ると、

相関関係の発見で留まっている。

まだまだだな。


イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)/クレイトン・クリステンセン
¥2,100
Amazon.co.jp

イノベーションへの解 収益ある成長に向けて (Harvard business school press)/クレイトン・クリステンセン
¥2,100
Amazon.co.jp

この本から得られる理論は、

その大小・事柄・状況を問わず、ジレンマ克服を手助けする術だと思う。

知的欲求=本能をくすぐられる2冊。

ゴリマッチョになりたい!

と思っていくら筋トレしても、

もし今流行のインエンザにかかっていたらマッチョになるどころか余計体調が悪くなってしまいます。



同時に複数案件が進み、開発スピードも速い僕のチームでも

それと似たような状況が多々あります^^;





向かいの席のMさんも言っておられましたが、大切なのは、

新しい施策とシステム改善の両立、

 「攻めと守りのバランス」

だと思います。




Webサイトのパフォーマンス改善というと今まで、

・ボトルネックになりやすいDB回りの見直し(SQL・Indexのチューニングとアプリの修正)
・アクセス数に応じたミドルウェアのチューニング
・より低コストでスケーラブルなシステムを目指したアプリケーション改善
・サーバ追加
・サーバのメモリ追加

という感じに、割とコスト(時間も)がかかるものをやってきました。

そして、そういうもんだろう、と思っていました。

が、


ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール/Steve Souders
¥1,890
Amazon.co.jp




この本を読んでちょっと目からウロコでした。

  WebサーバからHTML文書を取得するのに要する時間は、

  エンドユーザーに対する応答時間のわずか10~20%に過ぎない。

  残りの80~90%は画像・スクリプト・スタイルシートのダウンロードや解析等に費やされる。

らしく、80~90%の処理時間を半分以下にする方法(応答時間全体でも50%ほどになる)が

14のルールにまとめられています。


どれもこれも、バックエンドのパフォーマンス改善に比べれば比較的低コストで実践できそうなものでした。


試す価値ありです!



フロントメンバーにも有益な一冊だと思います。





とにかく今期は改善MAX。



本業のシステム改善は当然。やるべきことが盛りだくさん。



組織的にも穴だらけ。

つっこみところがありすぎて全部書ききれない。

メンバーのアウトプットの質を上げつつ、スピードも上げるためにできることはたくさんある。

がんばろう。



前に役員のUさんがおっしゃっていた。

「組織は左に振ったら今度は右に振ってやるってことが必要」

ほんとそうだな、と実感している。






エンジニアリングについてあれこれ考えるのは大好きだけど、

チーム(会社)をよくしていくことについてあれこれ考えるのも好きなんだなぁと最近思う。





一人でやったら3年かかることを、チーム(会社)でやったら3ヶ月でできるかもしれない。

一人でやったら10人の人を感動させられるかもしれないが、

チーム(会社)でやれば東京ドームいっぱい10個分の人を感動させられるかもしれない。

こんな面白いモノにハマらずにはいられない。