一部の企業の開発マネージャーのポストへのインタビューに合格した著者は、会話中に同じ話を聞く必要がありました。

「半年（または1年-期間は会社によって異なります）1つのプロジェクトを「のこぎり」にした3〜4人のプログラマがいます。 それでも、努力にもかかわらず、起動して顧客に示すことができる実行可能な「デモ」はまだありません。 私たちは、仕事を組織できるリーダーを探しています。」

状況の奇妙さは、一見賢明で経験豊富な企業のリーダーが、プロジェクトの作業の開始時ではなく、採用されたチームが失敗したときにのみ開発プロセスを組織化することを考えるという事実にあります。 一方、プロセスは最初から検討する必要があります。

この記事では、著者は、Larian Studiosのツールキット部門で開発プロセスを整理した成功経験を共有しています。

会社について

Larian Studiosは、100人を超えるスタッフがロールプレイングゲームのシリーズDivinityを開発している小さな会社です。 同社は、さまざまな国にあるいくつかのスタジオで構成されています。 スタジオの1つはサンクトペテルブルクにあります。 ゲームは、Windows、Linux、Mac OS X、Xbox ONE、PlayStation 4などのさまざまなプラットフォーム向けにリリースされています。

技術について

ゲームを開発するために、同社は3Dエンジンと統合開発環境を使用しています。 エンジンは異なるプラットフォームに移植されているという事実にもかかわらず、開発はWindowsプラットフォームで実行されます。 これは、開発環境がWinFormsおよびWPFテクノロジーを使用して記述され、.NET Frameworkの制御下で実行されるためです。

統合開発環境とは、ゲーム全体または別のゲームモードまたはレベルでゲームを実行できるアプリケーションです。 これは、ゲームを起動するための一種のコンテナであり、レベルの作成、サーフェスの編集、オブジェクトの配置、スクリプトの作成と編集、キャラクター間のダイアログなどのためのさまざまなツールを備えています。 など

ラリアンエディターを使用して、神性：オリジナルシン2ゲームを作成します。

開発環境が印象的であり、多くのUI要素が広範な機能へのアクセスを提供するという事実にもかかわらず、その使用の利便性は、インターフェイス自体の輻輳とその個々の部分が一貫していないという事実の両方のために、多くのことが望まれていますお互いに。 これが主な問題です。

要件について

ツールキットの基本的な要件は、次の3つの条件で表現できます。

1. それはプロフェッショナルに見え、「ニーハイ」ソフトウェアのようではありません。
2. 指定された機能を備え、使いやすいものでなければなりません。
3. 開発の条件とコストは、合理的な制限を超えてはなりません。

ツールキット部門が開発したAll Sparkエディターは、視覚効果を作成するために使用されます。

顧客について

ツールは国内の顧客向けに開発されています。 これらには、ゲームを直接作成するすべての人々が含まれます。 これらは、視覚効果のデザイナー、3Dアニメーター、ゲームデザイナー、スクリプト作成者などです。 など

部署について

ツール開発部門は小規模です。 その構成：

• リードプログラマー1人（マネージャー）
• 3人のプログラマー
• 1人の品質エンジニア

プロセスについて

復習

部門の作業を整理するには、開発プロセスを配置する必要があります。 設定されたプロセスは、プロジェクトを予定通りに、指定された品質で提供するのに役立ちます。 チームは小さく、誰もがお互いを知っているので、私たちはヘビーウェイトではなく、あらゆる種類のルールで規制されているのではなく、簡単な開発プロセスを使用します。 その中の多くのものは形式化されていませんが、他のものは口頭での合意に基づいています。 しかし、私が話したい明確に構造化されたものがあります。

開発の段階と段階

ツールキット部門の開発プロセスは、次の4つの段階に分けることができます。

1. コンセプト開発
   この段階で、社内顧客は開発中のプログラムのコンセプトを準備し、基本的な要件を策定します。
   
   
2. 計画中
   この段階で、プロジェクトを評価し、その計画を作成します。
   
   
3. 開発
   この段階では、プログラムが開発されています。
   
   
4. 護衛
   プログラムが改善され、バグが修正されました。

ステージ1.コンセプト開発

新しいツールの開発は、コンセプトの開発から始まります。 ビジュアルエフェクトデザイナー、3Dアニメーター、ゲームスクリプトなど、社内のお客様がこれを行います。

コンセプト作成プロセスは、いくつかの段階で構成されています。

1. 意識のニーズ
   この段階で、利害関係者は、楽器に対するニーズと、スタジオ内でそのようなツールを開発するように促す理由を認識しています。 そのような理由には次のものがあります。
   
   
   1. 財務
      最近まで、彼らはサードパーティからライセンスされたツールを使用していました。 しかし、ライセンスの価格が上昇しているため、ツールの開発は安価になっています。
      
      
   2. 技術的
      既存のツールは、ゲームが開発されている新しいプラットフォームをサポートしていません。または、その助けを借りて、新しいゲームのキーの1つになる必要がある要件を実装することはできません。
      
      
   3. 人間工学に基づいた
      既存のツールは使用するのに不便であり、労働生産性に大きく影響し、結果としてゲーム開発の速度に影響します。
   
   
2. 要件のステートメント
   この段階で、利害関係者は新しい機器の要件を策定します。 これらの要件には、機能部分（ツールが行うべきこと）と人間工学的コンポーネント（ツールを使用することの便利さ）の両方が含まれます。
   
   
3. アナログソリューションを検索
   前のステップで定式化された問題の解決策の検索は、アナログプログラムの研究から始める必要があります。 私たちの場合、そのようなアナログは、Unreal Editor、Unity 3D、FxStudio Designer、その他のプログラムです。 このようなツールの深い知識により、成功したソリューションをスパイし、自分のアプリケーションで使用することができます。
   
   
4. 図面レイアウト
   レイアウトにより、開発者は開発中のツールがどのように見えるかを視覚的に表現できます。 最初に、メインアプリケーションウィンドウ、メインデータ編集ウィンドウ、ツールバーなどのいくつかの主要な画面を描画します。 開発中に、残りのウィンドウのレイアウトを追加できます。
   
   
5. 文書作成
   最終文書は、モックアップと要件を組み合わせて作成されます。 このドキュメントは、画面ごとに章に分かれています。各画面は個別の章です。 この章の最初に、対応する画面のレイアウトがあり、その下にテキスト形式の対応する要件があります。

ステージ2.計画

計画中、チームは次の3つのことを行うことが重要です。

1. 利害関係者と結果に同意します。
2. プロジェクト計画を作成します。
3. コミュニケーション計画を立てます。

ステップ2.1 結果に同意する

このステップでは、製品のアルファ版がどうなるかを理解することが重要です。 私たちの場合、アルファバージョンは、第3段階（開発）の最後に取得されるプログラムのバージョンです。これについては、後で詳しく説明します。 アルファ版には、顧客がコンセプトで策定したすべての要件からはほど遠いが、それらのサブセットのみが含まれる場合があります。 なんで？

実際には、コンセプトには顧客の多くの「ウィッシュリスト」が含まれます。 それらのいくつかは実際にはテストされておらず、実際には役に立たない場合があります。 そして、逆に、顧客がコンセプトを書いたときに考えなかった何かを実装する必要があるかもしれません。

そのため、お客様にできるだけ早くプログラムを使用していただけるよう努めています。 動作させずに、少なくともテストモードにします。 重要な要件と重要でない要件を示すことができるのは、実際の使用経験だけです。

この目標を達成するために、最小限の作業バージョンに含めるべきものを理解しようとしています。 そして、すべての要件のうち、顧客と合意した上で、それなしでは本当に不可能な要件のみを選択します。

最小の作業バージョンはアルファバージョンです。 そのリリースで、開発フェーズは終了します。

独自のGenomeエディターを使用すると、3Dアニメーターがキャラクターを視覚的にプログラムできます。

お客様がプログラムの使用を開始すると、バグやさまざまな粗さが明らかになります。 さらに、それを使用した経験は、最初にテストで表示され、次に「戦闘」条件で表示されます。 この経験により、残りの要件を評価できます。どれが重要で、どれが重要でないかです。

粗さを排除し、過大評価されている要件を実装し、メンテナンス段階でバグを修正します。

ステップ2.2 プロジェクト計画を立てる

プロジェクト計画を立てるには、次のものが必要です。

1. プロジェクト評価を行う
2. 利用可能なリソースを評価する
3. マイルストーンのスケジュール

ステップ2.2.1。 プロジェクト評価を行う

私の意見では、プロジェクトの評価には2つのタイプがあります。

1. 予備評価
2. 詳細な評価

予備評価はかなり大雑把です。 単純化された分解を使用しますが、このため、あまり時間を必要としません。

詳細な評価はより正確です。 しかし、それを受け取るためには、設計を実行し、作業を分解する必要があります。

時間を節約するために、プロジェクトの大まかな評価を行います。 ただし、「大まかなモデル」を使用すると、正確な結果を得ることができます。 これをどのように達成しますか？ プロジェクトを評価するために、1つのモデルではなく、3つのモデルを使用します。

1. 機能モデル
2. コンポーネントモデル
3. プロセスモデル

機能モデルは、一連の有用な機能の形で開発されたプログラムを表します。 ユーザーの視点を反映しています。

コンポーネントモデルは、アプリケーションをモジュールのセットとして表します。 エンジニアの外観を反映しています。

プロセスモデルは、プログラムをプロジェクトとして見たものであり、一定の時間を持ち、一連の段階で構成されています。 各ステージには独自のタスク（多くの場合、組織的または管理的）があり、その結果、その期間は各タスクの完了に必要な時間の重ね合わせとして見積もることができます。 プロセスモデルは、マネージャーの視点を反映しています。

これらの3つの視点を組み合わせることで、同じ製品の包括的な視点を表すことができます。 いくつかのことは、関数を通じて、いくつかのモジュールを通じて、いくつかのプロセスを通じて最も高く評価されます。 その結果、バランスの取れたスコアが得られます。

おそらくより詳細に、このトピックは別の記事で開示されます。

ステップ2.2.2。 利用可能なリソースを評価する

利用可能なリソースを正しく考慮するには、1人の従業員が自分の時間の100％をタスクに費やしていないことを理解する必要があります。 プログラマーは同僚とコミュニケーションをとり、少し休憩することに時間を費やすことを忘れないでください。

もちろん、チームの人数が2人で、ほぼ同じ生産性で作業している場合は、時間の無駄を無視して、1人1日が8時間であると想定できます。 実際、この規模のチームでは、問題に同意する時間はそれほど重要ではありません。

ただし、チームにすでに4人がいる場合は、コミュニケーションの時間とさまざまな人々のさまざまな労働生産性の両方を考慮する必要があります。

利用可能なリソースを評価する際に、次の労働生産性の表を使用します。

従業員	性能
リードエンジニア	50％
エンジニア	85％
初心者	50％
未経験の初心者	25％

主要なエンジニアは、プログラミングに加えて、計画、タスクの分散、顧客とのコミュニケーション、もしあれば新人を未経験者のトレーニングに紹介するために時間の一部を費やしています。 したがって、彼はプログラミングに半分の時間しか費やすことができないと考えています。

通常のエンジニアは、85％の生産性で作業する必要があります。 彼の残りの15％は、残りのチームとのコミュニケーション、顧客とのコミュニケーション、レポートの作成に費やしています。

ご存知のように、最初は新しい人をプロジェクトに接続しても、開発は加速されませんが、開発は遅くなります。 これは、チームメンバが新しい従業員を訓練することで仕事から気をそらされることを余儀なくされるという事実によるものです。 はい、初心者自身は最初はほとんど生産性がありません。私たちは、トレーニングに労働時間の半分まで費やしていると考えています。 時間が経つにつれて、生産性が向上するはずです。 成長しない場合、これは彼のチームでの滞在の妥当性について考える機会です。

経験の浅い初心者は、最初は単なる初心者よりもトレーニングに多くの時間を費やす必要があります。 したがって、最初の25％のパフォーマンスは恐ろしいものに見えるべきではありません。 ただし、時間の経過とともに成長する必要もあります。

これらの数値を使用して、チーム全体の実際の労働生産性を評価できます。

チームが4人で構成されているとします。

• リードエンジニア;
• エンジニア;
• 初心者
• 未経験の初心者

その後、チーム全体のパフォーマンスは次のようになります。

1 * 50％+ 1 * 85％+ 1 * 50％+ 1 * 25％= 210％= 2.1人日

これは、誰もが100％の生産性で作業していると考えられている単純なアプローチの場合の2分の1です。

ステップ2.2.3。 マイルストーンのスケジュール

計画を立てるとき、すべての作業をいくつかの段階に分散させる必要があります。 各ステージはマイルストーンで終了します。 マイルストーンは、完了した作業の結果が評価される時点です。

マイルストーンを計画するとき、2つのタスクに対処する必要があります。 まず、マイルストーンごとにユーザー要件を配布する必要があります。 第二に、各マイルストーンの期間を評価する必要があります。 同時に、マイルストーンの期間がほぼ同じであることを確認することが重要です。

マイルストーンによる作品の配布には、いくつかの基準を使用します。

1. テーマ
   各マイルストーンは、特定のトピック専用にする必要があります。 これにより、チームは特定のことに集中し、散らばったり投げたりすることを回避できます。
   トピックの例：データモデル、ツールバー、グラフ編集ウィンドウなど
   
   
2. 中毒
   ジョブ間の依存関係を考慮する必要があります。 依存する作業が、それらが依存する結果の作業よりも後になるように、作業を分散する必要があります。
   
   
3. 期間
   すべてのマイルストーンでほぼ同じ期間を維持する必要があります。 各マイルストーンの期間が5〜6週間になるようにします。

ステップ2.3 コミュニケーション計画を立てる

プロジェクトが正常に進行するためには、チーム内で個々の開発者間だけでなく、チームと顧客の間でコミュニケーションがどのように構築されるかを考える必要があります。

私たちの会社では、判明したいくつかのプラクティスを使用しています。 -非常に成功しました。

クラウド内のプロジェクトスペース

新しいプロジェクトを開始するとき、「クラウド」にプロジェクトスペースを作成します。 クラウドストレージとして、Googleドライブを使用します。 ただし、Yandex Disk、Mail.Ru、MicrosoftのOne Driveなど、他のサービスを使用できます。

プライバシー要件または個人的な好みだけでクラウドサービスを使用できない場合、ローカルサーバーにSharepointをインストールするか、svn、git、perforceなどのバージョン管理システムを使用するか、通常のファイルサーバーにプロジェクトフォルダーを作成します。 オプション-シンプルからエキゾチックまで-たくさん。

単一のプロジェクトスペースを使用すると、プロジェクトに関連するすべてのドキュメントを1か所に集中できます。 また、「クラウド」を使用すると、すべてのチームメンバーがそれぞれの職場からアクセスできるようになります。

プロジェクトスペースとは何ですか？ これは、アクセス権が設定された通常のクラウドストレージフォルダーです。 内部には他のフォルダが含まれており、各フォルダには特定の分野に関連するドキュメントが集中しています。

たとえば、この場合、プロジェクトフォルダーには通常、次の4つのサブフォルダーが含まれます。

1. コンセプト
   顧客の要件と開発されたアプリケーションの設計を説明するドキュメントが含まれています。
   
   
2. 技術プロジェクト
   プログラムの技術設計、クラス図、既存の技術的な制限などを説明するドキュメントは、このフォルダーに配置されます。
   
   
3. プロジェクト管理
   このフォルダには、プロジェクト評価、チーム構成、プロジェクトスケジュール、休暇スケジュールなど、プロジェクト管理の問題に関連するすべてが含まれています。
   
   
4. 品質評価
   ここでは、テストケースの説明、マイルストーンの結果に関するレポート、バグを登録するためのルール、プログラムの問題領域のリスト、およびバグを見つける方法を見つけることができます。

連絡先リスト

連絡先リストは、プロジェクトに何らかの形で関係しているすべての人々の名前と連絡方法（電話、電子メールアドレス、スカイプアカウントなど）を含むドキュメントです。

連絡先リストを使用すると、適切な人をすばやく見つけることができます。 そのようなリストを編集することを怠るマネージャーは、緊急時にリードプログラマー、デザイナー、または品質エンジニアを見つけるために時間と神経を無駄にします。

連絡先のリストは、次のような表形式で記述するのが最適です。

氏名	役職	モブ 電話番号	メール	Skype
イワノフP.I.	リードプログラマー	+7（XXX）XXX-XX-XX	pivanov@company.com	ピバノフ
ペトロフI.S.	プログラマー	+7（XXX）YYY-YY-YY	ipetrov@company.com	イペトロフ

毎日の会議（スタンドアップ）

毎日、私たちの小さなチーム（4人のプログラマと1人のQAエンジニア）が集まり、プロジェクトの現在の進捗状況を議論する短い会議を開催しています。 通常、このような会議には10〜15分かかり、すべてのチームメンバーが知ることができます。

長時間の会議の形式は変更されず、3つの部分で構成されます。

1. 一般的な発表
2. 各チームメンバーのレポート
3. 問題と提案の議論

最初の部分では、プロジェクトマネージャー（または管理機能を実行する主要なプログラマー）がプロジェクトに関連するニュースについてチームに通知します。 これは、プロジェクトキュレーターの管理上の決定、社内顧客からの要求、開発中のアプリケーションまたはチームの作業に関する肯定的または否定的なフィードバックなどです。

次に、レポートの順番が来ます。 この段階で、各チームメンバーは自分の作業について報告し、次の3つの質問に答えます。

1. 昨日は何をしましたか？
2. 今日は何をしますか？
3. 現在のタスクの完了を妨げる障害はありますか？

このレポート形式により、プロジェクトマネージャー（またはリードエンジニア、管理機能の一部を実行）は、プロジェクトの進行状況とチームが達成した進捗を把握できます。 また、チームの各メンバーは現在作業しているタスクについて話し、既存の問題を特定する必要があるため、他のチームメンバーが自分のタスクと同僚のタスク間の依存関係を時間内に見つけ、必要に応じてアクションを調整してこれらの依存関係を解決するのに役立ちます。

パブリックレポートのもう1つの利点は、各チームメンバーの作業が表示されることです。 結果の欠如を隠すことは不可能です。 これは、タスクを進めることができなかった人とチームの両方にとって追加の刺激的な要因です。誰かが自分でタスクに参加するためのヒントや提案を与えることができます。

報告後、議論が始まります。 問題がある場合は、それらについて簡単に説明し、ソリューションへのアプローチを開発します。

私たちのチームの実践は、そのような会議の高い有用性を確認しています。 そして、利益が将来にわたって継続するためには、会議が存在するすべての問題の長期にわたる決定的な議論に発展しないことが重要です。

コミュニケーターでの「ディスカッション」

プロジェクトの作業を開始する前に、コミュニケータープログラムで「ディスカッション」も作成します。 当社はこの目的のためにスラックを使用しています。 ただし、HipChat、Skypeなどの他のプログラムを使用できます。

このような「話し合い」（「会話」、「グループ」、または「会議」）を使用すると、たとえば、別のオフィスや別の国にいる社内顧客、またはリモートの従業員。

当社では、コミュニケーターでの「議論」が開発者と顧客の両方によって積極的に使用されています。 開発者はこれを使用して、顧客に簡単な質問をし、アプリケーションのリリースバージョンの新機能について通知します。 お客様は「コメント」に「コメント」を残し、緊急の対応が必要な場合は重大なバグの修正をリクエストします。

ステージ3.開発

復習

開発プロセスは、一連のマイルストーンで構成されています。 各マイルストーンは、計画された機能をサポートするアプリケーションのバージョンのリリースで終了します。 開発フェーズの最後のマイルストーンは、アルファ版のリリースで終了します。


アルファ版は、バグが含まれていますが、使用できるアプリケーションを指します。

マイルストーン

各マイルストーンの間に、次の作業が実行されます。

1. 作業計画
   
   1. 2人日から1人週までかかります
   2. リードプログラマーによる演奏
   3. 個々の要件について顧客と集中的に議論する必要がある場合があります
2. 開発（4〜5週間かかります）
3. バグ修正（1週間かかります）

タスク

マイルストーン計画では、マイルストーンの終了までに行う必要のある作業がタスクに分割されます。 タスクが評価され、タスク自体がタスク制御システムに入力されます。 このようなシステムとしてJIRAを使用していますが、これは重要ではありません。 代わりに、無料のRedmineから高価なDevTrackまで、他のタスク制御システムを使用できます。

すべてのタスクは、条件付きで2つのカテゴリに分類できます。各カテゴリは、計画された作業の特定のビューを反映しています。 私たちの場合、それは次のとおりです。

1. カスタムタスク
2. 技術的なタスク

カスタムタスク

カスタムタスクは、達成する必要がある最終結果によって決定されます。 この結果はエンドユーザーに明確に表示されるため、ユーザータスクはQAエンジニアによって簡単に確認できます。結果はそこにあるかどうかにかかわらず、確認できます。

そのようなタスクの例：

• ドロップダウンパネルを作成して、テクスチャを選択します
• カラーピッカーを追加する

ただし、利点に加えて、ユーザータスクには欠点もあります。評価が難しく、依存関係が循環する可能性があります（たとえば、タスクBを完了するには、最初にタスクAを完了し、タスクAを完了する必要があり、次にタスクBを完了する必要があります）。

カスタムタスクは2つのカテゴリに分類できます。

1. プログラムの特定の観察可能な部分、たとえば、別個のウィンドウ、複雑な制御要素、または何らかのサービス機能（たとえば、ドキュメントを特定の形式にエクスポートする）を特徴付けるタスク。
2. 最初のカテゴリのタスクを完了するための基準を指定するタスク。

基準タスクは、ある種のチェックリスト項目です。 QAエンジニアはそれを実行し、条件に応じてボックスをチェックし（項目が完了している場合）、すべての「チェックマーク」がチェックされている場合は親タスクを閉じることができます。

注：基準タスクは、最初のカテゴリのタスクのサブタスクとして実行されることに注意してください。

基準には次の3つのタイプがあります。

1. コンポーネントの構成を記述する基準（個別のフォーム、個別のコントロール）
   このような基準を策定するときは、次の質問を自問する必要があります。
   
   
   • コンポーネントは何で構成されていますか？
   • どの要素が含まれていますか？
   
   
2. コンポーネントの主要な視覚特性を特徴付ける基準
   このような基準を策定する際には、次の質問をする必要があります。
   
   
   • 背景コンポーネントは何色ですか？
   • テキストは何色ですか？
   • どのフォントが使用されていますか？
   
   注：すべての視覚特性を最小の詳細にリストしないでください 。 これは面倒であり、必要ではありません。 重要な特性のみ、または標準の特性とは異なる特性のみに注意を払う必要があります。
   
   基準を策定する目的は、コンポーネントの詳細な説明を細かく作成することではなく、タスクを「閉じる」前にこれらまたはそれらの特性を確認することを忘れないようにQAエンジニアの注意を引くことです。
   
   例 背景色、テキストの色、ウィンドウのフォントが標準のものと変わらない場合、これらすべてのチェックは単一のタスクとして定式化できます。
   
   背景色、テキストの色、ヘッドセット、およびフォントサイズがマニュアルと同じであることを確認します。
   
   
3. 行動を説明する基準
   そのような基準を策定するとき、次の質問をする必要があります。
   
   
   • 要素は何をしますか？
   • 特定のユーザーの露出にどのように対応しますか？
   • 要素を特定の方法で動作させるために、ユーザーは何をすべきですか？
   • 要素の動作は時間に依存しますか？
   • ユーザーはアクションを元に戻すことができますか？
   
   例
   
   
   • ユーザーとして、Gridボタンを押してグリッドの表示を制御できます
   • タイトルの左側にある矢印をクリックして、リストを展開または縮小できることを確認します

技術的なタスク

技術的なタスクは、特定の要件または特定の要件グループの実装に関連する作業に関するプログラマーの見解を反映しています。 それらはアクションプランの要素であり、技術用語で、または少なくともプログラマの辞書で表現されます。

技術的な問題の例：

• ...を担当する、または担当するクラスを開発する...
• ...
• 検索アルゴリズムを改善する...

技術的なタスクは評価が容易であり、結果の評価はより正確です。 また、それらからワークフローを形成することもでき、それらの間の依存関係を考慮して解決することは簡単です。

ただし、検証はより困難です。 多くの場合、技術的なタスクの結果はエンドユーザーには表示されません。 目立つようにするには、一連の技術的なタスクを完了する必要がある場合があります。

チームが6人以上で構成されている場合、技術タスクとユーザータスクを同時に使用することは正当化されます。 この場合、費やされた条件と時間は、技術的なタスクと結果-ユーザーのタスクによって推定されます。 , , .

. , .. QA-. . , .

JIRA . , — .

:

• 
  , .
  
  
• 
  - (- — feature), .
  
  
• ,
  .

コードレビュー

. . . , .

, , :

1. -
   — . ( ) . . - . . , - .
   
   
2. 
   — change list. , .
   
   
3. 
   : ( ) , , . . .
   
   
4. 
   — . . .
   

. QA-, .

QA- . . , QA- . , - .

QA- , . - , . — -. , , QA- , , . なぜこれが重要なのですか？

-, QA- , , .

-, - , “” .

. :

• ,

.

護衛

復習

, , . . , , , , , .


-, -, — .

. , , . , , .

3-4 . , . , . , .. .

, , :

, — . , , .

? . :

• 何が邪魔ですか？
• ?
• ?

, .

. , , , features, - , , , — .

.

おわりに

. . . “” , .

2 : — , — 3D-. . , , . .

2 : 1- , , 4- 1- . 6 — 7 . , , , .

.