おうさまのみみはロバのみみ

ネット上での木の洞

仕事を増やすマネージャー

良いチーム、悪いチーム。 優秀なマネージャー、そうでないマネージャー。 軍隊の指揮官みたいにバリバリみんなを率いて先頭に立つリーダー、みんなとで協力して効率をよくするリーダー。

世の中にはさまざまなリーダーやマネージャー、そしてチームがある。 決して長いとはいえない自身の経験を省みても、人それぞれなやり方やそのときの流行りのスタイルで指揮したり、チームビルディングしたりしていた。

その中で「あ、このチーム(あるいはマネージャーやリーダー)は駄目だな」と感じることがある。 それらにはある程度共通項があってつい先日ふと思いついたことがある。

つまり彼、彼女らは仕事を増やすのが得意なのだ、と。 そして逆に優秀だと感じるチームやマネージャー、リーダーは仕事を減らすのが非常にうまいということだ。

仕事が増える、とだけ書くとそれほど悪いことではないように思える。 少なくとも会社としては暇を持て余しているよりはあくせく働いているほうが一般的に良いことだとされている。

それ自体を否定する気はないのだが仕事にも「増えてよい仕事」「増やしてはいけない仕事」があるとぼくは思っている。 彼らが増やしているのは「増やしてはいけない仕事」だということだ。

変更した箇所全てを人力で目grepする。 チェックリストの多重チェックを行う。

などなどこの手の話は枚挙に暇がないことと思う。

逆に優秀なひとたちは「出発点Aを掘り下げていくと問題Bに遭遇しこの問題が解けません」という自体に対して「出発点Aからいくと必ず問題Bに遭遇するならそもそも出発点をFやKのような別方面からアプローチすれば問題自体を回避できる」というようなアプローチで問題自体を叩き潰していることがある。 あるいは少ない労力で問題を回避できるようななにかを思いつくのだ。

優秀なひとは「クライアントがどのような目的から今回の依頼を行ってきたのか?」を事前にメンバーに共有することが多い。 逆に優秀でないばあいは点である「こういう改修や機能追加をおこなってほしい」とだけ伝えることが多い。

この差はこの地点ではあまり問題が表面化しない。 だが開発後半になってくるとこの説明の有無がプロダクトのクオリティーを左右しかねない重要な要素になってくることが多々ある。

つまり「なんのためにこの機能を実装するのか?」という大きな目的が共有されていない場合、どういった点に注意すればいいのか。 どのような改善や提案をすればいいのかがメンバーには共有されないため、全然関係のない箇所に凝ってしまったり、あるいは細心の注意を払って欲しい箇所がおざなりになってしまう。

これはメンバー個人の問題というよりは目的共有が行えなかったというチームの問題であることが多いように感じる。

一人だと1は1のままだがチームで働くと掛け算や乗算になって自分の実力の何倍も発揮することができる!というようなことを耳にしたことがあると思う。 最近ぼくはこれらの言説に大事な但し書きが抜けていると思うようになった。

「同じ大きな目的を共有しているチーム、メンバーに限る」というものだ。

メンバーが向いている方向がバラバラなときにパフォーマンスがぐんぐん上がっている!ということは寡聞にして聞いたことがない。 逆にうまく回っていると感じるチームは同じ問題や目的を共有できていると感じることがよくある。

人間のパフォーマンスというのは我々が思っているよりも高いものではないとぼくは思っている。 だからこそチームが同じ方向を向いたときというのは多段式ロケットのように誰かのつけてくれた加速の慣性に乗っかってさらに自分たちはより遠くへ、早く目的地に到達することができるのだと思う。

ところがこの多段式ロケットの向き先がそれぞれずれていればどうなるか? 考えるでもなく、打ち上げ後すぐさま空中分解。悪くすれば打ち上がることなく爆発だ。

つまり、管理を司るマネージャーやリーダーに求められる技能とはこの「大きな目的」をきちんと見定めて設定することだとぼくは考えている。 いわゆる「問題の本質を突く」というやつだ。

「メンバー全員が同じ意見になるなどほぼ不可能だ」と悪いチームやマネージャーは口にすることがある。

そもそもだがそんな必要性はない、「Not Agree, But Commitment(同意はしない、だがチームに従う)」という状況を作ればいい。 このときに勘違いしてはいけないのは頭を押さえつけるように不満を押し込むことではない、ということだ。 いやいや従うのではなく、「自分の考えとは違うがチームが出した結論を尊重する。」というニュアンスのほうが実際には近いだろうと思う。

さてこの問題に対する解決策はないのだろうか?

ぼくは以下の方針を取ることで解決できるのではないかと考えている。

  • キックオフMTGなどで大きな目的を必ず共有する仕組みを作る
  • 仕事を増やすのではなく減らすために努力する目標設定を作る
  • 都度目的にズレが生じていないか振り返りを行う

これで本当に改善するかはわからないがまず大きな目的の共有を徹底することで多少の改善はみられるのではないかと見込んでいる。

「やらなくていいことならやらない、やらなくてはいけないことなら手短に」という折木奉太郎の標語?は実に素晴らしいと改めて実感した。

やらなくていい仕事をやらなくてすむようにするのがぼくたちの本当の仕事ではないか。

……また氷菓みたくなってきた。

ハーゲンダッツ クッキー&クリームが好き

今週のお題「好きなアイス」

好きなアイスクリームはなにか?と問われたらハーゲンダッツのクッキー&クリームをわたしは思い浮かべる。

最も美味しいアイスクリームではないと思う。 ただ最も気に入っているアイスクリームではある。

コンビニなどで買えること。 決して安いわけではないが最近流行り?の高級志向アイスクリームに比べればそこそこのお値段であること。 クリーミーな味わいとほろ苦いチョコが絶妙にマッチして年中飽きずに食べられる味であること。

これらの条件を満たしているハーゲンダッツ クッキー&クリームが私は好きだ。 とか書いてたら食べたくなってきた…。

KyotoJS 13

kyotojs.connpass.com

昨日のエントリでも少し書いたがKyotoJS13に参加してきた。 前回のKyotoJS12は参加予定だったんだけどもちょうど私事でゴタゴタしていて参加できなかったので今回が初のKyotoJS参加ということになる。

感想

参加してよかったなと思える楽しいイベントでした。 学びあり、笑いあり、交流ありで実にいい規模感と空気感でしたね。

これは関西だからなのか、それともフロントエンド界隈だからなのかまだわかっていないのだけど 結構女性のかたが参加していていいなと思った。

華やかでいいよね!という話ではなくて(そういう面があるのは否定しないが)やはり男だけだと閉鎖的というか社会が閉じている感じがして それはそれで内輪ノリで盛り上がれて楽しいのだけど、なかなか女性の方や外部の方が参加しにくい空気感があるなと東京にいたときに思うことがあった。

その点、京都に戻ってきてから勉強会のときに結構な比率で女性が参加していることがあってこういう空気感はいいな!と思っていた。 WordPress系のイベントとかだと女性のかたがめっちゃ参加していて今までぼくたちがいた界隈というのはものすごくニッチな層だったのではないか?というように感じるようになった。

あと驚いたのは発表者の多くがデモ用意していてすげー!ってなった。 イカやったりオーバーウォッチやったりしながらデモも作成するってどんな超人だよ!

セッションのこととか

個人的に一番キたのは @bokuweb さんの「Visual Testing」が非常にエモかった。 snapshot testingの紹介だけでも「おぉ、こんな便利そうなものが!」みたいな状態だったのに更にそこから踏み込んだ話しになっていてグイグイ引き込まれました。

質疑応答もやはりみんな引き込まれたからか、いろんな意見が出ていて面白かったですね。 予定があって参加できなかった同僚に対していいお土産が出来た。

その次に良かったのが主催者の id: amagitakayosi さんのGLSLハンズオン。

正直なところ「GLSLでVJ/DJやってなにが楽しいんだろうか?」とブログエントリを読んだり、本日最初の発表時には少なからず思っていたのだけど GLSL sandboxで実際にコード書いてそれが即座に反映されていろいろいじったりその仕組が気になったりしてハマる気持ちがわかった気がする。

これは楽しい。 なんていうかこう初めてプログラミングを初めたときのあの高揚感に近いものを感じた。 未来が広がるというか取り得る選択肢が無限に広がるようなわくわく感を少し感じた。

ブログのエントリ読んで「へーそんなのあるんだ、でもそれ何が楽しいんだろ?」と思っていた人はきっとぼくだけではないのでいますぐGLSL sandboxいじっていこうな!

あとGLSL触っていて思ったのが、もはや記憶の彼方のことだけどかつてゲーム会社に勤めていたときに少しだけ触れたOpenGL ESを思い出した。 当然ぼくが触れていたときよりもリッチな表現を手軽に試すことができるようになっていたけど、あの黒魔術郡が今度はWebに現れたのか!と少しだけ感慨深い思いを噛み締めてた。 ただめっちゃバッテリーが熱くなっていたのでCPUやメモリはゴリゴリ使ってそう。

隣にいた女性の学生エンジニアのかたと実際にいじってすぐに反映されているのがみれるのが楽しいですね!という感じで話しが盛り上がった。

居酒屋コーディングでドヤ顔ライブコーディングしたらモテるんじゃないかと少しだけ思ったりなんかした(多分モテない)

その他にもTypeScritpの話しは次元が違いすぎて理解できないけど面白かったし、Refluxはシンプルで最初に触るには良い規模感なのかなと感じた。

GyazoのJSフレームワークの変遷の歴史なんかも他社事例ながら面白かった。 JSフレームワークの寿命が1年というのは真だなーと思いつつ、それらをガンガン入れ替えてサービスに取り込めていけるのがすげえ!って感じで一人鼻息荒くしてた。 イカのやりすぎでLT枠に移動だったけどトークや質疑応答、ディスカッション形式みたいな感じでやればセッション枠でいけたんじゃないかなーって気がしてる。

懇親会も楽しかったし、2次会に参加したかったのだけど大きめの本屋で探している本があって今回は参加しなかった。 もし次回参加したら2次会も参加したい、お酒飲めないけどw

どうやらKyotoJSでは参加したひとは次回LTやる流れらしいので次回のときのためにネタを仕込んでおこうと思う。 「JSに関することならなんでもOK!JSでなくてもOK!」ってconnpassに書いてあったのでイベントドリブンでなんかやろうと思う。

昨日参加したサーバーレス勉強会でも刺激を受けてちょっとフロントエンド開発したい欲に火がついた感ある。 あんまり難しいことやれないと思うので参加してる人たちからすると物足りないと思うけども。

雑談

以前働いていた会社のごにょごにょ経由でぼくのことを知っていてくださったかたとようやくお会い出来たり(はてなのアカウントだけはお互いに知ってた)、 amagitakayosi さんに「そのIDってLandreaallのですか?」と恐らくぼくが記憶している限り初めて出典元を言い当てたりと楽しい雰囲気でわいわいしていけたので今後も続けてほしいなって思いましたまる!

あの日やらかした失敗の名前を僕達はまだ知らない

宇宙兄弟という漫画がある。 映画やアニメにもなったしクッソ面白いので多分みんな知っていると思う。

その主人公の1人南波六太がいった有名な台詞の1つに「本気でやった失敗には価値がある」というものがある。

宇宙兄弟はこういう心に刺さる名言いっぱいあるんだけど、その中でもかなり印象深くぼくの心に刺さったのがこの台詞だった。

ところが、この台詞ぼくの心には深く突き刺さったのだが違和感というか抽象度が高くていまいちきちんと言語化できていないように感じることがあった。

つまり 「本気」 とはどういうものか?だ。

もやっとしたものを感じながらも特にハッキリさせるようなことはせず日々を過ごしていたのだけど 本当になにげなく宇宙兄弟の↑の台詞を思いだしたところ、カチリと自分のなかで「本気」の定義がハマった気がしたのですぐさまメモりながら自分の中の考えを書き出してみた。

つまり宇宙兄弟で書かれていた「本気」というのは安全領域の外で行う挑戦のことではないだろうか?というのがぼくの意見だ。

ただの失敗と本気の失敗を区分しようとしたときに基準はどこになるのか? また自分のなかではっきりとそれを区別できているだろうか?と考えたときにこれ以上ピッタリとぼくの中でうまくハマるピースがなかった。

安全領域の外へと向かう挑戦はいわゆる谷という現象を生じさせる。 一時的に効率や生産性が落ちるが、しばらくするとその反動で急激に上昇するというのが谷という現象だ。

この谷の現象に関する説明は本筋でないため割愛する、気になる人はElastic Leadershipを読めばいいんじゃなかろうか。 なんか最近「ElasticLeadership嫁」としかいってない気がするが気にしない。

閑話休題

たまに失敗することで多少なりとも得るものがある、と主張する人がいる。

今回のことでぼくはこれが誤りであると考えるようになった。 元々この考えに関しては否定的な考えだったのだがそういう考え方もあるか、と許容している部分もあったが今回ははっきりと違うと思えるようになった点が大きい。

つまり、それは失敗にすら至ってない現象だということだ。

失敗すべく失敗したことをぼくは表現するすべを持っていないがそういうことではなかろうかと思う 失敗して得ることができたものは確かにある、がそれは限りなく0に近いものでありほとんど0だと思うのだ。

異論反論はあるだろうが、価値なき失敗はただの惨敗なんじゃないかと考えている。 100-0で負けたという結果だけが残り、その後にも先にもなにも残っていない。これがただ失敗をしている状況なのではないかと思う。

このことから「失敗は成功の元」なんて言われることがあるけどもこれってつまり言葉が足りてない、もしくは誤用なのではないかと思うに至った。 「(安全領域の外へと挑戦した)失敗は成功の元」ということではないかなといまは考えている。

実のところ、この考え方は前々から似たようなことは考えていたがうまく言語化できていなかったことがきちんと自分の中で腑に落ちたということだ。

類似例として「若いうちの苦労は買ってでもしろ」という言葉がある。 ぼく自身はこの言葉がすごく嫌いなのだけど、もしかすると「挑戦した結果の苦労」は価値があるので買ってでも行なえということなのではないか?と少し言葉に対する嫌悪感が和らいだ。

そうするとなんというかこの嫌いな言葉にも一本、筋が通ったように感じた。 筋が通ることで、この言葉が持つニュアンスやエッセンスが少し変わったと感じている。

ぼくの中で「すごく嫌い」から「認めてはないがいてもいい」という感じに変化した。 これで伝わるか全然わからんが。

もしこれこそが発言者(誰だか寡聞にして存じ上げないが)の本意だったのだとすると随分曲解された意図で使用されてきたのだなと思う。 「お客様は神様です」のように発言者の意図とズレた解釈がされてしまうのは悲しいことだとぼくは思う。

思うに歴史上の偉人や英雄と言われる人々は必ずといていいほど大きな失敗を経験しているように思う。 (成功だけで上り詰める人間が存在するわけがないから当たり前といえば当たり前なわけだが。)

そしてその失敗のほとんどが「なにか大きなものに対する挑戦」ではなかっただろうかと考えるに至った。 例えば曹操織田信長坂本龍馬新撰組

有名どころだけだが歴史上に名を残すひとは「なにかに抗おうとしたひと」と言い換えることができるように思う。 それは当時の腐敗した政治や特権であったり国をひっくり返すクーデターだったり反政府組織だったりと実にバラエティーに富んでいる。

文化や風習、益体もない慣習や当時の常識。 既得権益のような実のあるものから社会構造、宗教的思想や宗教観。

それらに抗うことは大きなリスクであったはずなのに彼、彼女らは時に失敗しながらも挑戦し続けたからこそ、いまなお歴史上に燦然と輝く存在として多くの物語の題材になっているのだと思う。

彼・彼女らからぼくのような凡人が学び得ることがあるとすれば「本気でリスクを背負い挑戦する」ことではないかなとちょっと考えている。

安全領域の外側へ挑戦するのは怖いし不安だ。 だけどもそもそもぼくのような凡人のことを気にかけているのは知人や友人、家族くらいのものだし挑戦しても得るものはあっても失うものは然程ないのではないか?と理屈では理解している。 そうはいっても人間は見栄の生き物なのでそれを失うことに対して恐怖を感じてしまうのも否定できない。

ぼくは恥ずかしい人間でありたいといま思うのです。

Serverless 勉強会@京都 vol.1 #slskyoto

sls.connpass.com

サーバーレス勉強会に参加してきた。 ちょうど5月頃にAWS Summitがあってそれに参加したインフラに強いメンバーの一部が「これからはサーバーレスの時代らしいぞ!」と騒いでて「サーバーレスってPaaSやSaaSみたいなもん?っていうかサーバーレスとそれらの違いってなんなの?」と思ってはいたが具体的に調べたりはしていなかった。

特別興味が湧いた感じではなくて困ったり、興味が湧いたときに調べてみればいいかくらいに考えていた。

そんな感じで「名前は知ってるけどなんかよくわからん」という認識でスルーしていたんだけどKyotoJSのSlackで「KyotoJS 13やるぞうおー!」みたいなノリのときに「サーバーレス勉強会とかぶってるじゃん、こっちも気になるー」という発言をみて「おやサーバーレス?そういえば社内で話題になってたな。なになにちょうど(ぼくの都合が良いことに)第一回開催じゃん」という割りと緩い感じで参加してきました。

なおKyotoJS 13は明日開催ですので暇な人はぜひぜひはてな京都オフィスに足を運びましょうぜ!

kyotojs.connpass.com

kyoto.js.org

目的

↑でも書いてるのとかぶるけど勉強会に参加したモチベーションはこんな感じ

  • サーバーレスとはなにか?を理解する
    • SaaSとどう違うのかを理解する
  • サーバーレスになるとどうエンジニアにとって嬉しいのか

結果

目的は達成できたか?を先に報告するとサーバーレスがどういうものかはざっくりと理解出来たように思うので目的のうちの1つは8割くらい達成したように思う。 残り2割はPaaSやSaaSとどう違うのか?がぼくの中でまだまだハッキリと区別出来ていないので他人に説明出来る気がしないからだ。

これが出来て初めて理解出来たといっていいかなと感じたのでまだ足りてない感じですね。 とはいえ「得体の知れないなにか」から「なんとなくわかったような気がする」レベルにまではもってこれたので参加して良かったと思ってる。

もうひとつの目的であるエンジニアにとってどう嬉しいのか?だがこれは正直いまいちピンとこなかった。 勉強会でその点に触れなかったわけではなく、むしろ結構わかりやすい説明があったのだけど具体的に自分の業務にサーバーレスを取り入れたイメージが出来なかった…というのが正解だろうか。

サーバーレスとPaaSの違いとしてイベント駆動であることや実動作時間での課金であるとかの説明は確かにメリットなのだろうと思った。 だがそれらがいま使っているVagrantやDockerを置き換えていくほどの魅力を現時点では感じられなかったというのが正直なところなのかもしれない。 実際に使えばまた意見が変わるかもしれないのでこれに関しては保留というところが正確かも。

VagrantやDockerを使っていない開発環境でサクッとAPIを用意したり、フロントエンド開発やスマートフォンアプリ開発がメインなひとがAPI実装を待ってるみたいなケースだと非常に魅力を感じるところかもしれない。 ただそのうち環境がもっと整ってくればサーバーサイドも「これからはサーバーレスだよね!」みたいな空気になる可能性は十分ありそうだった。

イベント参加した感想

正直なところ「インフラよりな勉強会だからおじさんエンジニアが多めになるのかな」と参加前は思っていたのだけど意外と女性や若い方がいたのは素直に驚きだった。

これは主催者や発表者のコミュニティーが若かったり、参加しやすい空気感があったのかもしれないと感じた。 開催場所が京都駅から非常に近いことやコワーキングスペースということで参加しやすい条件のようなものがあったからかもしれない。

あるいは京都という地方独特のなにかがあったりするのかも? この辺はまだよくわかってないけど京都のコミュニティーはたまに女性やお子さん連れの人、中高生くらいの学生をみかけることがある。

もう一つ可能性として考えたのはサーバーレスという魅力はサーバーサイドエンジニアよりもWordPressなどのCMS周りを扱う人たちのほうが魅力を感じるのかもしれないと思ったこと。 特に先月参加したWordCamp Kyoto 2017でも感じたことだけどWordPress界隈?は割りとAWSGCPを導入することに対して意欲的な印象を受けた。

これはメンテナンス性やブログサイト(というかCMSだから?)の性質からきているものなのかもしれない。

わりとこのことに自分としては衝撃を受けた。 自分たちでサイト作ってサーバー上に構築する…みたいなお仕事をしているひとはそう遠くない将来に今のままでは「おまんま食い上げ」になってしまう事態が十分以上に起こり得るのではないだろうか?と感じた。 というか多分すでにそれは起こっていてぼくが観測できていないだけなのかも。

ただサーバ構築してサイト作れる以上の価値を出していけないと今後は苦しそうだな、特に地方だとというようなこともふと考えていた。

そういえばWordCamp Kyoto 2017の参加レポートもまだ書けていない…あのとき午前から体調悪かったので午後から帰ってしまったのだけどどうもTwitterの反応とかみてると午後のLTがめちゃくちゃ盛り上がっていたらしい、もったいねえ。 今度時間を作って参加レポートまとめておかないと。

今回の勉強会でMVPをあげるなら最初のセッションを発表していた小池氏の「The Essence of Serverless」をあげたい。

Function as a Service(正直また増えやがったなXXX as a Serviceシリーズめ!!!って思った)という概念やサーバーレスのメリットやデメリットに関して入門者向けに簡潔にそして丁寧にまとまっていたのが好印象として残っている。

リモートだったのでHangoutでの遠隔セッションだったが非常にクリアな音声で聞くことができたし、不満点が少なかった。 惜しむらくは質問したくてもなにをどう質問すればいいのか思いつかなかったことだろうか?

説明がうまくてあまり「こういう場合はどうなんの?」みたいな疑問がわかなかった。 それでも質問してるひとがいてそういうひとたちはやはり自分たちでサーバーレスをやっていたときの問題点ややっていく上での問題点を聞いていたようだが。

せっかくの質問する機会だったがうまく疑問を出せなかったのはもったいないなあと思った。 もし次回があれば質問できるだけの知識を蓄えておきたい。

まとめ:

冒頭のサーバーレスに関する内容は初心者が聞く入門編として最適な感じだった。

サーバーレスフレームワークという概念を知らなかったがそのメリットも感じられて第一回の開催内容としては硬すぎず緩すぎず良い空気感だったと思う。 ちょっと内輪なノリもあったけどフレンドリーなアクセントとして働いていたように感じたのでいい塩梅なのではなかろうかと思う。

ちょっと気になった点としてはちょっとイベント自体が静かすぎるようには感じたことだが、それも徐々に解消していったので然程問題があるわけでもないかと最終的に感じた。

あ、2つほど不満点あったかも。 1つはハッシュタグがちょっとわかりにくかったってことですね。

最初2つハッシュタグがあってローカルとグローバルにわかれていたのでどっち使えばいいの???ってなりました。 そのあとの説明でそういうことかーと納得はしましたが個人的には #slskyoto のひとつで良かったんじゃないかなーと思ってます。

もう一つは途中からコワーキングスペースWifiがめっちゃ重くなったこと。 誰かなにか大きいファイルをDLでもしていたんだろうか? 結構ひとがいたのでなにかのアプリがバックグラウンドでめっちゃ帯域を圧迫したとかはありそうだなーって思った。

USJを劇的に変えた、たった1つの考え方 成功を引き寄せるマーケティング入門

感想

イシューからはじめよを読んでいたからだと思うのだがマーケティングもエンジニアリングも課題解決のために必要な根本のところは共通しているという点が面白かった。

イシューからはじめよでは問題の本質=イシューと定義されていたが本著ではビジネスドライバーと称されている。

本質的には同じことを指し示しており、解決すべき問題をとことんまで掘り下げてから考えるという「当たり前にできていない当たり前の考え方」から語られているためマーケティングに興味がなく、あまり頭がよくないぼくでも簡単に読み進められた。

その中でいくつか琴線に触れるワードがあったのであとで一部抜粋して紹介する。

この本で何が学べるのか?と聞かれたらぼくは「目的と戦略、戦術の違い」と答える。 過去のプロジェクトや会社組織で上手く回っていないケースの説明がこの3つの概念で説明できるような気がした。

エンジニアリングとマーケティングはその手法こそ異なるものの目指すべきゴールは非常に近いのかもしれないと読んでいて感じた。 全てのマーケターがそうだとは思わないけれど、今まで得体の知れない存在に対して同じチームメンバーだと思えるくらいには親近感を得るようになった気がする。

経緯

元々のきっかけは「小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則」の「マーケティングは部署ではない」を読んだことが発端になる。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (36件) を見る

マーケティングは会社の皆が行うものである。365日24時間いつでも。 なにかコミュニケーションの手段があるのなら、マーケティングはできる。

その中でこのような感じのことが書かれていた。 そこで今まであまり興味を抱くことがなかったマーケティングに関して「そもマーケティングとはなんぞや?」と少し気になりだした。

この頃、ちょうど大阪の会社を試用期間で辞める直前か直後であり、 「自分にとって理想の会社が関西には少ない、だったらいっそのことフリーランスや起業も視野にいれるか?」 とか考えていた時期だった。

ただぼくはあまり人付き合いが得意なタイプの人間ではないし、マネジメントやマーケティングに無頓着だったので起業にせよフリーランスにせよそこがネックだなとも考えていた。

そのような折にたまたまDHHが書いた「小さなチーム、大きな仕事」を読んで興味が湧いたのが1点。

たまたまその読了後に id:pugiemonn 氏がマーケティング関連について発言をしていたので これ幸いとオススメを聞いてみたところ紹介されたのが「USJを劇的に変えた、たった1つの考え方 成功を引き寄せるマーケティング入門」だったという経緯だ。

↑と読んだ本が異なるがこれを紹介されたあとで「先にUSJを劇的に変えた〜を読むほうがいいかも」という話だったので自分にとって読み進められそうな方を購入した。

琴線に触れたワード集

CEOが最初に雇うべきは人事のリーダー

エンジニアでも営業でもなく人事のリーダーを雇うべき!という主張は想像の埒外にあって意表を突かれた。

成長する会社とは、人的資源を成長させ続けることができる会社

説明を聞くと「なるほど一理ある」という気持ちになった。 成長を阻害させるようなメンバーを採用してしまう人事では確かに不信感やジョインしたそのメンバーにとっても不幸な結果(望まれない人材)になりかねないなと読んでいて思った。

ただこれは万事において当てはまるケースではないとも同時に感じた。

というのもスタートアップなどの創業期に人事のリーダーを雇うのは高コストだとかんがえられるからだ。 なのでこの事例はヘッドハンティングなどでCEOについた場合や昇進するなどしてCEOになった場合にまず最初に腹心となる人事のリーダーを据えろということなのだと理解している。

どこかのタイミングでスタートアップでもCEOの意向を最大限に汲み取って会社にとって益ある人材を見出してくれる人事のリーダーを雇う必要はあると思うが。 創業時にCEOかCTOが人事のリーダーを兼務する形が通常なのかなと思う、それが良いか悪いかはわからないが。

目的と目標の違い

本著で一番の学びがあったと思っているポイント。 わかっている人からすれば当たり前だが漠然とした理解ではなくきちんと切り分けて考えれるようになったと思う。 例文が非常にわかりやすいためすんなりと飲み込めた。

「目的はパリ占領、目標はフランス軍」

目的とは必ず達成する最上位の使命。 目標とは目的を達するために経営資源を投入する具体的なポイント

本著ではそのように紹介されている。 英語だとよりイメージしやすいかもしれない。

目的(=Objective)、目標(=Target)。 後者のほうがより具体性を持つ単語のイメージがある。

そして目的や目標が定まれば自ずと戦略と戦術の話しをすることになる。 日本語だと戦略と戦術は曖昧なところがある、本著ではそこは明確にわけなくてはいけないと書かれている。

目標:Who(ターゲットは誰か) 戦略:What(なにを売るか) 戦術:How(どうやって売るか)

「最強の軍隊はアメリカの将軍、ドイツの参謀、日本の兵卒、最弱の軍隊は中国の将軍、日本の参謀、イタリアの兵卒」という有名な海外のジョーク?がある。 これは詰まるところ戦術レベルでは優れているが戦略レベルでは最低だということだ。

これはマーケティングに限らずエンジニアリング、会社組織にも当てはまるように思う。 つまり目標の設定が曖昧なままに戦略を立てるがそもそも目的がはっきりしていないため的はずれな戦略を立ててしまい、結果戦術をまともにこなしたとしても結果に結びつかないということだ。

メンバーに問題があるわけではないのにチームや組織が空回っているように感じるときはこれらの条件を満たしているように読んでいて感じた。

どう戦うかよりもどこで戦うか

よく言われるやつ。 戦略が間違っていればどれだけ素晴らしい戦術も全く意味がない。 マネジメントもマーケティングも「どこで戦うのか」が一番重要。

Howだけを部下に任せても部下は育ちません

仕事を任せるときは目的からWhoとWhatをHowとセットで考えさせるのです。

部下が言われたことしかやらない問題はここにあるのかなと考えさせられた。 受託開発に置き換えてもいけるなと読んでいて感じた、上司がクライアント。部下が自分たち。

まとめ:

1/3くらいはイシューからはじめよに書かれていたこととかぶる面が多かったが そのあとはマーケティングに関する方向性にシフトしていったので相互に知識を補完してくれる感じで学びがあった。

なによりもマーケティングを知らないぼくのような人間でもわかりやすい。 かつUSJでの事例や具体的な事例を元に説明してくれているので最初に読むマーケティングの本としては最適ではないかなと思う。

エンジニアだとかマーケターだとかデザイナーに関わらず一読してマーケティングとはどういうことか?と軽く理解するのにちょうどいい量と質だった。

次はこの2冊を読もうと考えている。

朝食を #完全食COMP に変更したので経過観察

www.comp.jp

ソイレントの亜種…だと認識している完全食COMPを定期購入してそろそろ1ヶ月以上経過した。 購入後に変わったことや導入してどうなったかを書き残しておく。

購入しているのは定期購入のパウダー4000kcal * 2Pack(6,650円)のやつ。

ソイレントとCOMPで何がどう違うのかは理解していない。

そのうち本家ソイレントも日本上陸するだろ!とか思ってたら亜種のほうが先に出てきて待てなくなったので購入している。 ソイレント知らんけどCOMPじゃ駄目でソイレントでないといけない理由もないので概ね問題ないと思ってる。

変わったこと

  • 朝食が15分くらいで完結する
    • ヨーグルトも食べてるので15分、COMPだけなら5分くらいで終わる
    • 粉入れる→シェイクする→飲むでだいたい5分。洗い物とか含めても10分くらいじゃないかな。
  • 定期購入すれば専用ボトルが付属する
    • 知らずに先にボトル購入してしまった。定期購入(初回のみ)ボトルが付属を外すことができなくて1つ余ってる、ダルい
  • お腹周りが少しスッキリした気がする
  • 食べてから5時間くらい持つ、だいたい朝8時に飲んで13時くらいまではお腹減らない
  • 飲むだけだとストレス溜まる
    • 食べた感がないのでストレスが微妙に溜まる、なのでCOMP+ヨーグルト食べてる。恐らくカロリー的にはアウト
  • 朝のコーヒーを飲まなくなった
    • COMPだけでかなりの量の水分取ってるのでこれにコーヒーを追加するとお腹がタプタプになる

気づいたこと

  • 牛乳で溶かして飲むのが一番ベター
    • アイスコーヒーで飲んだが微妙だった、牛乳のほうがうまい。オレンジジュースなどは試してない
  • 牛乳だけだとお腹下すけどCOMP溶かすと下さない
    • 何故なのかは謎
  • 食費が安く済む…みたいなのはない。
    • むしろ牛乳代めっちゃかかる。
  • プロテインみたいにまずくはない
  • 専用ボトルでなくても問題ないが必要な粉の量の目安がわからない
  • 体重減った
    • COMPだけではなくジョギングしたり週末ジムいったりしてるのでCOMPのおかげで減った感は薄い
  • だまになりやすい
    • プロテインとかよりもだまになりやすい感あるので割としっかり振らないといけない
  • 専用ボトルの出来が微妙
    • しっかり閉まらないときがあってその状態でシェイクしてちょっと漏れることがある、非常にダルい。
    • プロテインとかのシェイカーのほうがこのあたりは優秀
  • 4000kcal * 2Packだと毎朝飲んでだいたい1ヶ月と1〜2週間くらい持つ
    • 3食全部COMPにするとかだと絶対に足りない

まとめ

とりあえず1ヶ月以上試した感触としては意外と悪くない。 以前大学の研究室かなにかでフルーツグラノーラを買って朝食べるようになったら効率上がったみたいな発言をTwitterで見かけたが多分それと同じ効果期待出来そう。

思った以上にお腹が空かなくなるのにはビックリした。 今のところ飽きもせず淡々と毎日飲み続けることができてる。 多分ダイエット目的としては夜ご飯食べる前に少なめに調整した量を飲んでから夜食べるようにするとかなり効果が期待できそう。

ただ家族とかからは嫌な顔される可能性があるのでそこだけ注意かな?