しがないラジオ 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年を振り返って感じました。