ロックマン謎かけで始まった #JBUG広島ではデザイナーと開発が業務を進める上で行った改革をご紹介します！ #JBUG

by Tanny

2021年6月21日

イベント

世界中のBacklogユーザーのみなさま、こんにちは！コミュニティマネージャーのTanny（タニー）こと、谷山鐘喜（たにやましょうき）です！

BacklogのユーザーグループであるJBUGが先日広島で開催したオンライン勉強会についてレポートします。

オープニング

いつも新しい試みで楽しませて頂いているJBUG広島ですが、今回はロックマン謎かけで始まりました！
「プロジェクトマネジメントとかけましてロックマンととく。その心は、どちらも最後は勘（缶）が重要です」

オープニングで謎かけする中道さん

それではJBUG広島#8スタート！

セッション1：株式会社フォノグラム田中さんによる「中小規模のウェブ制作で、デザイナーとしてやっていること」

週3日でフォノグラムさんで働きながらフリーとしても活動されている田中さん。今回はデザイナーとして下記のように普段から心がけている事を話して頂きました。

企画や相談の段階で簡易ワイヤーフレームを作る
パーツとスタイルを1つのアートボードに集約する
Adobe XDの共同編集とCCライブラリに一元化する

なぜこのような取り組みを行なっているかは下記の通りです。

関係者同士のイメージがずれたまま話が進むのを防ぐ為
マウスオーバーした時やアコーディオンの仕様、余白などを正確に伝える為
自身のデザインデータが同期されそのまま共有でき無駄な手間が省け、事故のリスクも防げる為

また、細かいパーツごとに先にデザインを決めて、それぞれを作ってから組み立てるように制作する事はなかなかできません。それは各パーツを作り全体のトンマナを見ながら都度バランスを整えていくという作業が必要だからです。

Tanny’s eye

1 簡易ワイヤーフレームで大切なのは丁寧に書く事ではなく、認識齟齬を生まない事です。関係者同士のイメージが最初から完全に一致しているという事はほぼあり得ません。
会議中にホワイトボードに図やイラストを描きながら話を進める事はあると思いますがそれと同じだと思います。
これをデザイナーさんに積極的にやって頂けるのはとてもありがたい事だと思いました。

2 パーツなどのスタイルガイドが用意されているのは実装者（エンジニア）にとってはとても仕事が進め易いと思います。
実装する時に具体的な依頼がないという事は都度確認が必要になり、その度に作業の手を止める必要があるからです。
そうなれば作業効率が落ちるだけではなく、実装者のストレスにもなりますし、不満が募れば人間関係にも影響を及ぼし兼ねないからです。

3 この取り組みはファイルや更新頻度の増加に伴う管理コストの軽減と先祖返りなどのリスクを防ぐ為には明らかに必要不可欠であり、今の状況を共有するという余計なコミュニケーションも省ける為作業に集中できるというメリットもあると思います。

このようにデザイナーさんの意識が高いおかげで助かるディレクターは多いのではないかなぁと思いました。
そんな田中さんが勤める株式会社フォノグラムが提供する指示ツールAUNもとても便利なのでぜひ使ってみてください。

田中さんの資料

セッション2：株式会社ドリーム・アーツ矢野さんによる「インハウスデザイナーとしてのいいかも！な働き方を模索している話」

自社プロダクトや個別クラウドサービスのUIデザインを担当する矢野さんですが、今回はインハウスデザイナー目線で取り組んでいることをご紹介頂きました。
まず、入社当時に「なんかモヤモヤするな〜」と感じていた事を下記のように挙げました。

色々決まってから指示が降りてくる
レビュアーのデザイン観に振り回される
「なんか違う」の悲しきリテイク輪廻

なぜこのような事が起きるかの原因を下記のように分析しました。

上流で決まった事だから疑問を抱いても意見しにくい
デザインで表現するべき軸が定まっていないためブレブレ
デザインでどんな価値を届けたいのかの目線があっていない

更に分解して考えるとデザインという行為が組織の中で孤立していて案件のコンテキストを理解できていない事があります。
そこで社内プロセスにデザインを浸透させる取り組みを実施しました。

戦略フェーズや要件整理の段階から入り込む事でデザインの軸が明確になっただけではなく、ラフスケッチの段階からエンジニアに共有しておく事で、成果物に至るまでの経緯や思考の変化も同時に伝える事ができました。

結果、お互いの安心感に繋がりそれが信頼関係構築にも寄与するので効果は大きかったです。

Tanny’s eye

昔、Webデイレクターをしていた時に担当者や上席者に「いい感じに！」や「なんか違う」と言わせてしまうのはディレクターである自分自身の力量不足だ。と昔の僕は考えていました。恐らくディレクターの中にも板挟みの中で申し訳なく感じている方はいるのではないでしょうか。

矢野さんの凄い所はデザイナーでありながら当初抱えていたご自身のモヤモヤを客観的に分析した事だと思います。
また、モヤモヤしているのはデザイナーだけではないのでは？と考え、それぞれの関係者の立場に立ち、仕事の進め方やモヤモヤの原因になっている業務フローにメスを入れた事です。

結果として環境が整備された事で案件のコンテキストが理解できてデザインの軸が決まる事で振り回されないデザイン作りを実現しました。

それだけではなく、周りの方々への連携や共有も考慮されている為、上流工程に関わる方々だけではなくエンジニアを含め、全体として業務の透明性を実現できた事はとても大きな成果だったのではないでしょうか。

僕個人的にもデザイナーは上流工程に居て、最初の打ち合わせから同席した方が良いと思います。
つまり、決まった事をお任せするのではなく、最初から「一緒に決めていく」のです。

矢野さんの資料

セッション3：株式会社デジタルキューブ恩田さんによる「プロジェクト横断のBacklogを作ったら進捗・リソース管理がはかどった話」

Backlogポリスとして案件進捗やリソース管理を行っているという恩田さんにBacklogをどのように使っているかをご紹介して頂きました。

社内用とお客様用でBacklogを使い分けており、いずれもヌーラボが開発するTypetalkというビジネスチャットツールに連携させています。

また受託制作の案件が大量にある中でプロジェクトをまたいで下記のような事を実現したかったです。

各案件の進捗を一覧で管理したい
メンバーのリソースを把握したい

これらを実現する為に最初はスプレッドシートを使用していたそうですが、Backlogでプロジェクト横断専用の「PMOプロジェクト」を作成しました。
Backlogではプロジェクトをまたいで全員分のガントチャートを見る事はできないので、このプロジェクトで管理したい課題の件名やURLを貼り付け、担当者をカテゴリーで設定します。

そうする事で担当者検索をした時に参照元の課題とPMOプロジェクトで同じ課題が表示されるという事態を避けれる上に、カテゴリーで絞ってガントチャートを表示させる事で担当者ごとの案件進捗も確認できました。

Tanny’s eye

確かに複数件のプロジェクトを管理するPMの方は主要な課題を専用のプロジェクトに転記する事で全体像が見えやすくなると思いました。参照元の課題から転記する際には手間をかけない事を意識したフローにしていましたし、カテゴリーに担当者を設定するという発想も面白かったです。

そうする事でカテゴリーで絞れば、プロジェクトをまたいだ担当者ごとの案件進捗管理がガントチャートからできます。

参照元の課題と同期させる手間は多少あるかもしれませんが、「PMとして把握できていなかった」という事態を避ける事が優先的ですし、期限日を過ぎても完了になっていない課題が一目瞭然で分かるので結果的にはこの運用の方が安全で早い気がしました。

恩田さんの資料

セッション4：株式会社ガイアックス中村さんによる「フルリモートでもチームを作れる、超えられる！」

普段の業務でデータ分析基盤の構築、運用をしているという中村さんに、フルリモートにおける仕事の進め方をお話して頂きました。

3名体制のチームで社内システムの構築をしていたが次第にその運用範囲は広がり、管理コストがかかるという課題がありました。
加えてエンジニアの方々がバラバラに業務を進めていた為、属人化やチームとしての意思決定ができていないという問題がありました。

そこで下記の取り組みを実践してチームを立て直しました。

ミーティングの頻度とやり方を変えた
レトロスペクティブ（振り返り）はJamboardで
プロダクトバックログを統一した
見積もりを予想するのではなくベロシティから算出するようにした
Discordで作業通話をするようにした

結果として作業時間を増やすだけではなくプロジェクト全体に影響する意思決定ができるようになり、チームの結束力も高まりました。

またチームの垣根を越えて2日間のハッカソンを行い、チーム外のメンバーから刺激を受け、交流も深まりました。

Tanny’s eye

チームの業務の進め方に課題を感じている方はたくさんいると思います。ただ、中村さんの凄い所は根本的に運用や連携方法を見直した事です。
今までのやり方を変えるというのは取り掛かるハードルも高いですし、それらを形にするのは尚更大変だと思います。

しかし積極的に試みた事で明らかな業務改善ができましたし、更に面白いと思ったのはチーム外のメンバーとも交流を深めたいと考えた事です。

そこでハッカソンの企画と実施をしたそうですが、これらを形にする中村さんのモチベーションは素晴らしいと思いましたし、普段交流しないメンバーから刺激を受け、新たな技術に関心を持てたりと、最終的に自分自身の成長にも繋がっているのがとても良い事だと思いました。

中村さんの資料

セッション5：Retty株式会社常松さんによる「ユニコーン企業の働き方を目指して – Rettyでの2年間の取り組みをギュッと紹介」

日本最大級の実名型グルメサービスRettyで開発マネージャーを務める常松さんですが、今回はアジャイル開発の変革の取り組みについて話をして頂きました。

その際「ユニコーン企業のひみつ」という本も参考にしたようです。

入社した2年前は「プロジェクトの成長が全体の成長に結びつかない」という課題を抱えていました。具体的には下記の通りです。

仕様のずれ、タスクのお見合い
調整が増加、意思決定の遅れ
サービス全体に望ましい意思決定ができていない
自由度が低く個別に目標を追求できていない

そこで従来通り機能開発や集客、データ分析などをグループごとに個々で行うのではなく、Rettyとしてどういうユーザー価値を届けるかというプロダクト全体思考にシフトし、働き方をLeSS(Large Scale Scrum)にして全員で1つのスクラムを回す意識を持ち、必要に応じて分割させるという手法を取りました。

コロナ禍になり始まったGo To Eatキャンペーンの対応も同様の手法で進めました。

全社的に開発プロセスを見直し一元化させた事で下記のような効果がありました。

急ぎで対処しないとまずいものが無くなった
チーム開発の意識が浸透し属人化が解消に進む
複数チームに跨がる技術課題に取り組みやすくなった
開発プロセスが全体で揃い、全社の方向性を揃えやすくなった
人員が増えても開発が回るイメージが持てる

このようにLeSSの導入により、開発に関する恒常的な悩みが減り、本質的な課題に取り組めるようになりました。

Tanny’s eye

入社当初各グループが別々にプロジェクトを進めていた状態に違和感を持った常松さんが前述した課題に気づけたのがターニングポイントだと思いました。
各々がプロジェクトを進めるのは自由に動けているようで調整の手間が増えたり全体の意思決定がしにくいという事態になりがちです。

故に実質的に不自由になってしまう事はどこの現場でもありがちな事かと思います。

そしてもっと大切な事は調整や業務の進め方云々ではなく「プロダクトとしてユーザーにどのような価値を届けるべきか」という観点に立ち返った事だと思います。

組織編成をしたり、業務の習慣を変えるのは大変ですがプロダクト全体思考に立ち返った事で組織としてのまとまりが良くなり機動力が高まったのだと思います。

抜本的に業務改善ができたという事実は会社にとって大きな成果だったと思いますし、関わるメンバー全員にとって意識を底上げするキッカケになったのではないでしょうか。
だからこそ急ピッチでたくさんの課題をクリアしないといけなかったGo To Eatキャンペーンの対応もワンチームで乗り越えられたのだと思います。

常松さんの資料

最後に

今回の開催に向けご尽力された、JBUG広島の中道さん、井上さん、石橋さんお忙しいところお疲れ様でした！！ありがとうございました！！
最後は恒例の記念撮影😃

記念撮影の様子

参考資料につきまして

JBUGについて

JBUG（ジェイバグ：Japan Backlog User Group）は、Backlogユーザーによるコミュニティです。現在はオフラインやオンラインでのイベント開催をメインに、Backlogの話だけに止まらず、プロジェクトマネジメント全般やチームコミュニケーション、働き方などについても意見交換を図っています。

プロジェクトマネジメントは、全ての業種/職種において必須のスキルである一方、そのノウハウが学べる場はあまり多くありません。

Backlogは国内最大級のプロジェクトマネジメントツールであり、すでに100万人を超えるユーザーがいることから、「プロジェクトマネジメント」「仕事のうまい進め方」に関する知識やテクニック、ノウハウを学び合うことをねらいとして、Backlogユーザーによって、JBUGが発足されました。

実体験から学んだ知見やノウハウのシェアを通し、より「働くを楽しくする」を実現したいと思っています。

あなたの街でもJBUGのイベントを開催しませんか？

これまで、北海道、東京、愛知、静岡、大阪、兵庫、高知、岡山、広島、福岡、宮崎、沖縄にてJBUGのイベントが開催されました。

いずれも、「イベントをやろう！」というBacklogユーザーさんが主体となり、リーダーとして話を進めてくださっています。もしあなたがBacklogユーザーで、「私の住む街でもJBUGを開催しようかな？」と思ったら、ぜひお気軽にJBUGのフォームからご連絡ください！Backlog運営メンバーの方々と一緒に、開催時期やテーマについて考えましょう！

Backlogの開発・提供のみならず、プロジェクトマネジメントのリアルなノウハウや知見を共有する場をオフライン、オンライン問わず増やしていくことにより、「働く」を楽しくしていきたいと考えています。

それでは、JBUGのイベントでBacklogユーザーのみなさまにお会いできることを楽しみにしています！