異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

luccafort.hatenablog.com

id:daiksy さんが以前開催した京アジャビブリオバトルのときにおすすめしていた異文化理解力をようやく読了した。

結論:

もし、あなたが少しでも「うまくチームが回っていないな」と感じるならば是非ともこの本を手にとって読むべきだし、可能ならメンバーにも読ませるべきだと思う。 もし、メンバーが読まないなら要約をしてメンバーに教えればよい。 せめて本著で紹介されている8つの軸を元に自分がどういう文化の人間であるか、どういう文化のチームであるか?は最低限見える化しておくとよい。

本著の対象者は全ての人類といっても過言ではないと思う。 それぐらい汎用的で実用性の高い話しが大盛り特盛りてんこ盛りな内容だと思う。

問題点:

さてここまで絶賛?しているがぼくは本著において実に重大なことが全編に渡って欠けていると感じている。 それはTeamGeekでいうところのHRTがメンバーに必要不可欠だということだ。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

どういうことかというと本著では異文化における違いを8つの軸から解説している。 会社のメンバーに対してHRTがないとどうなるのか?

端的に言ってメンバーを信用していないので「理屈はわかるが自分たちに当てはめるのは難しい」と感じてしまう。 つまりこれら8つの軸はまずHRTという根本の関係を構築した上で更に前進するための方策なのだと思う。

故にHRTがないチームにこの手法だけを取り入れようとしてもうまくいかない可能性があるのではないかとぼくは読んでいて感じた。 本著の問題というよりはチームとして崩壊しているところに手法だけ持ってきても仕方がない、というニュアンスで捉えてもらえればいい。 まずチームとして最低限の体裁を整えたうえで8つの軸にチームやメンバー、会社がどういう文化を持つのかを見える化していくのが重要であると思う。

理想の文化:

ぼくにとって本著を読んでどこに当てはめたかといえば現職の職場であり、チームであり、会社だ。 本著の8つの軸とは…

  1. コミュニケーション(ローコンテキスト vs ハイコンテキスト)
  2. 評価(直接的なネガティブフィードバック vs 間接的なネガティブフィードバック)
  3. 説得(原理優先 vs 応用優先)
  4. リード(平等主義 vs 階層主義)
  5. 決断(合意志向 vs トップダウン式)
  6. 信頼(タスクベース vs 関係ベース)
  7. 見解の相違(対立型 vs 対立回避型)
  8. スケジューリング(直線的な時間 vs 柔軟な時間)

となっている。

ぼくの中で理想的なエンジニア文化を8つの軸から抽出すると以下のようになる。

ローコンテキストなコミュニケーションで、 直接的なネガティブフィードバックな評価をし、 応用優先(帰納的思考)で説得を行い、 平等主義なリードによって敬意を得て、 合意志向な決断を下し、 タスクベース(認知的信頼)によって信頼関係が構築され、 対立してでも見解の相違を話し、 計画に引かれたスケジュールのとおり、直線的な時間で管理されている

この考えには一部強くアメリカの西海岸あたりの思想が混じっており、その影響をブログだったり書籍から受けている点は否定しない。

だがしかし、人によってこの理想となるエンジニア文化というのは当然異なっている。 会社としてもそうだし、個人としてもそうだろう。

そうしたときにいわゆるこの文化のミスマッチが発生する。

この軸と簡単な説明を事前に渡しておけば文化によるミスマッチは減るのではないかと期待している。

まとめ:

ともあれ、まずは会社、チーム、自分が理想とする文化を見える化し、そのうえでチームとしてどの文化で行くのか?会社としてどの文化を求めていくのか?を考えていくのが正しいのかなと思っている。

多くの場合、人は納得さえすれば文化的にかけ離れていたとしてもその決まりに沿って行動するのだ。 つまり、「チームとして上手く回っていない」というとはこの文化の相違による摩擦が起こっているのではないかと考えルヨ地がある。

少なくともぼくは現職に対して2つの相反する文化を感じており、それがうまくチームが回っていない原因かなと感じている。 どちらかがどちらかの手法に合わせる必要があるのだが、放置してしまっているせいでチーム間にギスギスした澱のような沈殿物が堆積していき、最終的に爆発するのではないかな?と考えている。

ところで異文化理解力を読んでると書いたところ幾つかのコメントで「あれいいよね!」と言われたのでやはり文句なく良書といっていいのではないかと個人的には思っている。

今週のお題「今年中にやっておきたいこと」

今週のお題「今年中にやっておきたいこと」

プロを目指す人のためのRuby入門

プロRuby本、もしくはチェリー本と言われるやつ。 先日参加したKyoto.rbで少し写経したり、読み始めたのでこれを今年中には読了&写経も含め読了したいと考えている。

テスト駆動開発

テスト駆動開発

テスト駆動開発

Rails Developer Meetup 2017でテスト駆動開発はいいぞ!ということで「まだみてないです、すみません…今年中にはなんとか」と発言してしまったので少なくとも読み始めることを始めるところまでは持っていく。 完読するのは今のペースだと1月中頃になりそう…。

Goでチャットアプリ作る。

最近Go言語書いてないよなーっというときに id:otiai10 氏の↓のエントリを読んで「やるか!」となったので年末年始を使って久しぶりにGo言語でチャットアプリを作ろうと目論んでいる。 これまた今年中にやっておきたいことじゃないけど。

otiai10.hatenablog.com

まとめ:

このタイミングで今年中にやっておきたいことが完遂間近でないというあたりに「お前これ全部今年中にやれると思うのか?」という心の叫びが聞こえてきますが硬く耳を閉ざして貝に私はなりたい。 とりあえずプロRuby本だけは今年中に読破するつもりなのだけど中々厳しい感じで第一次世界大戦中のドイツ軍もこんな感じだったんすかね?と最近幼女戦記読んでた影響で考えたりしています。 アバババ。

しがないラジオ Advent Calendar 2017 12日目 - 都落ちエンジニアの地方転職活動記 -

しがないラジオ Advent Calendar 2017

どうも、しがないラジオ Advent Calendar 12日目を担当する@lucca0showこと、るっか和尚です。 11日目は id:radiocatz さんです。

radiocat.hatenablog.com

はい、パーソナリティのお二人でもないのに6日目に続きまして2度目の登場でございます、いえーい!!!

実はぼく、去年2016年10月まで東京にいたのですが諸事情あって今は京都でサーバーサイドエンジニアをやっているので「都落ちした地方エンジニアから見た地方転職事情」を報告しようかなと思います。 転職活動そのものや転職してからみえてきた地方エンジニアのあれこれを思い出しながら書いてるので多分支離滅裂なのでそこは勘弁してくれ(人∀・)タノム

ところで東京から京都に出戻りしたときも都落ちなんでしょうか? 都から都に落ちていてこれはまさか無限地獄(゚A゚;)ゴクリみたいな気持ちになったりならなかったりします。

注意: 当たり前ですがこの情報は「ぼく」というPHPerエンジニアなフィルターを通しているため非常にバイアスがかかっています。

「そんなことねえよ!」とか「主語がでけえんだよ!」とかあると思うんですがその場合はコメントやはてブで補足するんじゃなくてブログで反論していただけるとより良いインターネッツな世界が拓けるのじゃないかと思うのでよろしくでしょでしょ。 ついでにその反論ブログをしがないラジオAdvent Calendarに書いてくれたりすると実にいい感じです :)

結論

東京にいま住んでいる、あるいはいま地方だけど東京に移住するのに抵抗がないなら東京の会社で転職活動するほうがエンジニアとしてはいい。

ぼく個人は東京に戻りたいとは思ってないですがしがないラジオのリスナーが求めている「エンジニアとして活躍できる場所」みたいなのはやはり東京のほうが圧倒的に多いと思うのでその点だけで考えるなら東京行くしかないとぼくは思います。 最近は地方でもリモートOKだぞ!って会社もありますが狭き門である点は留意しておいたほうがいいかも。

求人の数

京都在住なので近辺で通えるWeb系の会社…となるとだいたい京都市内か大阪のだいたい2つに絞られる。 この辺は東京でも渋谷新宿辺りにWeb系企業が集中する、みたいなのと然程変わりないかなと思います。

ただ東京と違う点で大きいのはまず分母がめちゃくちゃ少ない!!!ということ。 ぼくは専門学校が東京でそのあとほとんどの時間を東京で過ごしていたのでびっくりだったんですが関西レベルでもWeb系企業の求人は非常に少ないと実感しました。

というより東京が多すぎるだけなんだとは思いますが体感的には1/4くらい。 それも求人を出しているのはだいたいいつもみかける企業…という感じです。

逆に組込系はめっちゃある、なんでこんなに求人があるのかわからないレベルである。東京にいたときは気にならなかったけど東京もそうなんでしょうか? JavaScala、Cあたりの組み込みで使われる言語使えるひとは困らないかも、給与とか待遇とかは不明。 あとiOS/Androidはどこも引っ張りだこっぽい感じですね。

受託開発メインが多い

東京なんかだとキラキラしてるWeb系企業は多かれ少なかれ自社サービスだったりすると思うんですがこれが地方になると受託メインが9で自社サービスメインが1みたいな比率のように感じます。

実際はもう少しマシなんだろうと思いますがスタートアップで有名度がなくて知ることすら出来ないパターンなのかなと思います。 東京もそうなんですがなにせ分母が大きすぎるので上澄みだけでもいっぱいあるように見えます、すごい。

それでも受託開発メインが多いなと感じるのは組み込み系やハードウェアに強い会社が京都には多いからかなと思います。 オムロンとか京セラとか任天堂とか。 大阪もやはり自社サービスよりも受託開発が多いなーという印象です。

旧態然とした開発スタイル

いまだにFTPで編集したファイルをアップしてたりIDEあるのに使ってなかったりとか諸々ある。 人によってはモダンな環境を勝手に構築していたりするがやらないひとは秀丸エディタFFFTP使ってファイルアップロードしてたりする。 ソースコード自体はgitで管理しているというのに…謎い。 ところによってはsvnとか悪名高きVSS(ビジュアルソースシュレッダー)が現役とかある。

いいのか悪いのか判断がつかないけどもクライアントとの距離感は東京よりも近いことが多いかもしれない。 その分クライアントのやりたいことを自分たちで汲み取って形にしていく感じはより強い。 忖度が発生しがちなのが個人的にはクソいなーと感じる。

レガシー業界なクライアント

何故かはわからないがクライアントの業界がレガシーでシステムに例外対応を求められやすい…という印象が強いです。 そのため最初から使うかわからないような汎用的な実装を、短納期で納品することを求められることが多い。 東京だと「レガシーな業界をおれたちの技術で風穴あけてやるぜ!」みたいなスタートアップ企業を見かけますがあまりそういうのは期待されてない気がする、主に転職先の企業とクライアントの双方から。

また勤めている会社も「納品=ゴール」という意識が強い気がしていて「リリース=スタート」みたいなスタートアップ感は薄い気がします。

なぜそうなのか?はよくわからないけど東京ではそういう案件が受注されなくて地方に回ってきたのかな?と推測しています。 東京よりも地方の方が単価安いしそれじゃあお願い!みたいな。

受託開発が多いのもこの辺に理由があるのかもしれません。 アジャイルリーンスタートアップみたいなことに対するクライアントの理解度が東京の頃よりも低いように感じることはある。 単純に所属した会社がそういう属性に強いところとの取引が多いだけというのは否定できないのでもうちょっとデータが欲しい。 なので転職する際に受託開発は嫌だなーと思ってたらその旨を伝えておくとお互いにミスマッチが減るかもしれないですね。

向上心のない技術者

これはたまたまぼくが働いた会社がそうだったというだけだと思います。 あと地方限定の話でもないかなとは思う。

いわゆる向上心のない技術者のかたが関西ではよく見かける…という印象を受けました。 これは東京の場合生存競争が激しく、自然淘汰されていくから見かけなかっただけだと思っているのですが地方だとそこまで競争原理が働いていないのでそういう人が残りやすい土壌みたいなものが出来るのかな?と思っています。 この手の話はしがないラジオでも度々話題になっていたりするので、地方特有ではないですがより顕著な傾向があるきがしています。 恐らく地方はものすごく出来る人たちとそうでない人の格差が東京以上に激しい。

仕事としては向上心なんてなくてもそこそこ回せるので結果としてそういうのが嫌な人たちは転職して東京にいってしまうイメージ。 京都に戻ってきて「この人と話してみたかったんだ!」と思って勉強会とかイベントいったら「あ、その人なら転職したよ、今は東京」ってパターンが何度か……つら。 あとはフリーランスになってるパターンもありますね、大変そうです(こなみかん)

閉鎖的?な文化

全部が全部というわけではないけども東京ほどオープンな感じがしないことがままある。 これは京都だけなのかな? いやでも某大阪の会社もそうだったので京都限定の話しではないはず。

「求人サイトで目にしたのでとりあえず会社に遊びに行かせてよ!」ってメールしたら「無理です!」って返ってきたり OKでたから遊びに行ったら何故か面談開始されて「あれ?会社の雰囲気を知りたかっただけなのに転職前提の話しをされている???」みたいなことがあったり。

特に困るのがこの2つのパターン。

後日「ご期待にはお答えできそうにありません…」みたいなお祈りメールもらって「いやその前段階だったから遊びに行ったんだがぼくもアンマッチだと思っていた」みたいな気持ちになったり。 「1次面談はOKだから2次面談来てくれよな!」というメール。 良い会社ならいけばいいのだけどだいたいあまり自分とマッチしないなと感じてお断りするケースが多いので非常に気まずい。

東京のときは友達経由で遊びにいくことが多かったからかあまりこういう事態が少なかった気がする。

面談時の服装

現職の1次面談で私服(パーカーにジーンズ)でいったら驚かれたこと。 いまだに人事の人に「スーツじゃない人はじめてだったのでこやつ出来る!って思いました、エンジニアっぽい」みたいなことをことあるごとにネタにされてます。 なので割りと会社の文化によってはスーツじゃないと駄目!とか履歴書は手書きで!みたいなクソな古き良き文化の香りが漂っているかもしれないです。 ぼくはクソ食らえだと思ってますが。

Skype面談

最近はSkype面談も増えてきていると思うんですがどうも関西方面だとあまり好意的にとってもらえないことが少なくない。

「大阪に仕事終わってから行くのキツいんでSkype面談でお願い!」ってメッセージを送信したら最終的にはOKになるんだけど非常に難色を示されることが何度かあった。

会えるなら直接会うほうがいいとぼくも思うけど「こういう会社でどういう人材を求めているか説明させてください!」ってオファーを投げてきたのはぼくではないのに時間工面して移動費払うのがぼくというのはちょっとダルいなーって思う。 しかも時間がタイトだし、なんかのついでならいいけどさすがに話し聞きに行くだけにそこまでのモチベーションはないのでかなりつらい。

同じ条件でも東京のオファーだと距離的なものもあるんだろうけどだいたい快くOKだしてくれる、非常に楽だし助かる。

フリーランスの知り合いが増える

たまたまなのかわからないけど京都に来てからフリーランスの人と関わることが増えました。

これは「ワタシチョット○○デキル」人が会社やめた結果フリーランスになる確率が東京よりも高いのか?と思ってたりします。

東京の場合は辞めても受け皿となる会社があるけど地方だと少なくて場合によっては求人募集してない、みたいなパターンもあったりします。 結果としてフリーランスになるのが一番合理的だと判断されてそうなってるのかな?と考えてます。 真偽は不明だし、憶測としてもかなり乱暴な説。

地方の勉強会/カンファレンス事情

圧倒的に勉強会、カンファレンスが少ない。これはもうどうあがいてもなんともならない問題の1つだと思う。 少ないというか東京が異様なのであって恐らく地方の方が正しい数値なんだよ。

これはあくまで観測範囲内の話だけど東京との違いとしてもう一点あると思っててキャンセル率が東京ほど多くない、気がします。 地方の勉強会の場合割りと内輪ノリが強くてその分キャンセルしにくい空気感があるのかな?と思ってます。

数が少ないし、ドタキャンとか東京と同じ感覚でされると勉強会自体が成り立たなくなってしまうからじゃないかな?とも考えているんだけどどうなのだろうか?

気のせいでなければ地方の勉強会のほうが内容の密度が濃い、というか尖った発表が多い気がするんだけどこれは東京だとターゲット層が広範囲になりすぎてしまうからなんだろうか?

QOLがあがった

実家に居候してるからという点を抜いても東京に住んでいたときよりもQOLが上がったと言い切っていいと思う。 給与が下がっても、諸々かかる諸経費が下がってるのでトータルでは上がるみたいな感覚、で伝わるかな? これは他の地方エンジニアのひとも似たことを言っていたので多分ぼくだけが感じているというわけではないと思う。

元々生まれ育ちが京都だからというのもあるけど京都くらいの都市規模がぼくにはマッチしていたという点はあると思っている。 もちろん、すごい田舎にいった場合とかはわからない。 東京に比べれば京都は田舎だけど、他の地域に比べればそれなりに都会だしこの辺は相対的感覚なのでケースバイケースだとは思う。

通勤電車がつらくない

大事。 京都の満員電車ってこんなもんだった?みたいに拍子抜けする。 ただしその分電車の本数は東京とは比べ物にならないくらい減っているので調子こいてると終電逃して歩いて帰る羽目になった。

通勤におけるストレスが下がったのは地方ならではなのかわからないけど非常に良い点だと思ってる。 そもそも通勤手段のメインが電車ではなく車とかもある、ぼくは自転車だけど。

さいご

ネガティブフィードバックが多くなってしまったが基本的に東京という環境がエンジニアにはすごく恵まれているということだと思う。 なので相対的にネガティブになってしまっている気がする。

今のところぼく自身は東京のメリットよりもデメリットが大きいと感じているので特に東京に戻って再起をかける!みたいな気持ちがわかない。 それよりは妹氏の夫がドイツに赴任されてるので1ヶ月くらいドイツで働いてみたいなーって気持ちのほうが大きい。

東京は良くも悪くもなんでもあるんだけどその分の対価がストレスだったりするのでぼくとしてはあまり馴染めない感じで地方エンジニアも悪くないなって気持ちです。 東京の仕事を地方に住みながらやっていくみたいな働き方ができるようになれば最高。

Rails Developer Meetup 2017

techplay.jp

ハッシュタグは #railsdm

過去何度か大阪会場で参加しているrailsdmに久しぶりに参加してきました。 2017年最後の〆に相応しい豪華登壇者のかたがたと濃ゆい内容から初心者に刺さる内容まで多岐に渡っていたのではないかなーと思ってます。 ちなみにぼくはRails初心者なので割りと得るものがあったなーという感じです。 特に一番最初の「レールの伸ばし方」 by 前島 真一@willnetさんのやつとか。

感想:

通常こういうイベントは東京で開催されると他地域では参加できなくて指をくわえるしかないのですが railsdmは過去何度か参加させてもらったのですが大阪サテライト会場にGoogle Hangoutで中継されるので非常に助かっております。 会場を提供していただいているAimingさんには毎度感謝の念しかありません、ありがたや。

今回特にすごいな!と思ったのはセッションの中身…ではなくて運営スタッフによるタイムスケジュール管理の完璧さです。 ほぼ遅延することなく、予定時間通りに進行して古強者感をヒシヒシと感じていました。 もちろんセッションの中身も良かったですよ!

個人的MVP:

個人的に本日の登壇者のかたからMVPを選ぶとしたら誰かな〜と帰りに考えていたので発表しておきます。

セッション部門:

株式会社ソニックガーデン 伊藤 淳一 氏のRails ♥ SQL

受賞理由: 賛否両論ありそうな議題の提案と対応の仕方、実務に近いコードをどう対応するかが想像出来る余地を残しつつ議論出来る余地もあってメモ取るよりもコードみながら頭のなかで「ぼくならこうするああする」「これはどう対応するんだ?」と主に思考方面にCPUを割り振ってました。 Twitter上の反応などもみていると賛否両論あったり別角度からの意見もあって初心者なぼくには「そんなアプローチがあったのか!」と目から鱗な思いでした。 コードをみるだけではわからないが実務でありがちなことということ。 そして何よりも本日最も得るものが大きく多かったと感じたため勝手にMVPを送らせていただきますドンドンパフパフ〜♪

LT部門:

セッション部門は割りとハッキリ「今日の一番はこれだな!」と感じたんですがLTはめちゃくちゃ難しかった。 どうしてもLTという特性上時間に限りがあるので濃縮圧縮された情報になってしまうので突出して良い!と感じにくい土壌があったので非常に悩ましい。

悩んだ末に↓を選びました。

株式会社Gunosy 榎本 敏丸 氏の「Railsでまだ消耗しているの?」 ─僕らがRailsで戦い続ける理由─

受賞理由: ぼくは今までPHPerで最近、というか今年になってからRailsのイベントに参加するようになったりRailsで簡単なアプリを自分で作ってみたりしている。 そういう意味で「何故ぼくらはRailsを使うという判断をしたのか?」という根源的な問いを突き詰めていたこのLTは個人的に一番刺さったかなと思ったから。 他のLTも甲乙つけがたいものが沢山あって非常に悩んだのだけど「一番印象に残ったLTはなにか?」と言われたらこのLTかなと感じたので選ばせていただきました。 特にお気に入りなのが「Railsって遅いよね?」というネガティブフィードバックに対して「処理系の速さと開発の速さは別」という切り返しがスマートでカッコいいな!と感じました。 確かに処理系の速さを求めるところでRailsを選択するのはそもそもその俎上に上げるやつがどうかしてるのであってRailsどうこうの問題ではないし、なによりも開発の速さこそRailsが誇る持ち味の1つなんだから比較対象がそもそもずれてるな!と気づきました。 ISUCONでRails選択せずにGo選択したりNodeJS使うという選択をするのは正しい判断であって、Railsを頑なに使うのはただの思考停止だなといろいろ考えてしまったので特に印象に残っているのかも。

ネガティブフィードバック:

とまあ良いことばかり書いているんですが95%くらいはいいことだったんですがとはいえ改善してくれると嬉しいなーというフィードバックもあるのでそれも紹介しておきます。 個人的には解消は難しいと思ってるものばかり。

  • 東京会場の騒音(環境音?)がノイズだった
    • ものすごくうるさいわけではないが(一部消防車の音など例外あり)ちょいちょい登壇者の声のボリュームが小さいと聞き取れないことがあったのが残念
    • ただ窓を閉じると空気が薄い…みたいな話もあったので空気は大事、騒音よりも大事だぞ!って思ってるので改善されたら嬉しいくらいのものです。渋谷らしいし仕方ない。
  • Google Hangoutの音声品質があまりよくない?
    • リモート中継枠のためだと思うんですがrailsdmで毎回いってる気がするが音声品質悪いので聞き取りにくい
    • 最初は機材の問題かと思っていたがどうもソフトウェア側の問題なきがする、Google頑張れ。
  • 東京会場と大阪会場の会場の雰囲気に温度差がある
    • 会場のストリームも資料の配信とは別で流して欲しい、でも映されたくないとかで絶対問題になる現実的解答でない。
    • 大阪会場で拍手がまばらだったりとか質疑応答がしにくい空気感を感じることがあるので何かしらの善処はしてくれると嬉しい
  • アンケートが各セッション&LT毎だったので書いたあとでTwitterで「アンケートはこちら!」というのを見かけると「あれ?これ書いたっけ?」みたいな感じで不安になる
    • うまい方法を思いつかないのだけど記入済みのものはなにかしらのチェックされてるされてない的なものが欲しい
  • 懇親会(大阪会場)あるって思ってなかったので別の予定いれてしまった
    • 懇親会あるのってどこか情報あったかなー?なかったとしたら次回からは懇親会あるかもよくらいの情報はのせてほしいなって。
    • せっかくのRailsエンジニアの方々との交流する機会を逸してしまったのマジもったいなかった。

以上! どのセッション&LTも楽しかったし学びがあって良かったです。 2018年のやつは…参加したいができるんだろうか? とりあえず全32セッションは狂気の沙汰だなと思ってます、運営スタッフ大変そう(こなみかん

しがないラジオ Advent Calendar 2017 6日目! :)

しがないラジオ Advent Calendar 2017

どうも、しがないラジオ Advent Calendar 6日目を担当する@lucca0showこと、るっか和尚です。 5日目は@HKDnet さんになります。

さて、Advent Calendarを書いたことがある方はわかると思うのですが なにを書くのか?が非常に難しいのですよね。 誰かとネタがかぶると困るしかといってなかなか事前に準備できるものというのは限られるわけです。

そこでこの1年、今まで行わなかったことを実は勉強していてしがないラジオでも似たような話しがよく上がっているのでそちらの話しをしようと思います。

マネジメントとかリーダーシップをまなびはじめたよ!

なにかといえばそういうことです。

自己啓発本などはいまでも「意味ないなー」と思う程度には世の中を舐め腐ったナメクジクソ野郎なのですがとあることがきっかけでマネジメントやリーダーシップについて学んでみようと思い立ちました。 それがだいたい今年の2月頃の出来事。

マネジメントを学ぶきっかけ

ちょうどその時期、大阪のWebのベンチャー企業に転職が決まりました。 そこで働いて2週間ほど働いていて明らかにおかしなことがあります。 そう誰もマネジメントをしていないのです。

明らかにうまく回っていない、問題の本質はタスクがどれくらいあって今やってるタスクはなにを解決するためのものか?優先順位はどこか?

これらを問うと「そういうのはよしなに空気感を感じ取ってください」といわれたので 「あ、これマネジメントを学ばないとぼくが過労で倒れるわ」と思ったのが最初のきっかけです。

はじめてのマネジメント

そこでまず誰がどのくらい出来るのか?をまず調査しました。 外注のデザイナーさん(週3回)以外は学生エンジニア(プログラミング未経験インターン)、 そのうち1人は1週間後の退職が決まっておりしかもぼくの前任のメイン担当者。

もう1人は大学の研究室が忙しいので来月あたりから1ヶ月ほど来ないと言われています。 最後の1人は不定期ではあるけど週のうち3日ほどは来れるとのこと、唯一の希望。

そして結論からいうと仕事を通してプログラム未経験から半年くらい学んだレベルでした。 それ自体は全く問題ではないのですが現状を鑑みるとぼくが望む最低限のレベルに達しているフルタイムで働けるメンバーがいないという問題が浮き彫りになりました。

また、外注のデザイナーさんは非常に手が速いもののgitがわからんとのこと。 デザインに関しては非常にアウトプットが速い点やレスポンスが速かったりといい感じだったのですが如何せんプログラマと組んでチームで開発する経験値があまりなさそうに感じました。 このあたりは経験がないというよりどうやればいいのか上手くいってなくて今までおまかせ(丸投げ)だったのが原因かなと考える部分があったりなかったり。

そんなこんなでまあやばいよね?って感じでした。

まずgitとはなんぞや?からはじめた

ってことでまずgit commit&git pushはできるけど他はなんかよくわからん!なメンバーをまず全員集めます。 なにせ修正中のコードをpushされたらmasterをデプロイしていいのか、悪いのかすら判断つかなくなります。 なのでまず基本方針とそのために必要なgitの使い方をレクチャーしました。 そして今後どうやって開発をしていくかの説明を行います。といっても大した話しではなく

  • 修正依頼は必ず口頭ではなくチケット切って依頼。
  • 修正依頼が来たらブランチ作ってそこで修正する。
  • 修正が確認できたらそのブランチをレビューしたあとでマージ。
  • レビューの通ってないものはマージしない

本当はテストコードがどうとか諸々あったけど一度にいきなり変えても情報過多で対応できないだろうと判断したので比較的導入が簡単で効果のあるものだけを導入しました。 ちなみにぼくが入るまでは他人のコードの修正がmasterにガンガン入っててデプロイしたら動かなくなるページとか普通にあって原因調査にめちゃくちゃ時間がかかりました。 「手元の環境で再現しないのになんでだ!?」みたいな感じになって、本番のログみたら普通に400系や500系のエラー吐いてやんの。

タスクの割り振り方を変更

さてそんな状況でフルタイムで働けるメンバーがぼく以外誰もいないという状態だったのでまずタスクを1週間単位で切りました。 Aさんの今週のタスクは「メール送信時に文字化けが発生する原因の調査と解決、マストは原因の判明。最悪解決できなくてもいいですがどこまで調査してどういう対応をしたかを必ず書いてください」 Bさんは今週のタスクは「一覧のソートがこの条件のときに意図した並び順になっていない原因の調査と解決です、そこが終わったら詳細に移動したときに表示されない画像があるのでその原因の調査です」

といった形でタスクを切りました。 そして週一で進捗会議を行いました。

今どのタスクが残っていて、どのタスクの対応が優先順位が高いか、今週中に渡したタスクが終わりそうかなどなど。 他のも問題点や疑問点などがあればそこで報告するようにしていました。 この会議は全員が集まることが難しかったのですがTrelloでタスクをカードで管理してオンライン上でいつでも確認できるようにしたため、休んでいたメンバーもどういうタスクが追加されてどのタスクが割り振られているかがわかるようになったのでメンバーからはそれなりに好評でした。

このときに「これはリモートワークなどでも通じるコミュニケーションロスとその対応が応用できそうだ」と感じました。 いままでフルタイムで働くメンバーばかりだったので、こういう対応やその場にいないメンバーもいるメンバーと同等の情報にアクセスできる状態を保つのはなかなか難しいぞと感じたのが正直なところです。

そのとき参考にしたマネジメントの手法はWEB+DB PRESS Vol.97を一部真似させてもらいました。

とにかく課題が山積みだったのでトリアージを行って多少のバグや優先度の低いものは後回しにして緊急度の高いタスクのみを片付けることに専念しました。

とにかくこれによって「マジでこれはやばい、徹夜してでも直さないと!」みたいなバグはなくなりました。 潜在的には同じようなバグが眠っているとボク自身は感じていましたがとりあえず現段階で表面化していなかったこととそこまで手を入れるなら作り直したほうが早いので無視しました。

はじめてのマネジメントから学んだこと

その現場を通してぼくがマネジメントから学んだことは

  • 1日に対応できるタスクはだいたい3個、多くて5個
    • これ以下だとタスクの粒度が大きすぎるし、それ以上だとタスクが細かすぎることが多い
    • 1タスクにかける時間はおおよそ2〜3時間ほどが一番バランスがいい。
  • タスクに優先順位をつけて、合意をとる
    • 当たり前のように感じていたが顧客から言われた質問をそのまま投げてくるバカひとが世の中には存在するので今週はここまでしかやりません!というのは非常に効果的だった
  • フルタイムメンバーのありがたさ
    • 今までほとんどのメンバーがフルタイムな職場ばかりだったのでそれが当たり前だったが非常にありがたいことなのだと実感した
    • なによりタスク管理やスケジュールの組みやすさ、計画のしやすさを実感した
  • マネジメントはある種の技術
    • この会社のCTO的な立場のひとが「マネジメントはやればできるようになるよ!」とか言ってて当人は全然できてなかったが確かにある種の技術的な素養があった。
    • いままで属人性の高いスキルだと思っていたが単純に対処手法を理解していないだけだと気づけた。
  • 仕事の信頼は仕事でしか得られない
    • この言葉自体はもっとあとで知ったことだがマネジメントという仕事を通して学生エンジニアのメンバーと信頼関係が築いていけたかなと思ってる
    • 逆に経営層に対しては不満感をもってしまったが

今までマネジメントというのはあまり興味がなく大変そう(コナミ感) と思っていたが実はそうではなくてコードやデザインのように問題解決するためには ある程度出来るようになっていたほうが問題の本質を解決することができるしなにより無駄なところで疲弊せずにすむのだなと実感できた。

まとめ

マネージャーやリーダーになるかどうか?は本人の気持ち次第だと思うのですが エンジニアとしてそういう方面の異質な技術力があるというのはある種の強みになるのかもしれないなと思いました。 マネジメントもやっているエンジニアではなくマネジメントに強いエンジニアをイメージするとニュアンスとしては近いかなと思います。 またマネジメントは扱える範囲がべらぼうに広くて「こんなにいろんなことができるのか!」と純粋に驚きました、プログラミングやエンジニアリングで対応できることのなんて幅の狭いことか!とようやく世のマネージャーやCTOたちがピープルウェアに書かれている引用をよく使うのかが理解できました。

実際にはそれでも嫌だと感じるひともいると思います、そのひとは無理に目指す必要もないかなと思います。 ただぼくが思うにエンジニアリングだけ、プログラミングだけが許されるのは一部の超人だけなんじゃないかなと。 それはマネジメントさせるには価値がないほどに狭い範囲で成果が出せる超人でなくてはそれに専念させる価値を会社側が見出だせないからだと考えるようになりました。

エンジニアにマネジメントをさせることがいいことか悪いことかは判別つかないのですが、そもそも問題解決という意味ではエンジニアリングもデザインもマネジメントも取り得る範囲や場所が異なるだけで行っている本質は然程違いがないんじゃなかろうかと思います。

ただし例外もある

問題は技術力がないからマネジメントに逃げるタイプの人でマネジメント系の本やセミナーに参加して身につけた気になっているひとはかなり注意が必要だと思います。 ぼく個人としてはマネジメントはコードの何倍もの勉強量と質を求められると感じています。

なので技術力がないからと尻尾を巻いて逃げ出したひとが安易に逃げ込む場としては不適切だと思います。 実際には課題から問題の本質を抽出し、それに対して効果的な対策を考え、データを計測し、結果を分析し…とあまりにも多岐の知識、仮説や問題に取り組まないといけないのですから逃げ出した先が地獄の釜だったみたいな結果になるだけだと思います。

ぼくらが遭遇している問題の殆どはマネジメントが起因の問題であると思います。 であるならばそれを解決することが本当の意味でエンジニアリングやデザインに集中できるようになるのではないかと最近考えるように意識が変わったかなとこの1年を振り返って感じました。

3大今年買ってよかったもの

今週のお題「今年買ってよかったもの」

よかったもの

Inateck ラップトップスリーブケース

以前も紹介したが今年のベストバイをあげるならこれかなという気がしている。 使いやすく、また使い心地も良い。 不満点もいまのところないため、ほぼ満点に近い。 ポーチもついているのだがそれも結構収納力があるので周辺機器くらいならだいたい入る。 不満点の少なさ、満足度の高さからまだ1ヶ月ほどあるがベストバイといいきって問題ないと思う。

Bianchi リュックサック/ディパック NBTC50

スリーブケースとどちらにするか一瞬悩んだが結局スリーブケースをベストバイにあげてしまった。 このディパック自体は決して悪くない…悪くないのだけど2点だけ小さな不満点があるので順位を下げてしまった、それ以外は概ね満足いく品だと思っている。

不満点:

  • タブレット用スリーブがiPad Pro 12.9インチだとギリギリ、出し入れのときに引っかかることがあって手間。
  • 定期入れなどをすぐに取り出しにくい、ポケットは全体的に見た目以上に大容量で満足している。やはり一手間が惜しい。

今までは通勤用のディパックにNORTH FACEのディパックを使用していたのだがタブレットと書籍だけもってふらりと読書にいくには幾分大掛かりだったこともあり、もう1サイズ小さいものを探していた。 持ち物としては弁当、水筒(500ml)、タブレットに書籍。あと通勤後に汗をかくため着替えを詰め込めればOKということでこのサイズがベストになった。

このディパックで満足度が高い点としてショルダー部分がNORTH FACEのものに比べてずり落ちにくい点がある。 NORTH FACEのものはチェストストラップがあるが使うと窮屈、使わないとずれ落ちるという微妙さがあった、その点が結構ストレスになりがちだったので解消されてQOLが上がった気がする。 値段もNORTH FACEのものより安かったし、特にぼくが気にしていたディパック自体が自立する(会社で地面に置くため)という点でも安定しているので不満点がなければもしかするとベストバイにしていたかもしれない。

APPLE iPad Pro 12.9インチ 2017年モデル用【書き味向上】液晶保護フィルム ペーパーライクなペン滑り!

商品名がよくわからないけど3位がこれ。 いままでタブレットにシートを貼るなんてアホらしい…と思っていたのだけど少し考えを変えた。 そういう意味でノミネートしている。

これは使い方の問題だと思うのだがぼくはよく読んだ本の感想をiPad ProのメモアプリにApple Pencilで書き込んでいる。 ペン先をタブレットに当てたときの感触が硬い、当たり前だしそれが普通だと思っていたのだけどこのシートを貼ってから感想が変わった。

シート後にタブレットでメモを取ると書き味が滑らかなのだ。 以前は硬い、それこそ硝子にペンを当てているという感触だったのが紙とまではいわないがかなり荒い和紙に文字を書いているような感覚に近いものを感じるようになった。 それまであまり意識していなかったが、このことで硝子板にペンを当てるようにメモを書いていたことがそこそこストレスだったのだと自覚するに至った。

たまたまだが「書き味向上」という文字につられて購入したが割りと正解だった、とはいえ他のシートを試していないのですごくいいとも言い難いのだが。 また他のシートに比べて若干高めであるが個人的にはApple Pencilを使うなら買って損しないんじゃないかなと思う。

まとめ:

電子機器そのものではなく、それを運搬するものや保護するものがベストバイだったのは改めて考えてみてもちょっと意外だった。 ワーストバイをあげるならApple Pencilになる、充電方式がクソいのとバッテリー容量が単体で確認できないのは大きな設計上の問題だと思う。

2割に集中して結果を出す習慣術

結論:

なにはともあれ結論から述べる。

この本は愚にもつかない内容だし、全体的に目新しさも具体的な解決の話もほぼ皆無だ。その辺にある自己啓発本に書かれているものと然程変わり映えしないものだと思う。

だけれども疲れているときや精神がネガティブなとき、ダウナーな思考が続いているときに読み返すと「これは出来ている」「これは出来ていないから出来るようにするには○○しよう」という一種の踏み絵的効果がありそうだなと思った。

全てを満たす必要はないが「自分が出来ていない重要なこと」を見える化するのにちょうどよいページ数と文章量になっている。

感想:

殆どは「やらないことを決めよう!」とか「やることを絞って短時間でやりきろう!」とかそんな話しばかり。 なので当たり前の話ししかされていない。

その上で「これ出来ていないな?」と強く思ったのが以下の5点。

  • 最も効果を出している人にインタビューする
  • 強みを活かした成長戦略を考える
  • まずやることを決めて、とりあえずスケジュールにいれる
  • まず試しに動いて、本格化させる
  • 満足度を数値化し、グレーゾーンを見出す

気になった点や意見、反論、補足なんかをメモしていたけどやはり自分にいま大きく欠けていると自覚している点である↑の点が印象深かった。 奇しくも今は年末であるし、忘念する前に本書を読んだことで振り返りが出来た気がしている。

来年はこれらを課題としてPDCAを回していこうと思う。 そういう意味では1200円だったし、その分の価値くらいはあったかなと思わなくもない。

手元においておいて、ダウナーやネガティブな思考に陥ったときに読み返して「どう解決するのがよいか?」を自問自答するきっかけにしたいと思う。

ちなみに本書を手に取った動機だが「副業と本業忙しすぎて時間が足らん、どうすればいいんだ…」みたいに悩んでいたときにたまたま本屋で目についたから。 そういう意味では当初の問題に対する寄与は全く与えていないので解決に繋がるわけではないが見直しを行う際のチェックシート的なものだと思えば買って損したということもないのかな?というのが素直な気持ち。

ただこの本を購入することをおすすめするか?と問われたら図書館とかで借りて読んでみて面白い、あるいは買ってもいいかもな…という気持ちになったら買ってみるといいのでは?くらいに消極的な感じ。 正直本書である必要性はほぼ見出だせないと思う。