これは Supership Advent Calendar 2018 5日目です。
##今回書くこと
開発ド素人の自分がいきなりスクラム開発の現場に入って3ヶ月経ってわかってきた・感じていることをつらつらと書いていきます。
###私のバックボーン
・運用型広告
・事業戦略
・プロダクトマーケティング
ここらへんの業務をやってきました。プロダクトマーケティングのときにエンジニアと会話することはあるものの開発現場に入るとまではいかない程度でした。
####こんな経歴なので…
開発現場全般の常識なのか、スクラム開発だからなのか、今のプロジェクトだからこそのことなのかがわからずに書いていますのであしからず。
##やってるスクラム開発の大枠
9月頃からプロジェクトが進み始め、本格始動したのが10月から。
###12月時点での体制
自分
+自社PO兼SM1人
+自社エンジニア2人
+協力会社SM1人
+協力会社エンジニア/デザイナ5人くらい
→合計10人弱程度でプロジェクトを進めています。
###会議体など
・スプリントの単位は2週間
・デイリースクラム：毎日15分
・デイリーリファインメント：毎日1時間
・補完リファインメント：週3~6時間
・スプリントレビュー：隔週2時間
・レトロスペクティブ：隔週1時間
・スプリントプランニング：隔週4時間
##これまでの働き方や想像とのギャップ
###ミーティングに費やす時間が多い！！
ミーティングが多いというのはネガティブに受け止められることが多いですが、ここではネガティブな意味は含みません。
今までの業務はプロジェクト毎に多くても週に2~3時間ほどしかミーティングをする機会はなかったのですが、今は5~10時間ほどは週にミーティングを割いています。実際にやってみると本当に顔を合わせて会話する時間が多い！もちろんそれとは別にSlackでの会話も随時行われています。
###実際にコードを書いている時間が想像以上に少ない！！
これは私の勝手な思い込みなのですが、開発現場においてはもっとコードを書く時間に埋め尽くされているのだと思いこんでいました。しかし、実際は設計や要件定義をするために費やす時間が非常に多く、想像していたものとは大きなギャップがありました。
###プロジェクト進行の手法がものすごく発達している！！
いままで関わってきた業務ではプロジェクト進行などの手法がそこまで確立されていませんでした。
いつどんな仕事をするのか？そのプロジェクト管理はどのようにしていく？のような当たり前なことも属人化していたり0から考えていくケースが多々あったのですが、開発においてはプロジェクト管理の手法が発達しているためプロジェクト進行の体制構築が非常にやりやすいと感じました。
裏を返せばそれほどまでにプロジェクト管理が明暗をわけるということですね。
##開発現場/スクラム開発における良いところ
###アウトプットがすぐに目に見えるのでモチベーションが保ちやすい！
飽きっぽい性格の自分にとってはすごく大きなメリットでした。今から始めて半年後にやっと目に見えるものができるようなプロジェクトであれば中だるみをしてしまいがちかもしれませんが、スクラムの場合は早いケースだと数週間で実際に触れるアウトプットが出てくるためモチベーションが維持しやすいです。
###会話による気づきが多い！！
自分だけで考えているだけだとどうしても限界がありますがメンバーと話しているとどんどん新しい課題点やアイデアが出てきます。特に要件定義やユースケースを想定した改善案などは複数人で話すことにより格段にクオリティが上がります。
###周りの知識をものすごく吸収できる！！
個人的に一番ありがたいメリットです。
開発素人の自分でもこれだけの量の会話していると自然と知識がついてきます。もちろん会話についていけるように自主的な勉強もしているのですが、実践に勝るものはなし。
周囲のメンバーのおかげでわずか3ヶ月ながら理解が深まってきました。
##スクラム導入にあたってのポイント
###ミーティングのアジェンダをきっちり作る！
当たり前のことですがスクラム開発においては特に大事。デイリーリファインメントなどは毎日やらなければいけないので少し油断すると何を決めなきゃいけないのか？何について話し合わなければいけないのかを会議までに準備できない可能性もあります。しかし、開発メンバーの貴重な時間を(しかも数人！)使って行うものなので、段取りが命です！ここをぬかると生産性が急に落ちてしまいます。
###ミーティングで集まる時間を作る！！
スクラムだとある程度見切り発車で開発を進め、課題やズレを並行して超短期間で修正していくスタイルなので認識を合わせたり合意形成をする時間が取れなかったりすると途端にプロジェクトが進まなくなります。責任者が捕まりづらかったりすると難しい運用方法だなと実感することもあり…プロダクトオーナーが兼務で多忙だったりすると危険信号かもしれません。
###ドキュメント管理を徹底する！！
ミーティング内での決定事項や要件定義のマスタなどのドキュメントがどうしても増えてしまいがちなため、管理を徹底しないと各ドキュメントの整合性にズレが発生してしまいます。そうなると作業が止まり、確認のために行ったり来たりで時間が過ぎていってしまいます。
そしてドキュメント管理が崩壊すると混乱を極めるであろうことが容易に想像できます。
###巻き込むことを恐れない！！
エンジニアにはできるだけ作業に集中してもらうためにミーティングなどに巻き込むことをできるだけ避けようとか考えちゃったりするのですが、そうやって進めたときには後から抜け漏れがあったりし、かえって時間がかかったりしてしまうこともあります。
そのため、結局は変な気を使わずに最初からエンジニアに入ってもらってたほうが効率的だったりするんじゃないかと思います。（そして呼ぶからにはミーティングのアジェンダなどをきっちり用意しておく！）
###能動的に参加するマインド！！
ミーティングに費やす時間が多い分、各個人のマインドが大事になってきます。
ミーティング中に発言がなかったりするようであれば出席してもらっている意味がありません。そして、ミーティングに費やす時間が多いので能動的な参加がないようであれば作業してたほうが良いよね、となります。
これは開発現場に限った話ではないですが、煩雑でドキュメントだけでの理解が困難なものでもない限り単純な情報の共有はドキュメントベースで行い、せっかくのミーティングの場は全員がディスカッションに費やすことができるように準備し、各個人がディスカッションに能動的に取り組むことを心がける必要があります。
###やっぱり妄想力って大事…
あれやったらどうなるんだろう、これしたら何が起きるんだろう、という妄想(想像)をしてどれだけ先読みできるかがという力は開発でもそれ以外の業務でもプロジェクトをリードしていくには必要な不可欠な力でした。
そして技術的な目線・エンドユーザー目線・ビジネス目線でプロジェクトを見ながら想像できる人がいるとバランス良く進められるのかなと思います。もちろん、一人ですべての目線で見れる人は超レアなのでそれぞれを理解しているメンバーがいさえすれば、あとはプロジェクトを進めていく過程でバランス良く取り入れていくだけです。
##これから頑張らなきゃいけないであろうこと
###メンバーが増えたときの生産性の維持
いまはまだそこまでプロジェクトメンバーが多くない状態ですが、これから増員していったときにその分しっかり生産性を保つことにひとつ壁があるだろうと予想しています。
人数が増えることによりコミュニケーションラインも増えてその分生産性が落ちる可能性が高いでしょう。また、属人化することにより増員が困難になるはずなので、属人化させずに開発スピードを保つ。これを意識していきたいと考えています。
###プロダクトが使われている現場の意見を拾うこと
プロダクトがロンチされクライアントに使われるようになったときには実際の使用感などを実際に使っていただいているクライアントの現場の方に直接声をもらいに行く活動が必要になります。
プロダクトをスケールさせるためにプロジェクト体制は大きくなり管理工数が増加する反面、利用していただいている現場からの声を拾いプロダクトに反映していく。このサイクルを回すことも近い未来に訪れるであろう壁のひとつだと考えています。
##最後に…
企画系の業務をやっているときには開発サイドとのミーティングなどもしていましたが、実際に開発現場に入ってみると見えてくる景色は全然違いました。
これは開発サイドとビジネスサイド、どちらにも言えることですが両サイドにはそれぞれの価値観や習慣、手法、常識が存在しているのでお互いの"向こう側の世界"を想像すること、尊重しながらコミュニケーションすることを意識するとより良い仕事ができるのではないかと思いました。