視覚仕様

仕様は致命的です。 これはおそらくプロダクトマネージャーの仕事の中で最も退屈な部分です。 おそらくそれが、ほとんどの仕様がひどく、遅延、変更、バグの主な原因である理由です。



積極的なコミュニケーションとプロダクトマネージャーの可用性は、仕様が不十分であるという問題の解決に役立ちますが、常にではありません。



アジャイルムーブメントには、仕様に関する独自の見方があります。 最も極端な翼は、その見解を次のように表現しています。



お尻仕様で！



そして、そのようなプロジェクトの要件の典型的な説明は次のとおりです。



ユーザーとして

新しいタスクをすばやく追加したい

時間を節約し、コンテキストを失わないために



驚くべきことに、このアプローチは機能します。 特定の場合。 以下のすべての条件を満たしている必要があります。

• チームは同じ部屋に座っています
• プロダクトマネージャーへの24時間365日のアクセスがあります
• チームにテスターはいません
• 設計者は1営業日以内にあらゆる問題の解決策を考え出すことができます

少なくとも1つの条件が満たされていない場合、チームには重大な問題があります。



スペクトルのもう一方の端には、人生の4分の1を包括的なプロジェクトドキュメントの作成に費やすことを望んでいる少数の個人がいます。 彼らはあらゆる詳細を熟考し、各フィールドを詳細に詳細に説明し、すべての否定的なシナリオに退屈に深く入り込み、システムがランダムなマウスクリックにどのように応答するかを正確に知り、SQLで名前を入力しようとし、データセンターに直接the石が当たります。

仕様とプログラマ

多くのプログラマーは仕様が好きではありません。 定義を導入し、それを「クラス1プログラマー」とします。 彼らは、システムがどのように機能するかを非常によく知っており、どのシナリオで「不明なエラー」または「あなたはそれができません」というメッセージを受け取ることができますか？



仕様の存在は、創造性の自由に対する制限と不信の表れとして認識されています。「この機能をどのように作成するのがベストかわからない」と思われるかもしれません。 したがって、クラス1プログラマーは仕様を読むことを好みません。 彼らはそれらをスキャンし、それらを見て、写真を見ることができますが、彼らはそれらを読みません。



クラス2のプログラマーはまったく異なる人々です。 機能に仕様がない場合、それらは悲しい状態に陥り、多くの変更、遅延した論争、および悪い決定を楽しみにしています。 彼らは、バグの定義を導入しようとして、テスターと多くの直接の接触があることを知っています。 彼らは、製品のマネージャーやお世辞をキャッチしようとしたり、彼からだまされたりするためにどれだけの時間を費やさなければならないかを明確に理解しています。





タイプ別のプログラマーの分布。 ほとんどの場合、仕様に適用されます。



クラス2プログラマーは、仕様を最初から最後まで読み、それを系統的に消化し、致命的に正確な質問をします。



クラス2プログラマの場合、任意の仕様を作成できます。すべての仕様を飲み込みます。 クラス1のプログラマーは、複雑な言葉を使わずに、短くて明確なキャプション付きの写真しか表示できません。 いっそのこと、漫画を見せてください。 アニメーションと言いたかった。



これら2つのクラスの間には、1.5の大きなクラスがあります。 これらのプログラマーは仕様を読み、一般にそれらの可用性を必要とします。 しかし、彼らは多くの熱意と思慮深さなしでそれをします。 そのようなプログラマーはほとんどいますが、製品管理仕様を作成するのは彼らのためです。 より正確には、仕様への参入の障壁を下げ、アイデアを視覚的、簡潔かつ鮮明に伝える必要があります。

仕様とテスター

テスターに​​は厳しい人生があります。 仕様が不足しているため、テストプロセスは忍耐力とストレス耐性の緩やかな拷問になります。 原則として、バグは仕様システムの動作の不一致です。 仕様がない場合、バグはありません。 利己的なプログラマーが喜んで使用するもの。



たとえば、バグがないために会社にボーナスがある場合、ボーナスを取得する最善の方法は仕様の作成を停止することです。 仕様なし-問題ありません。 プロダクトマネージャーは仕様を作成せず（また、空き時間にFacebookに猫を投稿します）、プログラマーはバグのないコードを作成し、テスターはバグを見つけません（会社が突然必要がないと突然判断しない限り）。 すべて順調です。 最後に悪魔を持っている顧客だけが、予測不可能な行動で苦しむことを知っています。



何らかの理由で、プログラマーは仕様を読まない余裕がありますが、テスターは読めません。 彼らは、製品マネージャーが最短時間で頭から捨てたゴミを細心の注意を払って理解する必要があります。 彼らはすべてを系統的に読み直し、矛盾やあいまいさを探す必要があります。 そして、これは怠zyなプロダクトマネージャーが使用できます。 実際、テスターがすべてを読み、すべてのエラーを修正しようとすると、仕様に煩わされます。

仕様のプロパティ

愚か者が悪い仕様と良い仕様を区別するための兆候について話しましょう。

（中）完全性

Gödelによると、完全な仕様を追求する意味はありません。 完全な仕様には一貫性がありません。 そのため、仕様が不完全であるという事実に同意する必要があります。 期待できる最大値は一貫性です。



この時点で、あなたはあきらめて、完全な仕様を作成することはできないので、それについて何ができるのかと言うことができますか？ ただし、完全性にアプローチする合理的な試みには多くの利点があり、時間と労力という2つのマイナス点しかありません。



バランスの検索は簡単な作業ではなく、明確な答えもありません。多くはコンテキストに依存します。 ただし、開発の開始時にプログラマーが3つ以上の質問でプロダクトマネージャーにアクセスした場合、マネージャーが新鮮な果物やコーヒーへのアクセスを安全に奪うことができるので、気が散らずにビジネスに取りかかることができます。



それでは、仕様はどのくらい完全なのでしょうか？ 答えは非常に簡単です。 まず、要件の仕様は数文に限定する必要があります。 開発を開始する前に、時間の観点から妥当な範囲で詳細に説明する必要があります。





ユーザーストーリーの開発段階に応じた詳細な仕様。 最初は、数文で十分です。 実際の実装の開始時には、完全な仕様が必要です。



仕様を検討した後、疑いの余地がないことをお勧めします。 実際には、開発プロセス中に、制限や実装が予想外に難しいものが明らかになります。 しかし、優れた仕様では、それらはほとんどありません。



仕様が短すぎる場合、発散効果により、チームのモラルがグラスの底に下がります。 この機能は、拡張し、変異し、変異し、予期しない適用部位に浸透し、がん性腫瘍に成長します。 その開発は決して終わらないようです。 それを削減し、制御し、終わらせるには英雄的な努力が必要です。





仕様が欠落している（不完全な）典型的な機能開発プロセス。 新しい問題を特定すると、作業量が増えます。 この機能を完了するには英雄的な努力が必要です。

脳脳

非常に賢いように見えることを好む人がいますが、これは彼らの本当の能力とは弱い相関関係があります。 彼らは「相関」、「発散」、「ゲーデル」などの言葉を喜んで使用しています。



だから彼らは文章がパラグラフを取り、セミコロンがあり、写真がまったくないという恐ろしい複雑なテキストを書くのが大好きです。 時々、そのような人々は、ありそうにない変動のおかげで、製品の管理者になり、プロジェクトの成功に破壊的な貢献をします。



仕様を読むのが難しいだけでなく、「ユーザーがマウス型マニピュレーターの左ボタンをダブルクリックしてクライアントアプリケーションの次のセクションに移動する操作を実行する」というフレーズの本当の意味を理解しようとして貴重なエネルギーを費やす必要があります。



仕様はできるだけシンプルにする必要があります。 クラス1のプログラマーでさえ、突然写真から目をそらして何かを読むことにした場合は、言語を理解する必要があります。 プログラマーはとにかく汗をかいて、あなたのすべてのクレイジーな要件を満たし、少なくともあなたの知性のジャングルからそれらを救わなければなりません。

大きさ

印刷された仕様が壊れやすいテスターを損なう可能性がある場合、この仕様には明らかに重大な問題があります。 優れた仕様を使用すると、蚊を殺すことができ、最大の飛ぶことができます。大きなクリーチャーを殺すと疑問が生じます。 余分な単語、冗長な段落、繰り返しの必要はありません。 廃棄するものがなく、仕様がまだ大きいと思われる場合は、機能をいくつかの小さなものに分割します。



サイズは完全性と相関しているように見えるかもしれません。 ただし、仕様を水で満たすことは明らかに良いアイデアではありません。 意味と人生で満たしてください。

アイデアを伝える方法

私の考えを説明する一般的な方法は何ですか？ それらを調べてみましょう。

疑似物語

多くの仕様開発者は構造を愛しています。 最もアクセスしやすい構造要素：テーブルとリスト。 多くの場合、仕様にはリスト、リスト、ネストされたリスト、リストにネストされたネストされたリスト、およびテーブルはありません。



一方では、テーブルは表形式のデータをうまく把握するのに役立ちます。 しかし、どの仕様も表形式データの形式で表現できるとは考えられません。 いくつかは成功しますが：





テーブルの優れた使用例。



リストも適度です。 仕様全体がそれらで構成されている場合、5ページ目までに著者を撮影し、7ページ目までに自分自身を撮影します。





リストの説得力のある使用例。



このようなテキストの使用はカルマを台無しにします。 そうしないでください。

物語

通常、製品マネージャーは一貫したテキストを書くことを好みません。 プレート、リスト、チャート-これはどこに行っても変わりません。 しかし、わかりやすい話を取り、書くことは彼らの強さを超えています。 したがって、物語の仕様は自然界ではほとんど見られません。 例えば、私はそれを書く自由を取りました。

VasyaとButch DnDのストーリー

Vasyaは次の反復を計画しています。 彼はカードで満たされたボードを見ます。 左側に、彼はバックログのカードのリストに気付きます。 Vasyaは、より高速なユーザーの名前を読み、次のリリースで最初の3つのストーリーを実行する必要があることを理解しています。 Vasyaは習慣的にCtrlを押し、各カードをクリックします。カードはそれに応じて魅力的に黄色に変わります。 Vasyaは最初のカードをつかみ、右の列にドラッグし始めます。 カードは1つに美しく折りたたまれており、右隅に壮大な数字の3が付いています。 Vasyaはカードを目的の列に移動しますが、まだリリースしていないため、カードに反応して列が黄色に変わる様子を楽しんでいます。



ハッピーエンド

ボブはカードをリリースし、それは3つに分割されます。 完了すると、列は通常の灰色に戻ります。 カードは2回点滅して、ここですでに慣れていることを保証し、また普通になります。 ヴァシャは幸せです。



不運な結末

Vasyaがカードをリリースすると、突然、驚くべき赤いメッセージが表示されます。「あなた、私の友人、ユーザーストーリーの反復を変更する権限がありません。 管理者に尋ねてください。多分そうするでしょう。」 カードは左の列に戻って黄色のままであるため、Vasyaはシステムの開発者と比較して自分の価値がないことを完全に感じることができました。

このような仕様を読むことは、表やリストのドライな言語よりもはるかに興味深いようです。 それは動機を明らかにし、あなたに解決を感じさせ、提示させます。 Vasyaはただ残念に思って、どういうわけか彼を助けたいと思っています。 リンクを1回クリックするだけで、Vasyaに管理者にpingを送信する機会を与えることができますか？ または、Vasyaがカードをリリースする前に予防的なエラー表示を行うには？



残念ながら、通常の首尾一貫したテキストに時間を費やしたい人はほとんどいません。 文書に表を入れて、その列をドライな動詞で埋める方がはるかに簡単です。



たぶん、物語の仕様は十分に正式ではありません。 しかし、適切な写真で補えば、すべてがうまくいきます。

Bdd

行動駆動開発には、要件を記述するためのかなり興味深い形式があります。 実際、機能を受け入れるための基準を説明しています。 すべての基準に合格すると、機能は準備完了と見なされます。 BDD形式の仕様の一例を次に示します。

スクラムマスターとして、週ごとに描かれたリリースBDチャートを見たい



スクラムマスターとして

週ごとに描かれたリリースBDチャートを見たい

反復練習が無効になっている場合

BDチャートの恩恵を受けることができるように



開発プロセスを考える

管理->プロセス->編集で反復練習をオフにすると

リリースBDチャートに移動します

次に、反復速度を毎週の速度に置き換えます

チャートの終了日はリリースの終了日と同じです

そして、反復ではなく数週間で描かれたBDチャート

チャートの開始日はリリースの開始日と同じです

このアプローチの良い点と悪い点は何ですか？ 良い点のうち、単一の形式を区別できます。 あなたはそれに慣れ、数週間後、あなたは何らかの形ですぐにこのフォーマットで仕様を書き始めます。特に脳は含みません。 はい/完了/受信-ユーザーアクションに対する明確な応答形式。



さらに、このような仕様は自動化できます。 もちろん、もう少し厳密な形式に同意する必要がありますが、原則として、製品マネージャーは、すぐに自動テストに変わるスクリプトを作成できます。 実行可能な仕様は、あらゆる開発者の夢です。



短所でも十分です。 第一に、自動化されたテストに適切に変換されるすべてのものは、通常、人間の脳にほとんど変換されません。 仕様は主に人向けに書かれており、テスト用ではありません。 BDD形式を認識するのは非常に困難です。 多数のシナリオからのスペックは特に鈍いように見えます。 それは、リストやテーブルよりも優れているものはなく、多くの場合、さらに悪いものです。これには、Given、When、Thenの繰り返しが多く含まれているためです。 これらの繰り返しにより不要なノイズが発生し、有用な信号を認識しにくくなります。



BDDスクリプトは、システムとユーザーの相互作用を記述するのに適していますが、非機能要件およびインターフェイス要素にはまったく適していません。



BDDを使用する場合、機能全体を一度にカバーすることはほとんど不可能です。

インターフェイスの概要

多くの製品マネージャーはペンを恐れており、色鉛筆のセットは気分を台無しにします。 彼らは描くのが恥ずかしくて、フリーハンドのスケッチはプロフェッショナルではなく、十分にクールではないと確信しています。 鉛筆の代わりに、Visio、OmniGraffle、または他の高価なプロ用ツールを好みます。



スケッチの場合、しっかりした手と目を閉じて直線を描く技術を使用することは完全にオプションです。 スケッチの利点は、スケッチを非常に迅速に行い、電話で写真を撮り、最終的に鈍いライブ写真で希釈できることです。





Targetprocess 3でシステムの概要を報告します。



通常、それらはインターフェースを描画しますが、はるかに少ない頻度で、より深いものを描画します。 スケッチだけで仕様を作成することは可能ですか？ 事実ではありませんが、これがアーティストとしてのあなたの能力の最良の応用であるということです。





Targetprocess 3の役割、プロジェクト、およびチームに応じて、人々に許可されたタスクの割り当てのスケッチ



スケッチには重大な欠陥があります-詳細の欠如。 定義では、スケッチからささいなことを期待するべきではありません。それは一般的な全体像、一般的なアイデアを提供しますが、機能開発段階で多くの追加の質問を提起します。





Targetprocess 3でタイムラインをスケッチします。



個人的にはスケッチが大好きです。

詳細設計

デザインはすべてシンプルです-開発段階の前に準備ができている必要があります。 デザイナーが数日で何かをリベットできることを期待しないでください。彼自身は恥ずかしくないでしょう。 デザイナーには時間が必要です。 通常はたくさん。 機能が開発されるずっと前に設計を開始する必要があります。



問題があります。 完成したデザインの機能が突然不要になる場合があります。 何もする必要はありません。開発される可能性が高い機能を推測して設計する必要があります。





Targetprocess 3のタイムラインデザインの準備



そのため、完成したデザインは、あらゆる仕様の不可欠な属性である必要があります。 設計は仕様全体を置き換えることができますか？ 残念ながら、ありません。 通常、すべてのシステム状態は設計に表示されず、相互作用フローは説明されず、すべてのシナリオは解決されません。 デザインは静的です。 そして、ダイナミクスが必要です。 設計のダイナミクスを表示できます。





時間とともに請求カードを変更するための3つのオプション



しかし、それは長くて困難です。 選択を非常に細心の注意を払って実行できるのは、ごく少数の人だけです。

絵コンテ/絵コンテ

ストーリーボードは映画製作者に愛されています。 一般的に、これはシーンの個々のキーフレームのセットにすぎません。





理解できない映画の典型的な絵コンテ。



絵コンテを描くのに素晴らしいアーティストである必要はありません。 任意の角度で曲線を描くことができれば十分です：





典型的な高速ストーリーボード。



業界では、ストーリーボードは個々のシステム状態の集合です。



ストーリーボードは非常にコンパクトであり、一般的にどのような状態であるかを理解することができます。 優れた絵コンテも、これらの州に入る方法を示しています。





代替スクリプトでTargetprocess 3にタスクをすばやく追加するためのストーリーボード。



静的なインターフェイススケッチとは異なり、ストーリーボードはシステムとのユーザーインタラクションを示します。 相互作用が複雑な場合、ストーリーボードは複雑です。 これはもう少し考えるためのサインです。突然、簡単にできるようになります。

流れ

要件をよく理解するには、ユーザーが実行できるアクションとシステムが実行できる状態を知る必要があります。 BDDスクリプトは一般にそのような理解を与えますが、クラス1のプログラマーが理解できる画像に注意深く読み、翻訳する必要があります。 すべてのアクションとすべての状態を描画する方がはるかに簡単です。



フロー図は、ユーザーのアクションに応じてどの状態遷移が可能かを簡単に示すことができます。または、UI要素を含めることもできます（この場合、ストーリーボードに近づきます）。



私はフローチャートを描くのがインターフェースのスケッチに劣らないのが好きです。





Targetprocess 3のコンテキスト編集スレッド。

アニメーション/ GIF

すべての子供は漫画が大好きです。 しかし、1分間の漫画を作成するためには1000枚のドローイングを作成する必要があることを知ったとき、ほとんどの人はアニメ映画に従事することを永遠に思いとどまらせます。



それでも、ストーリーボードはアニメーション化できます！ その後、非常に視覚的なものになり、これがどのように機能するかを想像できます。



アニメーションは、ライブプロトタイプよりもはるかに高速に実行できます。 もちろん、インターフェースとの実際の相互作用はありませんが、主なケースは非常によく示されます。



アニメーションGIFを作成するには、忍耐力、忍耐力、専門的な変形が必要です。 イゴール・トラフィモヴィッチはアニメーションに関与し始め、いくつかの良い例を砲撃しました。





Targetprocess 3でのデマンドカードの進行状況の経時的変化。



アニメーションは基本的なことを示すことができますが、複雑なケースをアニメーション化することは非常に問題が多く、長いものです。





Targetprocess 3リストでの高速データ編集

紙のプロトタイプ

すべての子供が紙、はさみ、接着剤を愛するわけではありません。 反対側の隣人にピグテールを切ろうとするためのポインターで手でbeatられた人もいれば、円を切ることができなかった人もいれば、レッスンの途中で椅子に接着された人もいました。 まあ、悪意のある接着剤愛好家は、単に希望する専門家のレベルに住んでいません。 これがおそらく紙のプロトタイプがあまり一般的でない理由です。



紙を取り、インターフェイスの一部を描き、ビデオカメラをドラッグし、数時間ですべて記録し、短いビデオをマウントするのは簡単なことではないように思えます。 さあ、ビデオ、少なくともインターフェイスを通過して、物議を醸す、あいまいな場所がどこで発生するかを見つけてください。



バックパックに紙セットを入れて、スターバックスのシンプルなラテのプロトタイプを高く評価し、...オリジナリティの深さを明らかにする恐ろしいユーザーを探しに行くことができます。



紙での作業は楽しくて面白いです。 相互作用がはっきりと見えます。 もちろん、必要な時間はスケッチよりもはるかに長くなりますが、実際のプロトタイプよりもはるかに短くなります。 このタイプのプロトタイピングはここでは過小評価されているように思えます。





iPadアプリケーションのペーパープロトタイピング（これは開始しましたが、完了していませんでした）。





登録フォームの紙プロトタイピングの良い例

インタラクティブな仕様

インタラクティブな仕様はテキストとグラフィックスを組み合わせており、非常に効果的です。 それらを作成するには、通常、プログラムできる必要があります。 すべてのプロダクトマネージャーが必要な知識のセットを持っているわけではありません。何らかの形でテーブルやリストがより身近になっています。



私の人生で見た唯一のインタラクティブな仕様は、オレグ・セリガによって作成されました。





Targetprocess 3でのカードカスタマイズのインタラクティブな仕様。



ここで、カードサイズ、カードタイプを切り替えて、重要なプロパティの説明とともに目的のアイテムにすばやく移動できます。



インタラクティブな仕様を作成する必要がありますか？ ほとんどありません。 プロトタイプには十分ではありません。また、すべての情報をより効率的に伝える簡単な方法があります。

ライブプロトタイプ

ほとんどの製品マネージャーはコードを書くことができません。 リスト、キュー、テーブルハッシュなどの一部のデータ構造は、それらとは無関係ではありません（ただし、実際の動作はわかりません）。 彼らは一般的にループと条件文のアイデアを持っています。 しかし、実際のコードを書いた経験がある製品マネージャーはごく少数でした。 これはすべて、自分でシステムのライブプロトタイプを作成できないという事実に変換されます。つまり、プログラマーに連絡する必要があります。



良いプロトタイプは多くの質問に答えます。 これにより、多くのシナリオを自分で体験し、最終的に実際の相互作用を確認できます。 プロトタイプでユーザビリティテストを実行できます。 プロトタイプは、単に顧客に見せて、彼らの願いを集めることができます。 営業担当者は、潜在的なクライアントにプロトタイプを見せ、すでに開発中であり、まもなく（2か月後に）確実にリリースされるとうそをつくことができます。



これ以上望ましいものはないようです。 しかし、すべてがそれほどバラ色ではないため、プロトタイプで仕様を完全に置き換えることはできません。



残念ながら、ほとんどの場合、ポジティブなシナリオのみがプロトタイプに実装されています。 プロトタイプの主な目標は、特定のソリューションの操作性を証明するために、ブレークスルーに取り組むことです。 ネガティブシナリオは、証拠の品質にまったく影響を与えないため、取り残されます。 ただし、開発者にとって、否定的なシナリオは非常に重要です。 開発者がそれらについて考えたくない場合、テスターは崇拝します。 その結果、システムの動作の微妙な違いを辛抱強く見つけ、バグを痛々しく修正し、「できません！」というメッセージを編集する必要があります。



2番目の問題は、小さな部品の不足です。 プロトタイプは通常、完成したデザインとは大きく異なります。 それは一般的に非常に恐ろしく見えることがあり、最も重要なのは労働者です。





Targetprocess 3の最初のプロトタイプで、コンセプトをテストするために作成されました。 それは顧客に示され、一般的な承認を引き起こしました。 Clickableですが、動作するすべてが機能しているわけではありません。



プロトタイプを通じて、「このフィールドの最大長は？」などの要件を把握するのは非常に退屈で長くなります。 開発者は、フィールドに長さがあることを覚えておく必要があるだけでなく、プロトタイプをマウスで突いてコードを見て、そこで何か良いものを見つけようとしても無駄です。



そのため、プロトタイプは仕様を置き換えません。 完全に補完-これはお願いです。 しかし、開発者に「ここではすべてがはっきりしているので、始めてください」という言葉を使ってプロトタイプを提供するプロダクトマネージャーでインテリジェンスに入らないように注意します。



もう1つのマイナスは時間です。 プロトタイプは長い間使用しています。 一般に、開発者には高速と低速の2種類があります。 どんな場合でも、高速のプロトタイプ開発、低速を信頼できます。 ご存知のように、プロトタイプのコードの品質はarbitrarily意的に劣る場合があります。 主なことは、必要なスクリプトが機能することです。 そして、KOは今私に背中を叩いているようですが、私自身は過去にそのような過ちを犯しました。

仕様=視覚的説明

仕様の目的は、アイデアを最も理解しやすい完全な方法で伝えることです。 これは、テキストとグラフィックの両方を使用する場合に最適に機能します。 したがって、すでに説明したさまざまな方法の健全な組み合わせが必要です。 それは常に困難であり、創造的なアプローチと善を行いたいという欲求が必要です。



以下では、すべての方法が1つのスケジュールにまとめられています。 X軸では、コンテンツを作成するのが困難です。 明らかに、ライブプロトタイプの作成は困難ですが、スケッチのスケッチは非常に簡単です。 Y軸には、実用性があります。つまり、この方法がアイデアをどれほど効果的に提供するかです。 繰り返しますが、疑似物語仕様の有用性は高くありませんが、完成した設計またはプロトタイプの有用性は高いです。





1つのボトルでアイデアを伝えるためのすべての方法。



BDDや擬似ナラティブなどの低ユーティリティメソッドを使用しないことをお勧めします。スケッチ、物語、フローチャート、ストーリーボード、紙のプロトタイプ、完成したデザインがうまく機能します。本当にたくさんある場合にのみ、アニメーションやライブプロトタイプに時間をかける価値があります。



友よ、善の道に出ましょう！わかりやすい言葉でストーリーを伝える明確な視覚仕様を作成します。



PSまだ20枚の美しい写真が残っていますが、この記事はすでに巨大なので、申し訳ありません。