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

Usual Software Engineer

よくあるソフトウェアエンジニアのブログ

ここ一年の振り返り

先月、僕が開発のマネージャーを努めていたサービスがクローズになりました。 こんなに無力さを感じたことがあったでしょうか。 ただ、得られたことや感じたことは大きいので 最後の振り返りとして書き留めようと思います。

立ち上げ

思い切った新規開発でリリースまで辿り着けずにプロトタイプの段階で打ち止めになったプロジェクトから 一転して既存のリソースを流用して内製の開発チームをつくることになり 初めて採用の面接官側をやりました。 採用面接と一口に言っても、考慮しなければいけないことは多方面に渡っていて 結局はバランスをとって何を重視するか判断して決めることになりますが 非常に重要であり難しい問題です。良さそうと感じた人がうまくハマらなかったり、 おとなしそうだなと思っていた人がバリバリ仕事できたり。

ただ、少なくとも現場の人間と面接するのは必須だなと。 社風に合うかも大事なんだろうけれど、所属する予定のチームの複数メンバーと面接することが 一番お互いのミスマッチが減らせるし早くフィットできると思います。 脱線ですが採用だけじゃなくて異動も同じようなフローにして、 各チームがオープンに"バンドメンバー募集!"みたいな空気になったらいいのにと思います。

イテレーション

そんなわけでチームメンバーを少しずつ採用していったわけですが チームマネージメントどうしよう?という話になり その瞬間、テックに理解のないディレクターがプロジェクトを炎上させる光景がコンマ2秒で目に浮かび その後2秒くらい考えて「俺がスクラムでやってやる!!!」って気持ちになってました。 もともと開発の周りのこともエンジニアリングしたいと思ってはいたので ただリーダーの経験もスクラムの経験も無かったので技術本やwebサイトやアジャイルラジオや先輩から必死に学びました。 社内にもスクラムの説明会を5回ぐらいやったでしょうか。 まだチームメンバーが4人ぐらいのころから1週間を1イテレーションとして始めました。

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

スクラムをすべて体現できていたかどうかは正直怪しいですが チームは組織としてペースを保って開発を続けられましたし 職種はプランナー・デザイナー・アニメーション・エンジニアといて15人になりましたが 僕の今までの経験では一番組織力は高かったかなと感じています。 とかいうのをマネージメント層が言っても説得力ゼロなんですが 幾人かのメンバーは過去の多くの経験の中でも1,2を争うぐらい チームの体制や開発のスムーズさを評価していたので マネージメントの面白さとか報われるところはこの言葉に尽きるなと思いました。涙。 ま、エンジニアの方が楽しいけどww

過去のエントリとかでいちチームにいちスクラムマスターが必要みたいなことを書いていましたが 僕が言いたかったあのポジションはTechnical Program Managerと言うらしく GoogleTwitterはそういったポジションが確立しているようです。しっくりきました。

ゲーム開発

今度はチームではなくモノの話になりますが、iOS/Androidスマホネイティブアプリのゲームを初めて開発し 当然ですがクライアント側に重要なプログラムがあるので、アプリのバージョニングやダウンロードリソース、 リリースサイクルなどが今まで作っていたwebアプリケーションとは大きく違うので その辺りは知識と経験が広がって良い感じでした。

ただそれ以上に、スマホゲーム市場のレッドオーシャンっぷりを半端無く感じて プロダクトオーナーの目線やプロジェクトのお金の話などエンジニア以外の部分も大きな経験になりました。 やっぱり、言われたものを作ってるだけの人はエンジニアとは言えない。 自分がいちエンジニアの立場に戻ってもプロダクトに対する多角的な視点は持ち続けたいです。 ゲームだと自分がユーザになり得やすいので雑多な意見も多くなるし自分の意見が通らないことも多いだろうけれど 結果的にユーザにとってプロダクトにとって良いものにしたいという部分が皆ぶれていなければ どんなにぶつかっても最終うまくいくんじゃないかなと思っている次第です。

チームとリーダー

予定のリリース日が近くなるとだいたい炎上し始めますよね。 見積もりなんてだいたい正確なことはないんで。 ただしプロジェクトとしてはどうしてもムチを打って頑張らざるを得ないこともあるので うまくやってるつもりでもやっぱりしわ寄せはきてしまいます。

で、別に炎上の話をしたかったわけではなくてですね、こういったケースが他にもあるんですよね。 なんかわからないけれどいつの間にかチームのモチベーションが下がっていたり この前までうまくいっていたのに急に進捗が悪くなったり。 これはいかんと長い時間をかけて取り入れてみた仕組みも、一瞬にして跳ね返され何も無かったことのようになる。 嗚呼、コミュニケーションって難しい。マネージメントなんて無くなってしまえ。おのおの自己管理すればいい。 とかって自暴自棄になりかけるのですが、実は答えは出ていたりするんですよね。 対面のコミュニケーションが重要だということ。モチベーションが下がっていたら直接聞けば良い。 1対1の定期面談の重要性がようやくわかりました。

あとよくあったのは、チームでこういう問題があるんだけどこの解決策はどうかなー微妙かなーとか 考えているうちに日々の業務で時間が経っていてチームの問題が顕著化してしまうパターン。 これもいっそチームにその解決策がどうか投げかけてみれば良いだけの話だったりするんです。 1人の把握できる能力は限られているのですから、対応のスピードの方が重要な時はありますし、 問題が大きくなる前に見抜けるのはマネージメントの役割ならではだと思います。 ちょっと話はずれますが、コミュニケーションが大事だからといって 口のうまいひととか社交的な人がリーダーに相応しいとは全く思わないです。 このTED Talkとか面白いので良ければどうぞ。

www.ted.com

www.lifehacker.jp

それぞれ良いリーダー像はあると思うので一概にこれが良いとかはないと思いますが、 僕としてはフラットであることと支えることが重要かなと思っています。 導くというのは、前に立って引っ張るだけではなくて、背中を押してあげたり脚力をアップさせたりすることでもあると思います。 フラットに関しては、贔屓とか媚びとか嫉妬とかうっとうしいからですね(笑)自分の手柄とかどうでもいいんです(笑) それで最初は冷たいとか思われちゃうんですけどね。冷たさも温かさも必要なわけですよ。

さいごに

開発がスムーズにいっていたとか、チームがちゃんと組織として機能していたとか そういったことを書いたわりに結果としてこのプロジェクトは成果を出せず クローズとなってしまいました。 余談ですが、言われるまで気づかなかったけれど、自分への誕生日おめでとうコメントに対して リリースしたアプリの宣伝をスパムのように全員に返信してたのは たしかに本気だったからだよなと後から認識しました。 もはや悔しいとかの次元じゃなくて完全に負けた、 他人のせいじゃなくて自分自身でものすごく感じています。 本当に力が足りなかったのだなと。

ただ、こう書くとずるい気もしてしまいますが 大した経験もないのに技術責任者として迎えていただいて ベンチャーとしては重要な最初のプロジェクトの開発を主として 自由に思うように経験させてくださった取締役のお二人に本当に感謝しています。 もちろん社内メンバーや社外の方々にもお詫びと感謝。 プロジェクトが上手くいかなかったのは本当に無念です。。

深夜の走り書きなのでなんかふわふわしてます。 次のタイトル、フラットに面白いので成功を願っています。

スクラムのプロジェクトを終えた後に読んだ良本。よくまとまっています)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)