Xmasイブイブにお目汚し失礼致します。社会人歴がようやく三年目をむかえました @mmusasabi がお送りします。
ベーシックアベントカレンダー24日目ですね。皆さん３連休はいかがお過ごしですかね。
これ書いてるのは月曜日とか火曜日なんですが、多分ぼくは寝正月ならぬ、寝クリスマスを過ごしているでしょう。
さて、この今回のぼくの記事は
結論：それ全部できるけど、ちゃんと皆協力してクリスマス迎えようぜ！
というような感じです。開発技法的な話ではなく、開発する上で大切なチームづくりの話がメインになります。
概要
最近とあるサービスのリニューアルに携わることになり、その開発リーダー的な立ち位置で携わりました。が、それがとにかく大変でした。
リニューアルの顛末をお伝えすると、初期のローンチ日を１月延長してもらった。にも関わらずローンチ後に何件かエラーを引き起こし、各所にご迷惑をおかけした。
....いまはそのエラーを取り除きおわり、なんとか落ち着きを見せました。
この記事はもう二度とそういった目に合わないようにするための、ぼくの反省をまとめたものになります。自戒の念がたくさんこもってます。
ぼくの思ったこと、感じたことが正解かどうかはわからない。
ですが、同じように社会人歴３年目で開発リーダーを初めて経験する人たちに向けてアンチパターン的な感じで受け取ってもらえれば幸いです。
この記事を書く上でのキーワード置いときますね
- 開発フォローないのは辛すぎます。
- 仕様を把握している人間が営業だけって厳しすぎる。
- 確認を取る人、仕様を把握する人がいないのはヤバイ。
- もっと良いチームビルディングしたかった。
このキーワードでぼくが何言いたいかわかった方はこの記事の90%はわかったと思うので問題ないです。
良いクリスマスイブイブをお過ごし下さい。
そうでない方はもうしばらくお付き合いくださいませ。
また、この話を読み進めていく上で大前提
ぼくの反省文であるということを認識の上読み進めていって下さい。
残念ながらこのアンチパターンに気づいたのは全て終わった後です。次から活かしていく所存で御座います。
...さて、たくさんの予防線を張った上で、そろそろ読み進めていきましょう。
Keyword no.1 開発フォローないのは辛すぎます。
最小人数でサービスのリニューアルをするぞ。そうなった時皆さんはどういったメンバーを集めますでしょうか？
開発者２〜３人に、ディレクター、デザイナー、企画立案者などを思い浮かべるでしょうか。
今回ぼくが携わったリニューアルは
開発者３人、営業１人、デザイナー１人。ヘルプとしてもう１人開発者。
というチームでサービスのリニューアルをやることになりました。
この時のぼくは新しくサービスをリニューアルすることに期待を膨らませ、どんな実装しようかなと考えるばかり。
この後来る恐ろしい出来事の数々のことなど、全く考えてなどいませんでした。
そもそも一体何をリニューアルするんだ？
そもそも、ぼくが何をリニューアルしたか。という説明が必要ですね。
リニューアルすることになったシステムは一言で言うと「発注システム」です。
とあるクライアントさんが、弊社に対して商品を発注し、弊社がそれを受付て、指定の商品を発送する。そんなシステムです。
旧システムは様々な問題を抱えております。例えばシステムに関して言うと
- バリデーションがなく、自由に発注ができてしまう
- ルール無用の発送システム
- 商品データの乱雑な保管方法
ソースレベルで言うと
- ソースコードがブラックボックス化しており、特定の人間しか触ることが出来ない。
- バージョン管理してない
- ドキュメントもない
そういった状態です。
社内でもこういったシステムはかなり珍しく、かなり歴史の長いシステムです。開発期間は３ヶ月となり、さてどうテコ入れしようかと悩みました。
兎にも角にもまずは設計をしよう
開発部３名でシステムとデータベースを確認してみて、そこから草案となる新発注システムの機能や設計を詰め込んだものを作る。
そこから営業と打ち合わせをすることで、大まかな設計図を作りました。
しかし、打ち合わせをする営業さんはあくまで営業。社内にいないことが結構あり、なかなか時間を捻出できない。そのため
- 開発である程度仕組みを想定。
- その想定に合わせ、機能を考える。
- その機能を営業へ提案。問題がなければ設計に組み込んでいく。
というようなフローでやっていきました。
しかし、今になって思えば、これは結構手間だ
そもそも最初から必要な機能は知っている人に色々考えてもらったほうがスムーズです。
そして、この後も出てくるのですが、この想定で提案した機能と、営業側、使う人側が思っていた機能と小さなズレがいくつも生まれてしまいました。
これでは、いけませんね....
反省：企画・機能作成等は開発が考えるのではなく、必要としている営業や使う人が考えるべき
当たり前の事を言っているようですが、今回のようにリニューアルの主力を開発にまかせてしまうと僕らは機能のバージョンアップと指示のない機能はリプレイスしてしまいがちです。
使う人のことを思って作るなら、使う人が大枠を設計するのが一番です。
Keyword no.2 仕様を把握している人間が営業だけって厳しすぎる。
早速一つ反省が出ましたが、しかしこのチーム編成だとその反省を活かすのは難しい。
開発途中に気づけたものの、その考えるべき役割の人が時間を取れなかったのです。
一番仕様を把握しているのはアルバイトと営業、そして部長
今回のリニューアルを使う人はクライアントと、その発注を処理するアルバイトや営業。たまに部長も確認します。
しかし、皆さんそれぞれ別のタスクで大忙しです。
なるべくヒアリングをしながらの開発を行っていても、そのヒアリングすべき人が捕まりません。リニューアルが後半になるにつれ、開発もヒートアップしていきます。
各々が各々のタスクに集中できているのは良いことです。
しかし、そのゆえ誰も仕様をコントロールする人がいなくなってしまいました。
反省：専任で誰かが全体の動きを把握する役割を持った人をチームに入れるべきだった。
...今回で言うと開発リーダーポジションであるぼくが見るべきではあったのです。
が、３ヶ月という開発期間でのぼくのリソースは、ほぼ開発にフルコミットという状態で時間を取るにも取れない。
気付いたときには既に手遅れ。気合で何とかするしかない状態でした。
そして、未だ反省すべき点があります。
突如、膨れ上がる仕様
今回リニューアルすることになった管理画面の自由度の高さ。
バリデーションのない入力項目。１００以上のカラムが並ぶマジックナンバーだらけのテーブル。
これらを駆使して裏仕様的にオペレーションでなんとかしてきた。
このなんとかしてきた。というのが非常に厄介でした。
当初の設計、開発計画には無かった要素が開発を進めれば進めるほどに五月雨式に出てくる。
気づけば、もう６０営業日（３人で開発するので１ヶ月の延長）が必要な状態になってしまい、開発陣はてんてこまいです。
えらいこっちゃ。
聞くべき人が捕まらない
裏仕様を把握している人間が営業であるため、常時社内に居らず、ヒアリングしたいときにヒアリングできない状態が続いてしまいました。
そのため、エンジニアの裁量で作ってはみるものの実際出来上がったものは使う人達に
「〇〇が出来ると思ってたのに！」
「〇〇の機能はどうしたんです？」
と言われてしまいました。開発としても良かれと思って作ったものがばさーっと言われてしまうとちょっと悲しい気持ちになります。
反省：完成後の理想像を持つ人を作り、その人がきちんと確認できる環境を整えるべき
当たり前ですが「KPIもKGIもずれてるよ？」と言われても、じゃあ何が正しい指標なのかを確かめようがない状況だと自ずと発狂します。動きようがないぜ。
開発が始まる前にそういった時間を確保し、タスクをコントロールし、裁量権を持った人間が誰なのか。
それらをハッキリさせてから開発スケジュールを立てないと、酷い目にあいます。
Keyword no.3 確認を取る人、仕様を把握する人がいないのはヤバイ。
このあたりは前の話も通じるものなんですが、判断を下す人がふわふわしてしまうと着地が分からなくなってしまいます。
しかし、機能テスト、仕様テストはしないと何がおこるかわからない。仕方ないので、確認できる人間全員にお願いして人海戦術的にテストを実施しました。
しかし、この時点で全員が何がゴールなのか。それを共通認識として持っていないのです。
開発がテスト仕様書を作っても、本当に探したいものに出会えない。
テストとは、ちゃんと動くかどうか。という機能テストである部分は無事行うことが出来ました。
と言っても、エンジニアが予め作る機能をリストアップし、そこで出来ることをリスト化。
それを関係者各位に手渡し、軽くシステムの説明をした上で実際に触ってもらう。想定とは違う操作も色々やってもらい、その上でエラーを吐かないか見る。
まぁ、良いでしょう。
しかし、それだけでは見てもらえないものが多数ありました。
実際のオペレーションで使う部分
多くのクライアントに使ってもらっているシステムではあり、その上でかなりイレギュラーを孕んでいました。
例えば、たまにアルバイトさんに依頼して、クライアントからではなく別の人から発注を行ってもらっている。
商品名を入れるカラムに、別の値を入れる。そして、それをcsvなどでダウンロードしたあと別のものに加工する。
...それ！最初に！教えて下さいよ！
というような部分が全く網羅されていませんでした。
それ故、リリース後にあれこれ言われてしまいました。
反省：詳しいオペレーションなど、属人化している操作など無いか予め関係者各位全員に聞く。
反省：もしくは、予め運用内容をドキュメント化してもらい、それを確認しながらやる。
そもそもの大機能の不足
テスト終盤に近づき、とある発言が生まれます。
「そう言えば〇〇って機能はこのあとできるんですか？」
(｀・ω・´)？
無論、そんなものは出来ません。テスト終盤はつまりリリース間際です。
しかし、運用する上でかなり重要な機能がその時点で実装されていませんでした。
反省：使用頻度の高い機能なども予めヒアリングして、関係者各位全員に聞く。
Keyword no.4 もっと良いチームビルディングしたかった。
これは色々なすべてのことが終わってから思ったことです。
ここで開発者三人の内訳を紹介しますと
3年目エンジニアぼく。1年目後輩エンジニア＊２。
です。まぁ、教えながらやれば大丈夫やろと思っていた過去のぼくを助走をつけてぶん殴りたいです。
もっといい開発手法あったやろ
開発はアジャイル型だ！と言えば聞こえは良いですが
ある意味大枠の機能を区切って、それぞれ実力にあった、もしくはやってみたいと思うような部分のタスクをそれぞれ分配してお願いすると言うかたちでした。
しかし、前述したとおり
機能の詳細が全然詰めきれていない
のです。故に、それぞれが仕様の確認に四苦八苦するわけです。MTGを開催して入念に詰めないといけないような部分なは基本的にぼくに集約されて、ガッツリ時間をとるわけです。
それ、無駄じゃん...。
恐らくざっくり大枠の機能を区切る。までは良かったんです。
そこでぽいっと任せるのではなく、開発に入る前にもっと入念に開発計画を立てる。
そうすれば、よりスムーズにタスクを進めることが出来たかなぁと反省でございます。
反省：お願いするタスクが生産性を落とさないようにして渡すべし
そして、終戦。俺たちの戦いはこれからだ！
いろいろな困難を乗り越えなんとかリニューアルへとこぎつくことが出来た。
戦後報告としては
- ローンチ日は一月延期させてもらった
- しかし、機能はあなぼこでエラーも多発
- それから２週間後にようやくまともな運用ができるようになった
というような状態です。
しかし、未だにぽろぽろ「これが出来ない」「旧システムの頃からある不具合なんだけど...」というような話が上がってきます。
それらは随時対応していきたいとは思いますが、予めそういった話を組み込むことができていればより良い設計や計画が立てれたのに...と思うこともないわけではないです。
そのためにも今回のことは次回に活かしていきたいです。
今回の反省一覧
- 反省：企画・機能作成等は開発が考えるのではなく、必要としている営業や使う人が考えるべき
- 反省：専任で誰かが全体の動きを把握する役割を持った人をチームに入れるべきだった。
- 反省：完成後の理想像を持つ人を作り、その人がきちんと確認できる環境を整えるべき
- 反省：詳しいオペレーションなど、属人化している操作など無いか予め関係者各位全員に聞く。
- 反省：もしくは、予め運用内容をドキュメント化してもらい、それを確認しながらやる。
- 反省：使用頻度の高い機能なども予めヒアリングして、関係者各位全員に聞く。
- 反省：お願いするタスクが生産性を落とさないようにして渡すべし
多すぎぃ(´・ω・｀)
...これにめげずもっと上手くやれるように頑張ろうと思います。
サンタさんいい子にするんでプレゼントおくれ(｀・ω・´)
まとめ：この反省を活かし、チームメンバーを集めるには？
会社の方針にもよるとは思いますが、今回の反省を活かしたり、回避したりするには
- リニューアルに関わる人のリソース配分をきちんと考える
- その上で人が足りないということがわかれば予めそう伝える。
- 関わる人の役割を明確にする
- 開発！営業！とかではなく、彼はどこどこの開発。かれはどこどこの仕様を見る人のような感じで
- 人が貰えないならそもそもの開発期間を伸ばしてもらう
- 駄々こねる（！？）
などが考えられます。
リニューアルという大きな出来事に対して、いろいろ会社も動きにくいこともあると思いますが
そこはひとまず思い切って発言してみましょう。助けが欲しいときは素直に助けを求めていかないと状況は悪くなる一方です。
一つ一つを丁寧にできるように気を配っていくことが何よりも大事かなと思います。
時間に追われ、タスクの整理も出来ずに慌てれば慌てるほど視野が狭くなり、結果的に生産性が落ちてしまうでしょう。
特に、僕自身というよりも、開発に参加してくれている人たち全員の生産性が落ちてしまっていたかもしれない。
効率よくやりたいのはみんな同じなのだから、時間がない時こそ時間がなぜないのかという部分で振り返ろう。
なんだかんだそれが一番の反省でしたかね。
Xmasもこれからだ！
ここまでお付き合い頂きありがとうございますm(_ _)m
良き、アンチパターンとして使っていただければ幸いでございます。
皆様、良い三連休をお過ごし下さい☆