kusuke-jpのアメブロ -9ページ目

kusuke-jpのアメブロ

技術的じゃないビジネス寄りの内容はこっちのブログに書いてます。内輪ネタ多し。

 昨日は某技術イベントのキックオフでした、昨年ご一緒させていただいたのですが、今年は運営委員をお手伝いさせていただくことにしました。

 その場で、いろいろな案を出し合っていたのですが、このイベントは「IT技術者」という広い枠でくくったイベントなので、当然ながら自分と違うタイプの人たちもたくさん来るわけです。

たとえば、エンタープライズ系のSIerさんが、セミナーを受講しに来るようなスタイルでいらっしゃる方もいれば、スタートアップ系で技術者仲間と交流したいと考えてくるような方もいらっしゃいます。

 なので、例えばWEB界隈で常識のように語られている「技術をどんどん公開しよう」みたいな考え方も、一方では電機メーカーなどではご法度だったりします(電機メーカーの早期退職制度で技術者が他国にノウハウごと流出する!と騒ぎになったこともありましたね。)

その日に聞いたので衝撃的だったのは、飲み会など他のメーカー社員と交流してはいけないという絶対的なルールがある会社も普通にあるそうです。

もうひとつ、なんで買ったか覚えてないのですが、こういう本を買ったので読み始めたんです。

「即戦力」に頼る会社は必ずダメになる (幻冬舎新書)/松本 順市
¥777
Amazon.co.jp


冒頭を読み始めて、派遣社員という制度が日本をダメにするとか、転職を繰り返す人はダメだとか、育成コストを放棄して中途社員を採用するのはダメだとか、あまりに自分の考えと違うことが書かれすぎていたので、5ページ目くらいで捨てようかと思ったのですが、思いとどまりました。

極端ですが、これから自分や自分の子供達が迎える社会は、いろいろな「垣根」がなくなっていく社会だと思ってます。
例えば、海外に進出すれば異なった文化、宗教観をもったチームと一緒に成果を上げる必要があります。
自分と考えや、事象に対する分析結果が違うからと言って、さっとシャッターを閉めてしまうのは早計ではないかと。


(※とはいえ普段心安らかに生きていく上で、面倒なものを無視するというのは大切な能力ですが。)

ここで、第一段階、「違う考えや経験を持った人のことを理解する」の第一歩が達成できそうです。著者は旧来の3Kの職場を既存社員を育てて東証2部上場まで成長したと書いています。同意はできませんが信頼に値します。業種や市場が異なれば、企業戦略も異なって当然だからです。

ビジネス書を読む理由は単純です。そこから知見を得たいからなので、自分と立場や考え方、主義主張がことなる人の本を読んでも、自分という軸がしっかりしていれば自分と正反対の方向に主張している人からもなにかエッセンスが抽出できるような気がしましたし、読み進めてみればもしかしたら自分と考えの近い主張も出てくるかもしれません。



では次に、じゃあこのように全く違う考えの人が自分のチームメンバーだったら。つまり「違う考えや経験を持った人に何かを伝える」。

「理解」できるようになれば、「私とあなたの考えは違う、でもあなたがそう考えることは良いと思う」というふうに考えの違いは横においておいて仕事をすることができます。ただ、それでも相手の考えや「目線」に合わせた伝え方ができるかどうかがすごく難しいな―と感じました。

意見が違う人と、議論を交わすことはできます。もしかしたら相手を論破できるかもしれません。でもチームの場で相手を論破してもあまり良いことはありません。

自分は割とドライなので、一定の合意が形成できるか、合意されなくてもチームとして決議されればことは進むので問題ないと考えてしまいがちです。参考:「話し合って決める」という幻想

それでもやっぱり割り切れないのが人間だし特に日本社会というハイコンテキストな場では、「相手が受け入れられるように伝わる」のは大切なスキルだと思うのです。むずかしいよねー

(ちなみに「受け入れる」というのは、同意してもらうという意味ではなく、先のシャッターを閉ざさないでくれるという意味です。言い換えれば相手の立場にたって伝えるというニュアンスでしょうか。)

ちなみにそういうの、妻はとても上手なので、見習っていこうと思いますが、なにか良い訓練方法があれば教えて下さい。
 社内にはキラキラ女子にかかわらず例えば特定の分野で「この人すげーなー」とおもう人たちがいます。うちのプロデューサとかも新人のくせにサービス改善のセンスがいいなと思ったり、特定の会議に参加するときに、進行のセンスがいいなと思ったり。肝となるボタンのラベリングでしっくり来る言葉をチョイスしてきたり。。

じっくり考えぬいて出す理論に裏打ちされた答えって感じはしないんだけど、息を吸う様に普通にやってることのレベルが高い状態っていうのを「○○センスが高い」と僕は呼んでるんですが(笑いのセンスが高いとか)

どこかで又聞きした言葉、「センスのよさは過去の経験からくるパターンマッチング」というのをふと思い出しその意味を振り返ってみましたが、たしかにそうだなぁと思いました。

日々のブレストや会話の中で「おっ、いい視点」と思える発言がぱっと出る人って、やっぱり過去にもそういう経験を繰り返ししていて、その時に自分で考えだしたスキームや他人が言った発言などがインプットされている。

体に染み付いてるっていう表現が適していて、なんでそんな考えができるかを人に教えたりはできない。なぜなら無意識のうちに脳内で過去の似たような状態とパターンマッチングを行なっているから。

何が言いたいかって言うと、日々わからないながらも分析しながらアウトプットし続けていると打率が上がってくるからマジおすすめってことです。
(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)

(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)(y)

※タイトルは釣りです。
最近自分の中でもしっくり来ていない部分があって、人それぞれの価値観として合う合わないはあるにせよ何処かにかきとめて置きたいなと思ったので書いてみます。

CAは会社カルチャーとして挑戦を超絶推奨する文化があって、しかも失敗してもいいよっていう安心とセットにしているのが特徴です。自分も入社してから目一杯失敗させてもらって、経験値を蓄えさせて頂きました。

周りを見ても、チャレンジしているひとはそのような感想を持てているんじゃないでしょうかね。

■目標を履き違えること

ただ、誤解を恐れず書くと。時々それを履き違えて、チャレンジし経験すること自体を目的にしていないかなーと思うのです。「起業したいです」っていう人が起業をゴールと履き違えているように。そうじゃなくて、成果とか、達成したい事項があって、それを成し遂げるためにチャレンジが必要なんじゃないかなと思ってるんです。○○にチャレンジして成長して行きたいですみたいな言葉が仕事の会話で出てきたら、成長よりも成果を意識するように修正していってます。

達成したい成果(Goal)があって

それを達成するための
・技術的なチャレンジ
・職責的なチャレンジ
・何かを切り捨てるチャレンジ
・何かを新しく始めるチャレンジ

なのであってそれぞれを最終目標にするとダメな気がするのです。

■副産物を独り占めしないこと

例えばチャレンジした結果成果を成し遂げられなかった、思ったほどうまく行かなかった時に「でも成長出来ました」っていうのは自己弁護でしか無いと思うんですよね。自分が頑張ったことを正当化するのは人間誰しも行うのでいいのですが、ぼくはもっと組織はシステマチックであるべきという考え方なのです。

どういうことかというと

[ぼく|わたし|だれか|あなた]の失敗が、組織に還元されていますか?

という点です。僕がチャレンジさせてもらって僕が成長した、それだけだと会社のコストにタダ乗りしてるだけだと思うのです。

このへんが誤解を生みやすいのですが、「だからチャレンジするときには覚悟を持て」っていう一種の強迫につながるとそれはそれでマイナスで、そうじゃないと。

たくさんチャレンジして、たくさん失敗した貴重な経験を独り占めするのは組織全体にとってコストパフォーマンスが悪いってことなのです。

なので、挑戦と安心と共有もセットにしていきたいです。生きたケーススタディってすごく役に立つので。

後半はなんか偉そうになっちゃったけど、一旦ひとりごとということでご容赦を。



はてなの方はエントリの振り返りだったので、こちらはビジネス面での今年の抱負を。と思っていたのですが、昨日飛び込んできたちきりんの中の人のエントリを読んで即買い、一気にiPad miniのKindleで読んじゃいました。



勝ち続ける意志力 (小学館101新書)/小学館
¥777
Amazon.co.jp
勝ち続ける意志力 世界一プロ・ゲーマーの「仕事術」 (小学館101新書)/小学館(Kindle版)
¥525
Amazon.co.jp


いろいろな面で刺激を受けたのですが、ちきりん女史がおすすめするように、「勝つこと」と「勝ち続けること」の違い、そのために何をやるべきかという事がひたすら書いてあります。

自分が「勝ち続けられないひと」の習慣も当てはまるし「勝ち続けるひと」になるための行動も一部できていたので、興奮して読み進めることが出来ました。

端的にこの本の主張を抜き出すと、「勝つこと」は誰でも1度くらいできる、しかし「勝ち続ける」ためには、例えば自分の勝ちパターンを捨てて、不得意分野でも練習と研究を人一倍こなすことによって負けないようにする。相手の弱点をつかなくても勝てるようにする、といった事が書かれていました。

これは一個人としても大変興味深い内容ですが、組織に当てはめても同じことが言えます。自分たちの組織なら、どんな仕事を任せられても徹底した研究と努力で成果を出せる、出し続けることが出来るといった戦い方を、2013年の自分のビジネス上の目標にしようと思いました。


現状、チームエンジニアの中には、自分が転職時に一定評価された技術からはなれ、新しい技術を頑張っているメンバーもたくさんいます。(Objective-C→Javascriptとか)
当然経験も0リセットに近いですし、勝手が違うので「得意な戦場」ではないことは確かです。しかし、彼らはそのフィールドで成果を出そうと努力しています。

エンジニアの価値観は様々で、個人的には新しい技術に挑戦することは技術者として当然だと思ってはいるものの、新しい技術で期間内に成果を出せと言われるとなかなか勇気がいるものです。


逆に言うとこの本の筆者が「新しい年になると、新作ゲームが発売され、今までの経験の多くがリセットされる。それは経験が少ない人が努力で経験の多いひとを超えられるチャンスだ」といったことを書いているのですが、めまぐるしく技術トレンド、ビジネストレンドが移り変わるこの業界にもまさに当てはまることだと思います。

今年はアスリートのごとく徹底的に分析、鍛錬し、筋肉質な組織にしていきたいと思っております。

そんじゃーねw

--
おまけ:曽山さんの本の帯に書いてある社長コメント「仮にサイバーエージェントがまったく違う事業をすることになったとして、たとえそれがうどん屋であっても何であっても、我々の組織を持ってすればきっと成功すると思う。」というメッセージにも近いものがあるように思います。

サイバーエージェント流 成長するしかけ/日本実業出版社
¥1,470
Amazon.co.jp
 今月は、大阪で進行中の4つのプロジェクトのウチ、システム的に悲惨なプロジェクトの「デトックス」をひたすら頑張りました。

そもそも、9月に大阪組織統合で立ち上がったものの、10月末くらいまでは各自それまでのプロジェクトを引っ張っており、11月が本格的に新組織が動き出しました。

たくさんの課題と向き合っています。経験不足、リソース不足、がむしゃら感不足(メンバーがおっさん中心なんでw)とかとか、いろいろ足りないものがたくさんあって、色々と奔走してたので、ちょっと書きだしてみようと思いました。

バシッと3月度に数字決めてさっさと後任を育てたいので、「足りない」を克服するためのメモです。以下相変わらず長文なので色がついている文字だけであとは読み飛ばしていただければと。

大阪組織全体に対してやってみたこと


■まず初めにメンバーとの対話

何はともあれ全員のスキルや苦手分野、いまのプロジェクトの状況を聞いて回りました。嫌気がするほど問題点が上がってきたのですが、まだ情報を教えてもらえるうちは期待が多少残ってると思い、組織づくりで人員配置を動かしたりもしてみました。


■目標の共有とマインドセット

9-10月は各人ごとのキャリアパスを考えたりしながら目標を設定していましたが、10月頃から所属部門の技術人事制度が整ってきたり、新年度の計画も出てきたのでそれにあわせて、目の前の現実と高い目標を伝えたりしました。N瀬さんにも来てもらいました。


■人材計画


わりかし人材計画は部門の計画もあるので、2,3ヶ月ごとに大幅に変わったりするのですが、もともとプロデューサ→外注さんというシステム側が把握できていない状況から、9-10月で手分けして各プロジェクト内容の把握を進めたので、4週間後の人員計画を見据えたパートナーさんの採用など、ある程度ギリギリ間に合うくらいのアサインが出来るようになりました。

直接人材計画とは関係ありませんが、各種勉強会を実施して、関西のエンジニアの方に認知度をあげようというブランディングの試みも行なっています。まだ積極採用をしていないので、某イベントのように採用色のあるイベントにせず、純粋に場を提供し楽しんでもらっています。


■上役、サポート部門とのシンクロ

組織として仕事をする以上「現在自分たちの立ち位置の確認」「向かうべき場所の確認」がなければ闇雲に頑張っても意味はありません。また大きい組織と地理的なコミュニケーション密度の違いもあるので、「どう見られているか」も東京にいる時よりはやや意識したほうが良いと感じています。

これをフィットさせるには、やはりライン上の上役の人たちとのコミュニケーション回数を増やすというのは重要だと思いました。特に「公式なやりとり」以外の、漏れ聞こえてくる言葉からその人の考えが理解できたりするので、会議だけじゃなく飲み会や席替え、雑談が大事です。

エンジニアとしての横串組織も、非常にしっかりしたものが構築されつつあるので、そこに乗っからせていただいて超助かっています。(まだまだこちらが立て直せてなくお見苦しい点も多いですが)

11月にサポート入りしたプロジェクトでやったこと


■アーキテクチャの改修


もともと、いろんな条件が重なって「取り急ぎで」作ってもらった経緯のシステムなので、インフラからフロントエンドに至るため、設計上の問題が山積みでした。同時期に自社基準を策定しているという話をCTOからもらっていたのですが、そんなレベルではなく、一刻もはやく目を背けたくなる状態でした。

また、内製化巻取りも短期間で集めた委託の方に丸投げしていたので、チームとしてもやや崩壊していました。委託のリーダーのK氏と何度も対話し、ときにぶつかりながらも理解を得て、K氏がウェブアプリのアーキテクチャを、フロントデベロッパーさんと僕がフロント周りをひたすら書き換えて行く事で何とか褒められはしないものの目を向けれるようになって来ました。


■インフラの支援

ただ手が足りていないインフラは放置気味でした。横串Mtgがあると教えてもらったので出たところ、案の定呆れられてしまいました。。ただその結果、人材の融通も調整していただいて、なんとかブラックボックス部分を洗い出したり、各種チェックをしてもらい「コントロール可能な」状態に近づきました。


■トラブルも逃げずに対話


委託メンバーの方が、あまりにドツボにはまってるところこちらが進行上上手くサポートできなかったことがあって、たまたま出張中だったのですがチーム内で揉めたことがありました。該当の方を叱責して代わりの担当を探すというドライな対応を昔の僕ならとっていたのですがww

一緒に働く仲間なので、色々お話をして、こちらから出来る支援や、支援するためにこういう考え方で仕事に望んでほしい。などしっかり話し合ったら翌日から目に見えてパフォーマンスが上がり、自分自身驚きました。


■圧倒的なリソース不足と順序の決定

全方位でいろんなものが足りてないプロジェクトなので、KGIに向けて重要な順に対応し、残りは社内基準で何とかお許しをもらえるレベルにしようと考えたりしました。保守性、堅牢性、速度、サービスの使い勝手(今回は内製化だけど)安全性など様々な評価指標で、ビジネス上のバランスが一番取れるところまであと数営業日で作り上げるベストな優先順をつける事を考えたりしました。

リリース日まで、リリース後2週間以内、1ヶ月以内、春まで、などと対応日を口頭でサクサク決めてたたき台を作り、各部門の担当者にあててすり合わせるという作業をここ2週くらいしてました。

以上です。


個人的な雑感

わりとCAに入社するまでの数年間、悪く言えば「誰も挑戦したこと無い分野なら、クオリティの低い仕事しても需要が強いから認めてもらえる」あたりを狙った仕事をしていたので、自分の仕事に対する「まぁこんなもんでいいか」のラインが結構低いなということに最近気付かされています。

ところが、なかなかこの年になると叱ってくれるひともどんどん減るので、お前こんなんじゃだめだよ、糞だよって言ってくれる仕組みが社内でいろいろあって楽しいです。CAクオリティを達成するためのスピード感というか、プロ意識みたいな空気が大阪でも芽生え始めているので、この感じを育てていければと。


次はコミュニティプロジェクトのスピードアップに全力投球です。