001002003

004005006

現在の仕事 （複数可）

研究職・教育関係

ユーザ企業

会社員

開発会社

研究職・教育関係

会社員

専門分野（複数可）

情報システム専門分野なし情報システム情報システム情報システム

情報通信ネットワーク

大会のプログラム

友人の紹介

その他（会社参加）

このイベントをどのようにお知りになりましたか。（複数可）

Aチーム

Bチーム

Cチーム

010

011

012

大学院

研究職・教育関係

研究職・教育関係

専門分野なしセキュリティ

情報システム，その他（情報教育）

コンピュータサイエンス，ソフトウェア工学，情報システム

大会のプログラム

友人の紹介

その他（児玉先生）

大会のプログラムその他

大会のプログラム研究会からの案内
ゆるい連携

サプライチェーンの革新/わかりやすい 材料の調達に特化していた.。
プレゼン.ユーザオリエンテッドなデザインフレームワークだった。

顧客のやりとりを全体として短くすると 設計等の重要な仕事のために凡雑（編 ゆるい連携いう視点
集注:原文ママ）な作業を裏で行い時間とコストの削減になるものだと思う.

この作品のよいと感じたところ，惜しいと感じたところはどこですか。

各メーカーの仕様インタフェースが合っ システムをイメージしずらかったていない問題が明確.スペック指向による解決の実現性と実現主体が弱い.

実現可能性に疑問あり

革新的なサプライチェーンのアイデア システムで完結しない部分の解決にがあるので実現できるおもしろい.サプ は，現物合わせとなる点が惜しいと感ライヤーのデータをどのように収集する じた。
かポイントですね

顧客ニーズと管理する仕様とのマッチ ゆるやかな連携によって，入力された ステークホルダーが不明
ングイメージがわからなかった
条件に対する返答が多すぎることになり，それをどうしぼりこんでいくかという部分が気になった。

作品の特長は何だと思いますか。

顧客中心主義によるオープンなステー 外部を含めた連携クホルダー情報共有すべてを満足させようとして軸が定まっていない.

顧客中心

すなお

作品の特徴は何だと思いますか。

ドキュメントがしっかりしている→安心感を与える.

この作品のよいと感じたところ，惜しいと感じたところはどこですか。

デモもあり，わかりやすかった.

ものすごく大きなシステムになると思う. セールスポイントがややわかりにくいコストを考えた方が良いかな.

この作品のよいと感じたところ，惜しいと感じたところはどこですか。

エキスパートシステムな感じを受けた.
知識管理はむづかしいのでは?

WBSと改善知識のフィードバック方法が弱い.

この作品のよいと感じたところ，惜しいと感じたところはどこですか。

アイデアが部分的情報システムのデザインの"よさ"は，おもに何で決まると感じましたか。

このような取り組みについて，感想やご助言をお聞かせください。

目的と実現方法の明瞭さ

最後30分程度しか参加できませんでしたが，なかなかおもしろかったです。第2回に期待しています。

DBをシンプルにしている.業務日誌

実際にヒアリングして，独自の視点を立てたこと各ステークホルダーがどんな情報を見るのかがよりわかりやすいと良いと思う. 学生さんらしいアイデアと文章（ちょっと未熟）はよいところと惜しいとろがあった

大人と知識差を，企業にインタビュー， その視点に対する工夫がわからなかっヒアリングしてうめたところ
た

ビジネスそのもの

オーソドックスなシステムで確実に実行 システムの追加が容易なシステムにできるものとしてデザインされている。 なっていると感じた.。

モックアップを提示するなどして，具体性があった.

・進捗管理がわかりやすい・使いやすい（と感じた）
・質問を考えやすかった

今ひとつユーザ（顧客）像がぼやっとし 前提が考えられていてその中でシステていた.システムオリエンテッドなプレゼ ムが考えられている点。細部の前提がンだった。
すくなっかたのが惜しいと思った。

WBSベースの知識共有の有効性が，イメージしにくかった.

BOMの適用，知識ベース

施工管理は特に限定した点（編者注:原文ママ）

細部の技術まで考慮されている.

製造業の知識を建築に応用したところアイデアが明確になっている〇ノウリッジのPDCA化に注力した点
×前説明が長かった

実装まで考慮させている。使われるシステムになるかはプレゼンからはわからなかった.

標準と実績の差をどう管理して，改善につなげるのかがわかりにくなかった.

リスク管理

業務範囲の明示，エンドユーザへの請 ・ユースケース，設計モデル図がよく整求範囲の明示理されていた・リスク評価に重点をおいている

採用される業者によって，リスクが変わるという視点実現可能性についてやや疑問

どのようなシステムになるか，全体像が キチント（編集注:原文ママ）入力されたかからなかった.
データがあると動くしくみだと思います

・リスクが定義づられてない気がした・説明の幅が広すぎたか

何を結果として出すかを明確にした方 コンセプトとキーとなる実現手法が良い.注目するポイントがバラバラで評価しずらい.

大変面白い取組なので継続して頂きた 良かったと思う。
い

ステークホルダー間で，情報を共有する視点

ヒアリングをベースにデザインされてい ドキュメントがわかりやすかった。
た。

わかりやすかった。 タイムラグは厳し
いと思う.

聞けなかった

実際の建設会社へのインタビューを行ってクオリティーほ高めていた点

聞けませんでした〇現実感をより出そうとした点
×リクス管理逐次開発とControl/Viewの分離による 実現性，拡張性
実現可能性. システム実現自体が目的化

BOMの建築施工への応用

データフローモデリング013

その他（会社経営）

ソフトウェア工学

スペック指向によるゆるい仕様合わせ アーキテクチャ

作品の特長は何だと思いますか。

Eチーム009
研究職・教育関係

情報通信ネットワーク

友人の紹介

この作品のよいと感じたところ，惜しいと感じたところはどこですか。

研究会からの案内

008
開発会社

作品の特長は何だと思いますか。

作品の特長は何だと思いますか。

Dチーム

007
コンサルティング会社

・各チームで作ったデザインのプロセス-作業に費やした時間，各メンバーの役割など-についても共有できると良い.
（授業に今後活用するうえで）・大変，おつかれさまでした.授業でやってみたいと思います.

これまでの課題をシステムによってどう フローがきれいで整理されている事解決したか，セールスポイント，チャー 機能追加が容易な事
ムポイントが明確なもの

顧客ニーズを正しく表現できているか否か.そして，それを顧客が理解できるように見える化できているか否かではないか.

とてもよい。色々な年令，会社，学校が とても参考になった。要件が広くて，シ ITのデザインコンペはムツカシイです 建設でいう目で見えるデザイン，アーキ参加しているのがよい.課題の設定，参 ステムが大きくなつてしまうので，もう少 ね.「デザイン」ということから「システム テクチャとシステムのデザイン・アーキ
加者インセンティブで多くのチームが参 し小さなシステムの提案の方が良いの 設計」や「アーキテクチャ設計」を想定し テクチャには類似点と相違点がありそ加できる様なイベントになるとおもしろ かもしれないていました.今回はどの水準のデザイン う.ここの定義づけは難しいか.あらためいですね!
だったのだろう? システムだろうか? し て，MRP計算は世界最強の計算ロジッ
かし提案内容だけでは「このシステムを クだというこがわかりました.
発注しよう.作ろう」という思いは，もてなかった.「要求」と「設計」その境界はどにある?「設計」は何ができれば「設計した!」と言えるのか.コンペはココ(「設計した!」）を狙ってほしい.

業務のリアル反映

リスク管理にフォーカスを当てようとしていること.（編集注:原文ママ，このチームの欄に記述）

そのリスクをどう貯めるか，工夫必要（編集注:原文ママ，このチームに欄に記述）

印象がうすいステークホルダがわからず，特長がわからなかった.

顧客と開発のビミョーなバランス

実現性と戦略的視点

せび続けて下さい.

勉強になりました.