要件設計から開発へ、繋がるデザイン設計のあり方

デザインは、要件定義から開発への流れを支える重要な工程です。

要件定義で交わした内容がデザインに反映されていない、
出されたデザインの実装コストが大きく開発部門を圧迫する…

UIや見た目の良し悪しとは別の問題として、デザインを取り巻くワークフローの問題は
概ね「コミュニケーションする」で解決されがちです。

本セッションでは、デザインを要件定義から開発へのフローを橋渡しするステップ捉え、
「伝わるデザイン」のありかたと、デザインを通じたワークフロー設計を考えてみます。

 
 

Outline/Structure of the Talk

- デザインの作り方・見せ方の変遷

- 見た目を伝えるデザインから、組み方を伝えるデザインへ

- ドキュメント制作を省コストですすめるワークフロー

Learning Outcome

- 省コストに、要件定義から開発へのフローを支えるデザインプロセスを構築する

Target Audience

デザインを取り巻くコミュニケーションをよりコンパクトに、本質に注力したい方

schedule Submitted 11 months ago

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    DENSO
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか?と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。あの時の彼の決断は正しかった、と今の私なら言えます。

    このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

  • kyon _mm
    keyboard_arrow_down

    kyon _mm / neno neno / Gota Miyazaki / Takao Oyobe - Agile Wars − アジャイルチームの夜明け −

    90 Mins
    Talk
    Intermediate

    agilewars.001.jpeg

    予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be

     

    数度目のアジャイル開発戦争が勃発。
    内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。

    Scrumの加護をうけし組織となるために工作を展開する企業。
    それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。

    終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
    そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・

  • Ryo Tanaka
    keyboard_arrow_down

    Ryo Tanaka - 会社組織で実験をしていくためのサバイバルテクニック

    20 Mins
    Talk
    Beginner

    実験場はどうして必要か?

    企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
    コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。

    でも、それ大丈夫ですか?
    安全ですか?失敗しても大丈夫ですか?失敗しないようにがんばりますか?
    でも、失敗ってしたほうがいいんですよね。

    会社組織は良い実験場か?

    そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね?
    失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。

    そうならないように、安全に実験できる場所を探しましょう!
    そのためのサバイバルテクニックを考えましょう。

    サバイバルテクニック

    #1 趣味を増やそう!

    単に趣味を増やすことに意味はありません。
    社会性が得られる趣味であれば、それは立派に実験場として機能します。

    #2 地域コミュニティに参加しよう!

    PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。

    #3 家族を実験に

    家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
    父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato / Hiroaki Ono - いつもの前説

    20 Mins
    Talk
    Beginner

    後の講演を楽しめるようにするために場を暖めます。

  • Yuusuke Sakai
    keyboard_arrow_down

    Yuusuke Sakai - 肥大化したプロダクトバックログを捨て、部署横断で1から再構築している話

    Yuusuke Sakai
    Yuusuke Sakai
    Director
    株式会社i-plug
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    2019年4月からスクラムで開発をしています。

    チームには「他部署からの要望」や「経営判断による最優先事項」が集中しやすく、

    プロダクトバックログは、自分たちでコントロールすることができないほどのアイテム数に肥大化していました。

    結果、

    「あのチームは、依頼してもやってくれない」

    「自分たちは、本当に価値のあるものを提供できているのだろうか」

    そんな声が聞こえるようになってしまいました。


    現在、この状況を打破すべく、一度プロダクトバックログを捨て、部署横断で1から再構築しています。

    プロダクトバックログの作り方を変えたことで、開発のプロセス自体も変化しました。

    このプロポーザルを書いている時点では、再構築したプロダクトバックログを使い、1スプリント終わったところです。


    一度もらった要望を捨てるという判断にも関わらず、どうやって他部署から協力を得ることができたのか、

    このチャレンジにより、どんな変化が起き、どんなことを学んだのか

    といったことをご紹介できれば、と思っています。