---
# System prepended metadata

title: メディアドゥ givery側での確認事項

---

# メディアドゥ givery側での確認事項
- 前半5日間の2~4日目の個人ワーク、グループワークにおいて、個人スキルの見極めはどこまで可能なのか
    - 森さん以外にもメディアドゥ側でオブザーブを立てたほうがいいのか？
        - これは必要。見極め基準はやはりその会社特有の視点があるため。（森追記）
    - 森さん1人の場合に取れる情報、メディアドゥからアサインした場合の2パターンでシュミレーションがほしい
        - 森一人の場合：デザインスプリントとしてアイディアを「発散」させる量はどれくらいか、「収束」させる場合の思考量はどれくらいか。すなわち、「思考量」の大きさは測れる。（森追記）
        - メディアドゥからアサインした場合：アイディア自体の独創性といった「発想力」の大きさ。これは主観が入るため、森が行うべきでは無く、メディアドゥが求めるベクトルの発想力を計測するため、メディアドゥの社員が見極めすべき。（森追記）
    - もし過去の他社の事例があるならほしい
        - 各社の評価基準に合わせて評価をしてもいいのであれば、それに沿った形で見極めることができる。直近では2事例あり。（森追記）
- メディアドゥの新規事業担当を10日間の企画にアサインできそう
    - どのタイミングでアサインするか？
        - アイデアソン
        - 前半5日目の中間報告
            - ここがよさそうです。上記の「発想力」の見極めをしつつ、効果的なレビューを期待したい。（森追記）
        - 後半5日目の最終報告
        - デイリーのワーク
        - その他
- 後半5日間の3日目のコードレビューはどのように行うのか？
    - チームの選択した言語にメンターが詳しくなかった場合はどうするか
        - 言語非依存の内容をレビューすることを検討する。保守性、拡張性など設計に関する部分。（森追記）
    - 具体的にはどんな内容をFBするか
        - 書き方なのか、エンジニアとしての姿勢なのか
            - 学生が日頃意識していないお作法にプロフェッショナリズムを感じさせることができればいい。戦い方はいくつかある。①その言語特有の知識での勝負。（ただしあまり効果的でない）②上記に示したように、設計に関する部分。言い換えると、チーム開発を前提とした部分。③品質保証に関係する部分。TDDを意識しているかなど。マーケットにリリースされる製品として意識しなければならないお作法で魅力付けできたらいい。（森追記）
    - デザインスプリント後の開発で主に使われるプログラミング言語は過去の事例から出せるか
        - その時に集まったメンバー次第だが、なんらかのフレームワークを使うパターン、PHPに行くパターンが多い。（森追記）
    - もし技術スタック的な相性の問題でコードレビューが不可能だった場合はなにかで代替できるか
        - 上記の通り、設計および品質保証の部分で代替可（森追記）

- 最終成果報告における審査基準はどうするか
    - 優秀チームを選定するのと合わせて、100万円分の電子書籍をプレゼントする1人を選定する必要がある 
        - これから議論だが、基本的には総合的な評価＋メンバー間の他面評価などを組み合わせて複合的に順位付けすればいいのではないか。例えば以下。（森追記）
            - trackスコア
            - デザインスプリント評価
            - 個人開発評価
            - チーム成果物評価
            - チームメンバー間相互評価