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

kusuke-jpのアメブロ

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

自分の周りを見渡すとすごいエンジニアの人がいます。結構。知名度がものすごくあるひとや、表には出てこないけどすごいエンジニアからあの人はすごいって言われてるような人。CAとしてもそんな人に来て欲しいと思ってたりして人事の人と話するとそんな話題もでるんだけど、彼らに来てもらえる可能性がある施策のヒントを教えてもらったので、はてなじゃなくここに書いてみます。多分これでハイエンドなエンジニアの心を鷲掴みにできると思うので他のIT企業の人事部各位はあんまり真似しないでほしいです。


先日、某勉強会でMさんに教えていただいた。技術秘書(Technical Secretary)というやつです。何人かのすごい人に聞いてみたけど、「それはいいね」といってもらえた。今日も言ってもらって確信しました。

テクニカルセクレタリーとは、学術方面ではすでに日本でもあるんですが、教授の実務サポートが出来るくらい専門分野の知識を有した秘書のことです。例えば学術分野では専門用語満載の学術資料の翻訳とか、それらを使った資料作成などがあります。それのWEB/アプリエンジニア版です。

ハイエンドなエンジニア/クリエータは、自分が最も評価されるスキルをぶん回して貢献したいと考えています。しかし、プロジェクトを進行する上ではどうしてもひとりの「担当者」になるわけですから、自分がやったことの報告書の作成や引き継ぎ資料、モック作成やテストデータの整理など、「付随する業務」というのが多種多様に発生します。これらを遂行する能力は、ハイエンドエンジニアといっても他人の10倍の生産性を発揮するのは難しいのです。

とはいえ、そのような付帯業務をちゃんとやらないと、プロマネ側から「技術はすごいんだけど扱いにくい人だなー」というネガティブ評価になるし、あまりそのような雑多な業務をPMから依頼しすぎると「何でもかんでも丸投げしてきて、グダグダな進行だなー」というエンジニアの不満になり、良い関係が生まれません。

それをサポートするのが技術秘書です。上記だけを見ると雑務を引き受ける下っ端の役割にも見えますが、求められるスキルは高く、用語が理解できる程度ではダメで、該当プロダクトのソースコードを読んで書類に起こしたりテストパターンを洗い出せる程度の知識は必要です。かつハイエンドなエンジニアのそばでそのワークフローを体験することで、技術秘書自身のエンジニアスキルもメキメキアップするのです。(マネジメント能力も)

とくに、当社は某所に採用しすぎちゃったテヘペロなどと揶揄されるほど急速に拡大してなお、ハイエンドな人材を求めているので、ハイエンドな人材には自身が生産性を一般的なエンジニアの数倍発揮できる部分に集中してもらい(=会社としてもコスパがいい)一般エンジニアはその神がかった仕事力を間近で叩き込まれることにより一気にショートカットして成長できる、という一石二鳥なのです。

以上、ジギョつくに出そうと思ったけど出すほどじゃない案でした。

7月付けで、正式にマネージャになりました。エンジニア入社でしたが、気がつけば拠点の運営をマネジメントさせていただいております。まだまだ小さい組織ですが、大きな存在感を発揮していきたいと思います。

以下雑多な振り返り。自分用です。

・プロデューサーになりそこねた。

2月に男道あした会議にでて、ひとつのプロジェクトを任せてもらったにもかかわらず、グダグダなスタートになってしまった。言い訳したい要因はないわけじゃないけど、この会社のプロデューサはそういう要因も乗り越えて良いプロダクトを出さないといけないので、7月の僕は失格だったと思う。

大きく反省点は2つあって、1つめはいくつか分業体制がしかれている中で、分業だからといって丸投げで思考停止していた部分が多々あったなと。

あとは工程管理・リソース管理を正常化することばかりに重きをおいてしまったような気もしてきた。PMとしてはいいかもしれないけどプロデューサ視点が抜けていたと思う。

遅くはないと思うので明日から取り返しにかかるぞ。


・非言語コミュニケーションが不足してきた

 なんだかんだで7月のリーダ会議を旅行ですっぽかしたので、会社の動きが見えづらくなってきた気になってきている。実際のところどうかは別としてそういう気持ちになることは良くないサインなのでちゃんと上司とコミュニケーションを取りに行く。

 非言語な情報は結構大事だ。それは「あの人今日体調悪そう」とか「あの人とあの人よく一緒にいるな、仲いいんだ」とか「あそこのチーム盛り上がってる」とか「今日は社長室にあの人達が招集されてる」とかだ。わざわざそんなこと文字に起こすまでもない情報だ。

いわゆる日本社会における「空気を読む」ための必須要素かつ言語化された情報の数十倍はあるにもかかわらず、それを限られたメールの文面から読み取るのは難しい。忙しいひとになるとソーシャルメディアでつぶやくのもせいぜい1日1~数回だ。(ツイッター廃人みたいに「おはー」「おはありー」「いてきまー」「あっ」「鍵忘れた」「ないないないない」「あー戻るの面倒だ」みたいに1分に一度呟いてくれればまだ読み取れるんだけどそんなことしてたら会社潰れるし)

あと、マネージャになったら会議漬けで仕事できない印象だったけど、思ったより会議がない。いいことなんだけど少し不安もある。


・裁量が増えて良くも悪くも自分が決めたいように決められちゃう

 マネージャになるということは裁量が増えることだ。決して給料が増えることと等価ではない。給料は市場価値に対して払われるものだと思ってる。
 裁量が増えると、ぶっちゃけ「あなたがやるんだから、あなたがうまくやれるように決めていいよ」という場面によく出くわす。言われなくても状況を客観的にみつめるとそうであることが多い。

 決めるのはめんどくさい。実は大小のビジネスの運用スキームを決める作業というのは、開発工程における要件定義から外部設計くらいまでの重要な工程なのに、手を動かさないことなのであんまり時間をかけにくいふいんき(←)がある。


・新しい技術とか、自分の職種を少し変えるぐらいドンドンできるようにしたい。

 今月は新しい試みをスタートさせた。ネイティブのフロントエンジニアと、コーディング経験のないデザイナーに、HTMLのコーディングをバトル形式で取り組んでもらった。まずはPC向け。勉強期間は2週間しかなかったけど、皆驚きの速度で吸収してくれた。

この業界毎日のように新しい技術が出てくるので、「つぶしの効く」「学習コストが低い=現在のスキルに近い分野」という点でまずHTMLが最適だと思いやってみた。このあとHTML5/CSS3とJSまでやってみようと思う。

サーバ側のアプリエンジニアは、インフラ寄り、たとえばチューニンガソンのようなアプリに一切手を触れずミドルウエア以下をいじってなんとか高速化するとかを通して、スキルアップしてもらおうかと思うんだけど、ちょっと人数がまだ少ないので保留。


来月もよろしくお願い致します。日が変わる前にかけた。
 お休みを頂いておりましたが、社内で嬉しい話題が。社長ブログ長瀬さんブログで会議のメンテナンスが全社スタートしてました。

だんだんとCAの社風にも慣れてきて、この手の「掛け声」や「キャンペーン」は結構頻繁に提起され、それこそ良いアイデアなら新人のものでも採用されるんだけど、やってみて定着に至らない・効果の出ないものは忘れ去られるというさながら市場環境のような様相を呈していることを実感しました。

なので、これは根付いて欲しいので自分も後押ししたいです。入社した時、「なんて会議の多い会社だ」「これがだいきぎょうってやつかぁぁああ!!!」と思ってたんですが、そうでもないっぽくて安心しました。「10分遅れたら○○万円人件費のロス」とか「アジェンダのない会議は禁止」とか、前の会社でも流行らそうとしてたので。


会議をメンテするための、失敗しやすい点の対策を書いてみたいと思います。


1.会議を減らすのではなく手段を最適化するだけということを理解する。


 目の敵にされがちな会議ですが、それでも大の大人が集まってワイワイ話す以上、何らかの効果はあるものです。たとえば、異動や入社の多い組織での顔合わせを兼ねたり、連絡事項を共有したり、もちろん、何かを決議したり。


 会議を減らしたら、その分タダで時間が手に入ると思わないようにしましょう。あくまで「それをするのに最適なのは会議することか?」という自問の上でメンテナンスするので、「会議はやめる、かわりに○○でやろう」みたいな手段の最適化を行うのが正解です。〇〇には懇親会だったり、MLとかWikiとかSkypeとかが入ります。

 ここを理解していないと、会議を減らしたけど、なんか情報が通らない、コミュニケーションが上手く取れてないなどの不満を抱え、何らかの会議が新設されて結局元に戻ってしまうのです。


2.みんなの時間を削減するために誰かの時間を多く使って準備する

 目的としては 会議で得られる結果/参加者のコスト を最適化することなので、たとえばアジェンダを作成・議事録を作成するという行為は特定の誰かの時間を大幅に使います。なのでAさんが会議の準備に40分かける代わりに、他参加者5人の時間が20分削減されることで、差し引き60分の節約になるという感じです。

 その場合、アジェンダは主催者、議事録は若手になることが多いと思います。議事録を取る人は、実はその書き方一つで会議の印象を操作できてしまう大役なので、出世したい人は積極的に議事録書くといいですよ。僕はズボラなので議事録係からひたすら逃げまわってましたが。


3.事前にやってほしいことを自分や他人のTODOに突っ込む

 ・自分:○○会議のアジェンダ作成(30分)
 ・自分:○○会議の議事録作成(30分)
 ・参加者:○○会議用の資料に目を通しておいてください(10分)

とか。忙しい人は無理矢理にでも時間確保して「情報が共有された上でいきなり議論開始できる」状態に近づける。会議中に全員の前で資料を読み上げるとかは、モチベーション系など肉声&身振り手振りじゃないと伝わらないものを除き行わない。


4.会議とはToDoを決める場だけど、他に手段がなければ会議でもいい。

 「アジェンダ書いて」と言われるとなれない人は戸惑うので、上記の点を取っ掛かりにすればいいと思います。「なんの会議か」というのは大体決まってることが多いので「会議が終わったらどうなってるか」を最後に書いておけば、その間が正しく進んでるかどうかがはっきりすると思います。

 会議が終わったら「○○さんが今週中にXXする」みたいな、日付&Todoが議事録に残っていれば、とりあえずOKでしょう。「今は諸々の都合で動けないので来週も会議実施」でも、関係者に打診したりたたき台を持ってくるとか何かできるはずです。

 とはいっても「定例○○報告会議」とか、情報共有のための会議って微妙ですよね。そんなに重要でもないし、参加者全員に聞かせたいかというとそうでもないんだけど、他に良い手段がない場合も組織によってあります。理想論ばかり言ってても仕方ないのです。

・MLに投げてもちゃんと読んでもらえないかも、、
・忙しい人の予定を押さえるには会議しかない、、

そんなときは気負わず会議しちゃいましょう。「ああ、この会議グダグダだな」と感じる人が多ければいずれ改善されますし、続けることが大切です。僕だって大阪にいるので渋谷の人たちと定例ミーティングして近況聞きたいし。



あと会議はペーパレスにして欲しいのと、MLは極力やめてWikiなどあとからjoinした人が困らない情報共有体制を普及させたいな。

こないだ出張時に曽山さんブログを読んで29円+送料で買った「ほめる技術、しかる作法」を読んだ。とくにしかる作法の章が刺さった。

僕はあまり人を育てる器がないので、どちらかと言えば仕事できない人は関わりたくないので去ってくれというタイプです。

そのあたりの心情も解説されていて、昨今の流動的な雇用環境や価値観の多様化で、いわゆる「会社は家族ではない」雰囲気で𠮟ることは難しくなったんだと。

思えば、短期的な関係にしか目が言っておらず、悪言い方をすれば「今役に立つ人かどうか」かという損得勘定だけで他者(社)と関わってきたのを「叱ってもらった」気分になった。

とはいえ、それでも人を育てるのは難しい。正確に言うと、業務をこなしながら人を育てるのは難しい。

だから、育つお手伝いならできるけど、育てるのは無理なので自分で結果出せない人はもう結構です。というスタンスになってしまった。だって楽だもの。

幸い、今の現場には皆ベテランが集まってるので基礎的なところで苦労することはなくなったけど、その分組織の掲げる目標がとても高いです。

その目標に進むために、リーダーがメンバーに出来ることはなんだろうと日々考えてまして、この本はとてもいろいろなことを気づかせていただきました。

ちなみに、この著者の「心理戦で絶対負けない本」というのも10年前くらいに読んでてとても面白かったのを思い出しました。


ほめる技術、しかる作法 (PHP新書)/PHP研究所
¥714
Amazon.co.jp

 今回も弾丸出張ということで、たくさんのアイデアや気づきを頂いたのでメモ。もう新大阪の新幹線の時刻ギリギリに行動するという無駄のない出張が出来る様になりました。

・小川さんのアナリスト勉強会

 個人的にぜひ講義を聞いてみたかった小川さんのお話を、職権を乱用して(?)会社にてセミナーを行っていただきました。マーケやアナリスト、プロデューサなどに参加してもらったのですが、自分が聞きたかった勉強会で社内の参加者にも喜んでもらえるという2度美味しい会となりました。小川さんありがとうございました。

小川さんのブログ、初心者はこちらのエントリがオススメです
http://d.hatena.ne.jp/ryuka01/20111021
http://d.hatena.ne.jp/ryuka01/20120426

小手先のテクニックではなく、事業成果を上げるためにどのような計測を行うべきかというブレークダウンの考え方が特に刺さりました。あと、書いてる最中という新刊がめっちゃ楽しみです。


・曽山さんとお話

 どこからか出張の話がながれ、空き時間にお話をする機会を頂きました。自分は技術職ではなく管理職を選択したので、ぶっちゃけいま感じている課題をぶつけてみたところ、明確なアイデアを頂くことができました。帰りの新幹線で早速マインドマップとか書いちゃったりしました。
行きの新幹線で、たまたま曽山さんのブログを見て関連記事の紹介されてる本をAmazonで即購入した矢先の出来事だったので、中古価格29円+送料250円の自己投資のご利益が早速あったようです( ̄ー ̄)明日届くのでまだ読んでいませんがw



・技術職のお話

 技術のサイバーエージェントにする、と言うことを社長がおっしゃっていたのですが、説明会を聞いてとても納得しました。たんに、エンジニアにデカイモニターを与えて、よく言えば自由というだけで居心地の良さを提供するだけの状態から、エンジニア自身が会社を動かしていくための施策などシステマチックに根本から変えていくという内容。
そしてそれに社長自らがコミットしていくという姿勢が改めてすごい会社だなと思いました。正直そういうのって、執行役員とかに任せて指示だけすればいいのに、社長自身が先頭に立つという点で、会社の本気を感じることが出来ました。

社長ブログ:http://ameblo.jp/shibuya/entry-11282704343.html



・広報、CS、プロモの方とのMtg

 前職と違い大きな組織では役割に応じて専門の部署があるのですが、そういった専門家の人達とリリース予定のサービスについてご相談させていただくのはなかなか興味深い経験でした。ちなみにお三方とものMtgに遅刻しました。申し訳ございません。


寝たら忘れる性分なので寝る前にメモメモ。