見出し画像

参加リポート 【オンライン】JBUG広島#8 広島でWorldのおかわりじゃ！

たかく しゅういち

Backlog World 2021の運営で大活躍だった、ナカミチさんたちJBUG広島のメンバーが再起動しました。Backlog World 2021でも講演されたRettyの常松さんの講演をメインにリポートします。

中小規模のウェブ制作で、デザイナーとしてやっていること

講演者：Tantan/田中 由花さん(フリーランス・株式会社フォノグラム)

Adobe XDユーザグループ運営メンバーの1人

今回の講演の3つのポイント

①簡易ワイヤーフレーム

②パーツとスタイルを1つのアートボードに集約

③デザインデータをクラウドで管理する

の3点です。

・簡易ワイヤーフレーム

リモートワークなので、ホワイトボードは使えない。そこでワイヤーフレームをネットで共有し、デザイナー同士が情報を共有する。

サクッとデザインのアウトラインを決めることができるのがメリット

・パーツとスタイルを1つのアートボードに集約

①メインのページのデザインが落ち着いたタイミングでパーツとスタイルを1つのアートボードに集約して、エンジニアさん・クライアントさんに観てもらうことで、手戻りを防ぐ。

ホバーした時

メニューが表示されたとき

文字のデザインと大きさ

ボタンやアニメーションの動作

を説明コメントも添えて、チェック用にする。

②なぜ、細かいデザインを作る前にパーツをつくるのか？

↓

例えば、コーポレートサイトで企業のビジョンを伝えたいとき、全体のバランスが表現に大きな意味を持つ。そこで、すべてのパーツを俯瞰することに大きな意味があるから。

パーツ集の整理には十分なスケジュールの確保が必要

・デザインデータをクラウドで管理する

①Adobe XD のCCライブラリ上で共同編集する

   →1つのページが常に最新の状態を皆が共有できる

②CCライブラリを使うと部品を手動でアップロードせずに、最新の状態にできる。

感想

・共同作業において、特定の人だけが情報を握らずにすむこと、自動的に最新の情報(データ)をメンバーが共有できるのが、優れものだと思いました。

インハウスデザイナーとしての「いいかも！」な働き方を模索している話

講演者：矢野 絢香さん（株式会社ドリーム・アーツ）

・世間のイメージは悪い：ダサい、辛い、レベル低いなど

・矢野さん、「辛い！ もとい モヤモヤ」が「いいかも！」になるための取り組みを紹介したい。

・インハウスデザイナーあるある

  ①いろいろ決まってから指示が降りてくる

  ②レビュアーのデザイン観に振り回される

  ③「なんか違う」の悲しきリテイク輪廻

デザイナーチームができて、この状況を解消するため、ミーティングを重ねた。

まず分析

・デザインという行為が矮小化・孤立している

  →表層のみに局所的に関わるためコンテキストを理解できていない

そこで、

「例えアウトプットがビジュアルのみでも、結局各フローにお邪魔させてもらったいた方がカスタマジャーニーに寄り添える！結果良いアウトプットを出しやすい！」という考えに至る。

しかし、

具体的な数字を示せずに、いきなり上流工程などに参画するのは難しい。

そこで、

お互い「いいかも！」な世界を目指して、社内のプロセスにデザインを浸透させる取り組みをじわじわ提案&実施している

次は実践した話

・戦略を立てる段階にお邪魔しつつ、ジャーニーなどを用いながら出てくる情報を言語化。第三者目線で課題提起

  →ビジネス的な目標も把握的できて、デザインの軸が明確に！

・戦略が決まったら、プロジェクトに関わるメンバー（個別開発の場合はお客さまも含めて）全員の認識がずれないように可視化。（ストーリーボードを用いる）

  →デザインも大枠からずれないよう意識できるからハッピー！

・ワイヤー作りに移る準備としてペルソナごとに要件を整理してみたり、簡易的な画面遷移図を作ってみたりしてメンバーとイメージの具体度を上げて行く。

  →頭の整理にも繋がって、検討の抜け漏れが発見しやすい！

・ラフスケッチからエンジニアさんと制作データを見ながら一緒に体験設計&修正を重ねていく（Adobe XDを用い、CCライブラリでデータを共有）。没データも残す。

  →この期間のコミュニケーションが密なのはメリットがたくさん！！

・デザイナーから情報発信して身近に感じる&興味を持ってもらう

 です！！

・デザイナーチームとしては、次の3点を心がけています。

  ①機会を見つけたらトライ&エラー

  ②”デザイン”が鼻につかないようにふんわりと

  ③表現力を研鑽し続ける

感想

・デザインもプログラミング（業務システムでの）も上流工程から参画でくるのは、大事だと思います。

おまけ

ドリーム・アーツさんの

Twitter

note

です。有益な情報がてんこ盛りです！！

プロジェクト横断のBacklogを作ったら進捗・リリース管理がはかどった話

講演者：恩田 淳子さん（株式会社デジタルキューブ）

恩田さんのミッション

それは、Backlog ポリス👮

①すべての受託制作案件の進捗管理

②受託制作メンバーのリソース管理

③品質・コミュニケーション管理

デジタルキューブさん

お客さまのWebサイトの保守も仕事にしている

そのため、Backlogのプロジェクトがドンドン増えている

ちなみに、おのおののBacklogプロジェクトは、Typetalkで連携し、チャットでエンジニアさん・デザイナーさんが情報連携している。

そんな中で、恩田さんがやりたかったこと

①プロジェクトをまたいで各案件の進捗を一覧で管理したい

②プロジェクトをまたいでリソースを把握したい

↓

スプレッドシートを使ったが限界を感じ、プロジェクト横断の「PMOプロジェクト」を作成

理由：

①Backlogは、個別ではガントチャートを見ることができるが横断で見ることができないため、

②Backlogは、フィルタ機能を使えば、人ごとに担当しているタスクが見られるが「今後いつ何のタスクが入ってくるか」という先々のスケジュール感を見るには適さなかったため

では、実際の恩田さんの仕事です。

課題サンプル

connpassのイベント資料のページの恩田さんのスライドの10ページ目をみてください。（画像貼り付けけど小さすぎ、noteの仕様みたいです。）

実例

会社の業務に関わる可能性もあるので、省略します。

課題管理の流れ

①各プロジェクトでタスクが発生したらPMOプロジェクトに課題を登録

②案件が進行したらそれぞれのステータスを変更

③PMOプロジェクトのガントチャートとボードを見ながら週2～3の頻度で元課題の進捗を確認

④元の課題が完了したらPMOプロジェクトに起票した課題も完了に

良かった点

①プロジェクトをまたいで、各案件の進行状況が一覧で把握・管理できるようになったこと

②プロジェクトをまたいで、誰がいま何を担当しているのか、今後いつどの案件を担当する予定があるのか可視化できるようになったこと

③開発担当のアサインが完了した上で、お客さまにスケジュールを提示できるようになったこと

お悩み

手動運用

→課題の新規追加と完了がわかるようにメールをフィルタリング

  試行錯誤中

恩田さんにとってのBacklog

・約束（タスク）を守るためのツール

・そこで、遅延しそうなら誰でも容赦なく突っ込むし、リスケして立て直す

Backlogポリス👮

・取り締まりは手段

・目的は、市民（顧客・メンバー）の安全を守ること

感想

「担当者」をカテゴリーにして管理する発想、ナイスです！！

フルリモートでもチームを作れる、超えられる！

講演者：中村 優さん（株式会社ガイアックス）

講演要旨：フルリモートワークで、

①スクラム実践を通じてチームを立て直した話

②チームを超えた交流施策として社内ハッカソンをやってみた話

・スクラム実践を通じてチームを立て直した話

  ①エッセンシャルスクラム

  ②アジャイルな見積もりと計画づくり

  ③ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介 - Yahoo!Japan Tech Blog

をベースに勉強し、チームの立て直しにトライした。

属人的になっていたチームの体制を機能的なものに変化させた。

結果的に、プロジェクト全体に影響する意思決定ができるようになった。

チームで仕事を進めている感覚が強くなった。

・チームを超えた交流施策として社内ハッカソンをやってみた話

  特徴

  ①チーム毎にボイスチャンネルを立てた。

  ②参加者の属性がバラけるように声かけした。

  ③審査や賞を設けなかった。

結果、オンラインでも「お祭り感」をしっかり味わえた！！

感想

現在、入社3年目の若手エンジニアがフルリモートワークでここまでチームの立て直しやチーム間の交流に関われたのはスゴいと思います。今後も、研鑽を積んで、成長していってください。

ユニコーン企業の働き方を目指して - Rettyでの2年間の取り組みをギュッと紹介

講演者：常松 祐一さん （Retty株式会社）

常松さんの講演の柱となるのは、この本にあるSpotifyの取り組みでした。

Spotifyは、ニューヨークに上場する規模の企業となりましたが、スタートアップだった時代の俊敏でアジャイルな組織体制を維持しています。そのための企業文化の変革をまとめたのが上記の書籍です。

この本にあるように、常松さんはRettyの企業文化の変革に取り組んできました。

しかし、文化の変革はすぐに効果の出るものではありません。複利で効いてくるものです。

そこで、常松さんは、

1チームのスクラムの体制を見直す

↓

2チームで同じテーマ（プロダクト）に取り組む

↓

LeSSの導入（3チーム 15,6人）

と徐々にスケールアップを行いました。

・では、常松さんが入社した2年前のRettyを振り返ってみましょう。

目標（理想）

・プロジェクトに権限と自由を与え、個別に目標を追求する

現実

・仕様のずれ、タスクのお見合いが発生

・調整が増加、意思決定の遅れ

・サービス全体に望ましい意思決定ができない

・結果として、かえって自由度が低い

という状況でした。

しかし、社外はRetty全体を1つのサービスと捉えます。

そこで、プロダクト全体思考へのシフトを試みます。

しかし、プロダクト全体へ全員が焦点を当てるように仕向けることが、スクラムをスケーリングするに当たって最も難しい課題の一つになります。

しかし、やらなければなりません。そこで、システム思考を適用しLeSS(Large Scale Scrum)をスタートさせます。

・プロダクトとしてベストな意思決定を行う

・優先順位・最終責任の明確化

・オーバーラップして協力を促す

ため、

次のような体制にシフトしました。

①プロジェクトやデバイス、機能別の改善ではなく、プロダクトとしてどうユーザー価値を実現するべきかを改めて意識する

②取り組むことを1つにまとめ、Rettyというプロダクト全体としてベストな意思決定を行って行く

です。

LeSSの場合、

代表者と何人かの意思決定者でその時の状況に応じて、やるべきことをきめます。

開発チームは、1つのプロダクトや機能に固執せず、フレキシブルにその時の課題に取り組みます。

RettyのLeSS導入については、以下に詳しい情報があります。ご一読ください！！

常松さんのまとめ

・チーム間の調整が増え、開発が全体の優先順位ではなく、調整に左右される課題が出た。そこで、バックログを一つにまとめるべきと考え、LeSSを知って導入した。

・「開発スピードが目に見えて落ちている」ことが大きな経営課題だったので、導入はすんなり進んだ。

・とはいえ完璧なLeSSではなく、試行錯誤しながら適用範囲を広げている。

でした。

Go To Eat をLeSSで乗り切る

次のテーマは「Go To Eat」キャンペーンです。

詳細はこちらをご一読ください。


・プロジェクト規模はというと

①携わったエンジニア数：26名

②開発期間：3～4ヶ月

③開発項目：[BtoB]、[BtoC]ともとにかく多岐にわたる

状況でした。

これを

・バックログをすべてGo To Eatキャンペーン関連のものに差し替え

・全体設計・仕様整理を行った後、各チームが優先順位に従って粛々と実装を進めた。

・toBの開発項目が多かったが、toCチームに管理画面の構築など難易度の低いものをとってもらい負荷を調整、

・フィーチャーフラグで表示を塞ぎ、スプリントごとのリリースを続けた。全部揃ったところで検証し、2020/10/1に時限式にフラグを外し

乗り切りました。

常松さんのGo To Eatまとめ

・「LeSS導入を進めていなければGo To Eatキャンペーン開発は乗り越えられなかっただろう」という社内評価

・toCとtoBのWeb開発で交流が進んだ

・リリース後に問い合わせが増えたり、負荷が高まったり、キャンペーンが想定より早く終了することがあったが、バックログの優先順位を見直すだけで対応できた。

LeSS導入による効果

・開発に関する恒常的な悩みが減った。0になったわけではないが、急ぎ対処しないとまずいものが無くなった。

・チーム開発の意識が浸透し、属人化が解消に進む。

・複数チームに跨がる技術課題に取り組みやすくなった。

・開発プロセスが全体で揃い、優先順位の上げ下げのみで全社の方向性を揃えやすくなった。

・人員が増えても開発が回るイメージが持てている

そして、一歩進んで、

「なぜ？」に向き合える組織

を目指します。

きっかけは、

見積もり(リファインメント)がうまくできない問題

です。

PM内で、工数見積もりしてもらうことが目的化し、開発物が洗練されていない中で見積もりを依頼されるエンジニアとPMが険悪なムードに･････｡

それを解消したプロセスが上記のスライドです。

有形なP(プロジェクト)ではなく、無形なP(プロダクト)を意識した

PM(プロダクト・マネージャー)にシフトすることを目指しました。

そして、「なぜ？」に向き合える組織へのシフトを目指しました。

そこで、

・リファインメントの仕組みを変更しました。

    ・「相談のみ」が宣言できるようルール化

    ・リファインメントの目的をこまめに周知・説明

・企画部門のスキル向上のために

    ・施策の壁打ち会を定期開催

    ・「プロダクトマネジメント」本の読書会開催

    ・スキル定義、評価制度の整備

を行いました。

しかし、常松さんの組織に対する自己評価は辛口です。

『アウトカム主導組織への道はまだ半ば』と評価しています。

常松さんの評価は以下のものです。

・何をやったか（アウトプット）ではなく、何を達成できたか（アウトカム）を軸に考える

    ・毎週の開発ゴールをアウトカムで記載

    ・毎週の全社会議で学んだこと・アウトカムを共有

    ・毎週開催する開発デモの後にディスカッション時間を設定

していますが、

・企画・デザイン・開発は少しずつ根付いてきたが、全社（総務・営業含む）となると、まだまだこれから。

と常松さんは評価しています。

「プロダクトマネジメント」の導入については、次の資料に詳しくまとまられています。

最後に常松さんは、

・LeSS導入により、開発に関する恒常的な悩みが減り、本質的な課題に向き合う余裕ができた。

・アウトカムに向き合う組織づくりはまだ道半ば

と評価しています。

そして、『ユニコーン企業のひみつ』の次のコトバで講演を終えています。

近道はない。でもやるしか無いんだ。

感想

ボクから見ると、一歩進んでるなーと言うのが感想です。

『ユニコーン企業のひみつ』読んでみたいと思います。


参加リポートは以上です。ここまで、お付き合いくださりありがとうございます。









川越在住。映画と音楽、お酒とラーメン好きのソフトウェアエンジニアです。 ビールは、ハートランド（KIRIN）。 🍜は、いろいろ。 好きな音楽は、クラシックギターとピアノ。好きなバンドは、ミスチル。好きなマンガは、「3月のライオン」。