新卒が感じた仕様調整の難しさ
はじめに
オールアバウトグループの新卒1年目エンジニアが投稿する企画『テックブログ新卒週間2022』。
今回はタケウチがお送りします。
私は2021年4月に入社し、7月半ばまでオールアバウトグループ研修とアプリ開発研修を受けました。 研修後には、メディア開発1グループに所属し業務をしています。
本記事ではメディア開発1グループがどのような働き方で、私が実際にどのような業務に取り組んできたのかを紹介します。また振り返りを兼ねてチームで業務を進めるにあたって難しさを感じた他部署、他グループとの仕様の調整について紹介していきます。
どんな業務をしているか
私の所属するグループでは、All About、All About Newsという2つのメディア運営に関するシステムの開発・保守をしています。
具体的なシステムの開発・保守としては以下が挙げられます。
- ユーザーが記事閲覧しやすいようにメディアのデザインや機能の改善
- All Aboutの記事を他社のニュースプラットフォームへ提供・配信する機能の開発
- 記事入稿システムの機能改善（記事入稿の補助機能など）
業務の進め方
業務の進め方としてはスクラムを採用しており、1スプリントの期間は1週間です。この期間で開発を進めています。
※スクラムとは
スプリントは毎週木曜日に始まります。
木曜日にメディアを担当する企画チーム、編集部との定例で開発する機能や施策の優先順位を決めます。それからスプリントプランニングを行い、スプリントで実施する施策を決めます。そしてスプリントでやる内容を企画チーム、記事制作チームに確認してもらい、合意を得ます。
金曜日から水曜日で施策や機能の開発に取り組みます。
そして次のスプリントの初日である木曜日に、前回のスプリントで開発した施策や機能を企画チーム、編集部に向けてデモをしてレビューをしてもらいます。 その後に開発する機能や施策の優先順位を決めるといったサイクルでスプリントを回していきます。
また業務の特性上、エンジニアだけで完結する業務はほとんどなく、企画チームや編集部とコミュニケーションを取りながら仕様や開発のゴールを決めていきます。
その仕様決めのコミュニケーションがうまくいかず、スプリントに遅れが生じ、苦労したケースが何度かあります。次にそこを掘り下げます。
苦労した仕様決め
メディア開発1グループでは、プロジェクト管理ツール「Backlog」を用いてタスクを管理しています。定例ではBacklogを企画チームや編集部と確認し、開発の要件やゴールを記載していきます。
開発を進めていくにあたって新たな考慮点が発生することがあるのでその都度、仕様を決めていきます。
最も仕様決めに時間のかかっていた、メディア開発1グループに所属して数ヶ月間のコミュニケーションを振り返ってみると、簡単なタスクにも関わらず仕様を決めるのに数日かかっていました。また先輩の助け無しでは仕様漏れも現在より頻繁に起こっていました。
チームメンバーからの指摘もあり、以下が課題になっていると考えました。
- 文章を長く書いてしまって読みづらく、相手に意見を伝えるのに時間がかかる
- 仕様をどうするか全て質問してしまっている
1. 文章を長く書いてしまって読みづらく、相手に意見を伝えるのに時間がかかる
文章が読みづらいことが原因でコミュニケーションのラリーが何度も発生していました。そのため自分の時間だけではなく、返信している関係者の時間まで無駄に消費してしまう状態になっていました。
オールアバウトには『ななメンター』という制度があり、新卒に自分の所属するグループ以外の先輩がメンターとしてつきます。そのななメンターでのランチの際に先輩にコミュニケーションの取り方について相談しました。
ななメンターからは文章力についての本(『メール文章力の基本 大切だけど、だれも教えてくれない77のルール』)を紹介してもらいました。
本から得た文章を書く際の以下のテクニックを特に意識するようになりました。
- 文章ではなく箇条書きを原則とする
- 曖昧な表現を使用しない
- 主語、主体を明確にする
- 本文で説明するか、添付ファイルで説明するかを検討する
上記を意識して、社内のslackの文章で改善できる箇所を見つけて修正していくことで、本から得た学びをアウトプットしていきました。
そして、修正した文章をななメンターとのランチ会でレビューをしてもらいました。
また先輩方の文章などを参考にして徐々に改善していきました。
2. 仕様をどうするか全て質問してしまっている
質問相手に仕様を任せていることも同じくコミュニケーションが何度も発生する原因でした。
企画チームや編集部は仕様を全て把握しているわけでは当然ないので、質問されてからどうするかを考える時間が発生します。
また仕様によって開発の工数も変わるので、企画チームや編集部は容易に決めることができません。
例えば、『記事の更新日を記事の上部に表示したい』という施策があったとします。
これまでは以下のように企画チームに質問していました。
PC版の記事更新日の表示位置を変更する施策について質問があります。
具体的に記事のどの箇所に追加したらよろしいでしょうか？
これでは企画チーム側でどの箇所に表示をしたいかを0から考える必要があります。
そのため質問として相手側に丸投げするのではなく、こちらから案を出すように意識的に変えていきました。
PC版の記事更新日の表示位置を変更する施策について相談があります。
記事更新日をどの箇所に表示しましょうか？
記事更新日の表示位置についてPC版のモックを3案作成しました。
スプレッドシートに記載しております。
どの案が良いか、もしくは他の表示位置を検討する必要があるかをご意見いただきたいです。
上記のように相談することで、相談される側もどう返事をするかを考えやすくなりますし、仕様のすり合わせにかかるコミュニケーションの量も以前より減らすことができました。
終わりに
メディア開発1グループに所属した自分がどのように業務をしているのか、苦労した仕様決めのコミュニケーションをどう改善していったのかを紹介しました。
開発が思うように進まなかったり、仕様をなかなか整理できなかったりとうまくいかないことが多い新卒の1年間でした。
しかし、このブログを書くにあたり過去のslackでのコミュニケーションや資料、プルリクエストなどを振り返ると成長していることは感じられました。
今後も開発の力とコミュニケーション力を鍛えて、出来ることを着実に増やし、仕事を楽しく進めていきたいと思います。
