読者です 読者をやめる 読者になる 読者になる

sekaie engineers' blog

セカイエ株式会社が主催するエンジニア勉強会について

セカイエから教えてもらった管理業務!!

メリークリスマス!!今日はクリスマスですね!世間はクリスマスムードというのに私は新幹線の中でブログを書いてます!
あ、紹介が遅れました、セカイエの開発総監督 石原です!はじめまして!

我々グリーの開発メンバーがセカイエに来て、半年が経ちました。早いですね。
本来はエンジニアブログですが私は総監督なので、エンジニア向けの内容を書いても面白くないので今回はセカイエに来てからのチーム作りとか、管理する上でのあれやこれやを書こうと思います。

最初に

最初に私の考えをお話しさせていただければと思います。
と言ってもマネジメントってそんな大した事は私自身が出来ているつもりはありません。世の中にはマネジメントについての本やら研修やらいっぱいあります。もちろん本を読んだり研修を受ける事は大切だと思います。ただ実際にプロジェクトを管理するとなると本や研修と同じようにはいかない事がいっぱいあります。
しかも今のやり方が成功しても必ず次も成功するなんて事はないと思ってます。
だから、正解を持っていない事が正しいのではないかと考えるようにしています。
自分がやっている管理方法が正しいとも思わないし、もっとよい方法が出てくるのではないかと常に考えながらチームを管理しています。

私自身、数年前、絶対にミスできないし文句なんて言ったら怒られる環境で仕事をしていました。平気で一時間ぐらいは立たされ説教を受けます。
月末に残業代を申請したら即電話がかかってきて
「お前プロジェクト状況を把握してんの?」
って言われました。要するにサービス残業しろよって事みたいです。

今は、笑い話ですけどその当時は、会社に行くのが嫌で朝出勤している時に「電車が遅延しないかな」とか「このまま乗り過ごしたい」とか「事故が起きればいいのに」とかそういう事ばかり考えてました。鬱寸前ですね。

という経験を活かして業務しています。私が相手にしているのは人間で、このメンバーの力を100% それ以上に発揮する必要があると思っています。それが私の仕事だし、その為の環境を作っていく事が必要なんだという考え方です。
そしてマネジメントは変化が必要な仕事だと思っています。メンバーを変えていく事は大変なので自分からメンバーに合わせて変化し、そのメンバーにあったチーム、文化を作っていく事が大切だと思っています。

セカイエが出来ていなかった事

セカイエに来た時に一番びっくりしたのは設計書です。セカイエは自社でサイトを運営している会社なんですが、まずはシステムの事を理解する時に設計書の場所を教えて下さいってお願いしました。
すると、
「docsにあります。」
って言われdocsには

f:id:sekaie:20151225095747p:plain

というフォルダがありました。
中身を見ると

f:id:sekaie:20151225101207p:plain

「テーブル定義書はありません.txt」
っていうファイルがありました。これだけで衝撃なんですけど、そのファイルを開くと
f:id:sekaie:20151225101455p:plain

おいおい、マジかよって思いました。
各システムのフォルダを開いたんですけど

f:id:sekaie:20151225101936p:plain

大阪人だったらこの内容ツッコムでしょっ!!
最初から設計書ないって言ってくれた方がマシでした。。。

という事で、セカイエにはそもそも設計書はありません。仕様は全て口頭で伝えているようでした。ある意味天才です。
ただ仕様の認識が間違ってしまえば、本当に無駄に時間を使う事になってしまいます。
設計書を書く時間を削減して開発中心にしてきた結果だとは思いますが、新規メンバーの学習コストは高くなるし、設計ミスを招く事になってしまうと考えています。
まずはドキュメントを書く文化を作る必要があると最初に感じました。

メンバーを牽引する

前述させていただいた通りセカイエには決まった設計書はありません(メモベースの資料はあります)。
幸いな事に、セカイエには私一人ではなくグリーから数名のエンジニアと一緒に出向する事になりました。
なので、まずは自分達から積極的にドキュメントを書き仕様の確認を繰り返す事で、セカイエのメンバーにも書く文化を根付かせるようにしました。

セカイエには特に決まった設計書というものがなかった為、まずは設計書の為のツールを準備しました。
セカイエでは設計書として「confluence」を利用しています。
ja.atlassian.com

という事で、基盤の準備ができたらまずは、二つのフォルダを準備しました。

  • document
  • operation

documentには設計書として利用し、operationには作業記録や仕様確認の為の資料を残すようにしました。最初からあまり複雑にしないように心がけました。
ドキュメントについてはまだ完璧にかける状態ではありませんが、以前に比べて資料は残すようになりました。

面談でわかるいろいろ

次にセカイエの主要メンバーと面談を実施しました。
最初の面談で
「私、1on1 嫌いなんですよね。」
って言われた時は、衝撃が走りました。試合開始直後に右ストレートを食らった気持ちになりました。
そこでダウンする事はなかったんですが、30分の予定が1時間くらい話をしました(笑)。
いろいろな方と面談する事で、ちょっとずつなんですけどみんなの言っている事や思っている事が食い違っているというのが見えてきました。
これは目標とか組織の方向性が固まっていないという事ですね。これは、私が決める必要があると思いました。

会議体

セカイエの開発メンバーは、それぞれ朝会を実施していました。これは素晴らしいと個人的には思っています。
朝会やらないとダメなの?って思うかもしれないんですが、私は朝会推奨派です。やらないよりはやった方がいいと思っています。
エンジニアは会議があまり好きではないのでなかなか難しい所ですが、管理する場合、進捗状況やメンバーの体調を朝会で確認出来ればベストですね。
朝会はコミュニケーションの場だと思っているので、なるべくメンバーで主体的に進めてもらえるようになるとよいと思います。
なぜ朝会が必要なのか、それは朝会の場で困っている事などを共有する事で、その他のメンバーが意見をくれたりサポートしてくれたりします。そうする事でチームとしての団結力が強くなります。無駄話をしてもいいのでなるべく発言しやすい空気を作る事が重要だと考えています。

案件の管理(スケジュール)

リノコはリフォームサイトです。それ意外にも顧客管理用のシステムや施工店管理用のシステムなどがあります。
案件も細かいものから大きなものまで沢山ありました。もともとプロダクト管理はbacklogを使っていました。スケジュールもちゃんと引いているようでした。
しかし、スケジュールは守られていませんでした。正確には守れないというのが正しいかもしれないですね。飛び込みの要件が入ったり優先順位が変わったりよくある開発風景だなと思いました。
なので、私から細かいスケジュールの調整はしませんでした。まず進めたのは見える化です。backlogを利用しててもいいが、なるべく今のやり方を変える事なく見える化できたらいいなと思いました。そこで、スケジュールをわかりやすく全体の進捗状況がわかるようにしたいと考え、スプレッドシートにまとめる作業を始めました。
f:id:sekaie:20151225151511p:plain backlogではチーム毎にスペースが分けられており全体を確認するのはそれなりに大変だったので、上記のような資料にまとめ、backlogとシンクするようにしました。そうする事でメンバーはbacklogを更新してもらえれば、一覧で状況を把握できるようにし、資料作成の工数を削減するようにしました。
全体が見えてくれば優先度や開発への影響などがわかりやすくなると考えています。

って事で他にもメンバーを管理する点でのコツとか秘策とか、いろいろあるんですが東京タワーが見えて来たので続きは次回の機会にでも書きます。

まとめ

本当にセカイエに来て助かった事は開発メンバーが協力的だった事です。そして、グリーから一緒に大阪に来てくれたメンバーが本当に素晴らしいメンバーだったという事です。その点で今回、セカイエとグリーが一緒に開発を進める上で大きな問題が起こりませんでした。
まだ我々の開発は始まったばかりです。楽しい仕事をみんなに提供出来るように頑張りたいと思います。
という事で、来年もセカイエの開発ブログよろしくお願いします。
それでは、みなさん良いお年を

ほな!