Aチーム

Bチーム

Cチーム

Dチーム

Eチーム

事前アンケート
訴えたい特長、コンセプトは何で 施工管理を行う上での課題の一つとして、扱う部材・設備が超多品種・少量生すか。
産であることが挙げられる。本書では、上記課題を解決するため、部材・設備情報に関するDomain、仕様をもとにした「ゆるい連携」を行う「Spec指向」アーキテクチャを提案する。（提出文書「概要」を引用）

施主と関係会社のみならず、戸主による個別の施工管理も実現した統合WBS 建築の施工とは、建物の「製造」ととらえ、製造業の工程管理のノウハウを施共有システム
工管理にも適用できると考えました。マンションを建てる工程（製造業でいう製ビジネス運用から、評価、情報システム化までを一体的に管理可能な情報モ 造工程）のルールを知識とよび、知識をもとに作業予定を生成、実績の記録、デル予実の分析で、知識を改善する、という「知識」を軸としたシステムです。
開発、運用だけでなく、知識管理までシームレスに結合できる適応型情報シス
テム

利害関係者ごとに想定される効果は何ですか。

施主（デペロッパ） 高付加価値マンションの実現によるビジネスへの貢献・ブラ マンションの購入者：カスタマイズオプションが増える、予算や工期のシミュレー 半蔵門建設：遅延リスク・品質未達リスク・原価オーバーリスクの見積もりノウ
ンド価値向上ションができる
ハウを全社レベルで共有し，業者選定やWBS作成に反映できるようになる．こマンション購入者 ５つの付加価値(美・快・安価・安全・維持)の提供による満足 ディベロッパー：購入者の満足度が上がる
れにより顧客に対して高い信頼性を提供することができるようになり，満足度を度向上
設計事務所：工期のシミュレーションが可能になり、素早いフィードバックを受 向上させることができる．
工事設備建材メーカ 技術・ノウハウの共有。各関連部門の特徴を戸主への付 け取れる
施主：対応可能な内装カスタマイズの幅が広がり，顧客セグメントを拡大するこ
加価値に反映施工管理者：カスタマイズしても標準のWBSを作成できる、施工工程のノウハ とができる．また，特殊な内装カスタマイズへの対応により他社に対する競争
半蔵門建設各部門 ノウハウ共有。システム管理負荷の低減
ウを標準化できる力を持つことができる．
調達部門：施工に必要な材料や人材の数量が把握でき、最適な調達を行える 戸主：自信の希望に沿った内装カスタマイズを実現することができ，満足度が向上する．

施工業者側：部材が超多品種・少量生産かつマンションの保守期間が長期に及ぶことにより発生する課題を解決する。
施主側：カスタマイズの要求の確定、調達の調整、施工の調整等の作業が長期に及ぶ課題を解決する。

提案システムのコンセプト：蓄積した過去の取引実績に基づいて納期や施工品に関するリスクを予測し，業者選定やWBS作成に反映することで，要件に対して最適な施行計画を立案することができる．
システムデザインのコンセプト：ビジネス環境やシステム要求をシステムモデルとし記述し，システムアーキテクチャを構成する要素として整合性をとりながらデザインした．

うまくデザインできた、評価してほ システム間を共通仕様（ドメイン）を介する変換でつなぐ仕組み。
しいと思うところはどこですか。

WBSを統合的に扱えるようにしただけではなく、知識管理も新たなシステムを 建築業界にはすでにWBSを作成するための知識があり（※書籍より）、施工工 ビジネス要求を適切に分析し，それらを満たす戦略として「リスク計算」というコ作らずに同様に扱えるようにしたこと。既存システムとの連携や運用後の拡張 程を知識化するという考え方に適していると思った。また、知識を軸に成長する ンセプトを打ち出し、共通問題文書に記述されている内容に沿った単なるWBS等を考慮したシステムとしたこと。
システムを構築する点に着目してほしい。
作成システムとは一線を画すところ．
ビュー部分のモックアップおよびIoTのデモ
さらに，システムデザインにあたっては，世界標準に則ったシステムアーキテクチャとして成立する，信頼性の高いモデル群を構築したこと．

デザインに懸念点があるとしたら 共通仕様（ドメイン）の作成をどのように実施するか。
どこですか。

費用対効果も含めた実現性が検証できていないこと。

デザインの作業はどのようにおこ 週に1回のMtg（オンライン、オフライン）＋個人作業ないましたか。

チーム内で打ち合わせ、全体のコンセプトと作業分担を決めたあと、各担当で チーム内でコンセプトコンペを実施し、システムのコアになるコンセプトを擦り合 本チームは複数の大学やスタートアップ企業のメンバーから構成され，活動拠執筆し、全体でレビューわせた。その後、要求関連図や業務シナリオを作成し、構想を膨らませ、業務 点も分散していた．そこで，基本的には明確な役割分担のもとに各組織がそれ出来上がったデザインに対応して、モックアップ、デモ作成
分析としての業務フロー図の作成、サブシステムの構成、ドメイン内のモデリン ぞれデザイン作業を進めつつも，クラウドサービスなどを上手く活用して協調グ、ユースケースの抽出、作成を実施した。
性を保つことで，組織横断・分散拠点での作業を可能にするよう工夫した．

参考にしたデザインの方法論、手 OSLC、QVT等
法はありますか。

各種記法(SysML、UML、Mindmap他)を利用
デザインパターン(GoF)、アーキテクチャパターン（POSA）

弊社で実施している企業情報システムの設計手法。上記のデザインの作業が ・ソフトシステムズ方法論
その手順であるが、システム思考的アプローチを採用している。仕事・機能の ・オニオンモデル表現
設計では、もの・こと分析や、Martin Fowlerのアナリシスパターン、アーキテク ・ISO/IEC15288などの世界標準ティングでは、関心の分離や一般的な設計原則（高凝集性、疎結合）。

マンション施工に関する業務知識 業務経験、施主としての経験、書籍はどのように得ましたか。

社内の識者および、そのつてで建築業界の方からのご意見→仮想のインタビューとして提案書に反映
インタネット上の業界誌、Webページ、建築施工事例等
書籍の「建設ITガイド2016」（どのような技術が施工でのITトレンドなのかの情報収集）

インターネット情報の検索、書籍、知人の一級建築士（現場監督）へのヒアリン ・大手住宅関連会社による施行管理システムの特許出願書類（WEBから閲覧）グ。
・参考書籍（花輪如一著：マンション建設の教科書）
・最近住宅を購入したチームメンバーの体験談

建築業は、製造業と異なり、まったく同じ建物を建築することはなく、その場合 実装可能な粒度のモデルまでブレイクダウン可能なアーキテクチャになっていの知識をどのように表現するかは、検討の余地がある。
るかどうかという点．
情報システムの設計ではクラス構成やデータ構造の設計が重要であるが，そこまで踏み込んだシステム設計には至らなかったところ．

事後アンケート
自分たちの作品で工夫すべきと感じた点はどこでしたか。

Domain を半自動で獲得する仕組みの考案は、今後も工夫を続ける必要があ リッチピクチャのウケがよく、聞く側にも伝わりやすい手法というとは今回のコン ・真面目に課題に対応しすぎた。もう少し、設計範囲を絞るべきだった。（A氏） A氏:顧客向けのプレゼンならば、情報システムデザインの手法についての説る。ルールベースでのメンテ ナンスの継続には限界がある。
ペでわかった。そこから、デモ作品を作らずとも絵にしてどのようなものを作ろう ・時間的な制約の中でのデザインであり、まだまだ手を入れたい部分がある明は不要だった。ヒアリングを実施した点は、聴衆にとってポイントになることと考えているのかを伝えることがよりよい発表につなげられるだろう。
が、今回のコンペへの出品ということでならば、もう少し簡素化してポイントを強 が分かったので、実際にヒアリングした、とか、実際に試してみた、などは積極調できると良かった。（B氏）
的にアピールすべきだと思った。
B氏:課題をきっちりと守って設計していたので、他チームよりも地味な提案になっていたような気がする。課題を守ることよりも創造的なアイデアを設計したほうがよかったのかもしれない
C氏:客にとってのメリットのアピールが足りなかった。
限られた短い発表時間であったので，メリットにフォーカスすべきだった。

提案システムの工夫すべき点：「納期や施工品に関するリスクを予測する」シス
テムでしたが，具体的にどのようなリスクを予測するのか，それによって誰にどのような利益がもたらされるのか，詳細にデザインし，整理できていればよかったと感じました．
システムデザインの工夫すべき点：クラス構造やデータ構造など提案システムをどうやって実現するかとというところまで踏み込んで情報システムのデザインをできていればよかったと感じました．

他のチームの作品を見て、どのよ 提示された要件の範囲外で何を仮定するかにより、作品に変化が生じると感じ 重要な点を模造紙にまとめ、細かな資料は手元のファイルにまとめることで発 ・あまり見る時間が無かった。ある部分、ユースケースに特化して、デザインの A氏:業務説明書のどこにポイントを置くか、が全く異なると感じた。今回、ワー 他のチームは実際に半蔵門建設のように内装カスタマイズを行う業者やそのうに感じまたか。
る。言い換えると、何を「発想」するかにより「違い」が生じる。
表に要点のみを伝える手法をとっており、自分たちもこの手法をすれば信頼度 特長をアピールしているチームが多かった。(A氏)
ルドカフェ内では質問できなかったが、なぜそのポイントに絞ったのか、なぜそ 関係者，利用者にインタビューを行い，その調査結果をうまくシステムデザインが増すなと感じた。一方で、開発者目線に偏ったシステムであると感じた作品 ・追加の要求事項を扱うのは良いと思うが、問題文から読み込める要求事項 の提案にしたのか、を聞いてみたい。に活かしている点が，自分たちのチームとは異なると感じました．インタビュー
もいくつかあり、自分たちのシステム構築を考える際には初心を忘れずにユー への対応は十分ではないように感じた。（B氏）
B氏:アイデアは理解できたが、設計として優れているかどうかを判断すること の結果から何に焦点を当ててシステムデザインを行うか決めることで，デザイザ志向なデザインを心掛けたいと感じた。
はできなかった。また、チームによって全然違うポイントで説明していて、実際 ンした情報システムの有用性がより明確に示されていると思いました．また実のコンペもこんなふうに評価軸がぜんぜん違う提案の中から選ぶのは大変だ 際に情報システムを作成しているチームもあり，実装を意識したデザインが行ろうと思った。
われている点も，我々と異なると感じました．
C氏:出題文の内容には沿わない提案であったが，各チームの特徴が出ていて面白かった。
情報システムの"よさ"は、おもに デザインに単純な“よさ”はない。デザインは、「発想」により「違い」が生じる。こ 開発者側(デザイナ)の共通された思考の徹底とそれに対するユーザへの伝達 ・機能、フォルムも必要であるが、いかに簡単に変更、改善、拡張できるような A氏:情報システムの有機性（全体がイメージできて、適切に分割され、構成し 情報システムのデザインの”よさ”は，現在の業務に情報システムを導入するこ
何できまると思いましたか。
れは、性能最適化であれ、機能集約であれ、同じことである。これは個性のよ 率ものが、情報システム特有の「よさ」でないでしょうか。（IEEEのsoftwareている各部分が、互いに密接な統一と連携がされている）が高い状態だと思い とによって，何が変わるかが明確な運用コンセプトをデザインできるか否かでうなものであり、単純な比較はできない。
architectureの定義IEEE1471でも「そのシステムのコンポーネント群と、それら ます。また、利害関係者にとって、プラスになるものがよい情報システムなのだ 決まると思いました．その運用コンセプトを実現する機能・物理コンポーネントのコンポーネント間の関係及び環境との関係」だけでなく、「そのシステムの設 と思いました。
群とそれらのインターフェースのデザインももちろん重要ですが，情報システ計や拡張の指針となる原則」もアーキテクチャだとしている）(A氏)
B氏:建築ではコンペによって「もの」ではなく「デザイナ」を決めると言っていた ムのステークホルダーにどのような価値が生まれるのか，明らかにすることが・要求仕様を満たしていること（完全性）に加えて、美学（シンプルさ、コンセプト のが印象的だった
重要だと感じました．またこうした点を意識することにより，コンペ時の発表も分の訴求力、等）という主観的な要素を組み合わせた視点で決まるのではないか コンペで「もの」を決めてしまうと、その「もの」をつくことが目的化してしまうよう かりやすくなるのではないかと思いました．と思います。（B氏）な気がした
コンペで「デザイナ」を決めることによって、話し合いの中でよりよい提案をしてくれそうな伸びしろをみせることが大事かなと思った。
C氏:企業で働く人達全員と情報システムとの関わり方が評価の対象となると感じた。関わり方の評価は，① 自分たちがその情報システムの中で働きたいか（主観，直観的であるがこれが一番大事な気がする）② 全体としての意思を感じられるか③ 全体が適切に分割され，適切につながっているか④ 全体の情報流が整合性を持って淀みなく流れているか⑤ 企業のビジネス目的に適応したものになっているか
そのためには，対象企業のビジネスとビジネス目的をインプットに，対象企業の論理アーキテクチャ図と概念モデルが必須の設計図になると改めて思った。

このような取り組みについて、感 以下は、チーム内の1メンバの意見である。
今回のコンペによって情報システムがデザインされなければならないほど、社 ・非常に良い取り組みであり、ぜひ、継続して開催していただきたい。(A氏)
A氏:発表時間について：発表者として、7分では伝えきれない部分が多かった 今回はこのような機会を設けていただき，ありがとうございました．同一のテー想やご助言をお聞かせください。 1. ソフトウェア開発にデザインコンペを持ち込むことのマイナス点の考察
会に必要とされていて、なおかつシビアなビジネス商材となっていることを知っ ・会場は、快適で、備品等にも問題が無かったと思います。(A氏)ように思います。しかし、聴衆としては、ポイントが絞られた、引き締まったプレ マに対して，複数のチームがそれぞれ情報システムをデザインするという機会ソフトウェア開発において、建築で行われる「デザインコンペ」を持ち込むことに た。ただ、今回の授業を通したコンペ参加によって情報システムデザインをしっ ・問題は、今回のようなコーポレートレベルのものではなく、ある情報システム ゼンになるのかなと思いました。参加者について：業務説明書が読まれていな は普段あまりなく，他の方からフィードバックをいただけるという点でも，他のは反対である。少なくとも以下の2点において、「隠れたカリキュラム」となり、学 かりと本質的に考える重要性や意義を深く知れた気がする。このようにコンペ に関連したConOpsとして提示し、回答となるデザインが比較可能なものにする いような質問が多かった。今回は、誰でも参加可能だったため、当日ふらっと チームのデザインを見ることができるという点でも，大変有意義でした．特に習者に対し悪影響がある。
は私達学生にとっては非常に有意義であり、学びの多いものであった。だか べきだと思いました。（A氏）
参加した方でも、分かるような説明を目指したが、きっちり読んでいる人と読ん ワールドカフェ方式での発表と意見交換は，発表者をした私自身が，様々な視ら、これから情報システムデザインのコンペが開催される際は是非学生と社会 ・コンペでの審査では、どういう観点で審査するのかを明確にしたほうが良いよ でいない人向けの説明は異なるため、説明の粒度の設定が難しかった。
点から自らのチームの情報システムについて考え，理解を深めることができま(1) ソフトウェア開発におけるデザインとコーディングは、建築におけるデザイン 人が混ざった今回のような形式を続けてほしい。
うに思いました(A氏)
設計者どうしのセッション：前提条件も話さなくてよいし、一番楽しかった。継続 した．一方，我々の準備不足や発表時間の制約もあり，事前に提出したデザイと施工のように分離できる、という誤解に繋がる
また、社会人の率直な感想や本気でつくられた作品に対して本気で学生が取 ・参加者は要求仕様書を読み込んでいるという想定とのことでしたが、実際は してほしい。もっと活発に設計者どうしで議論できる場があると良い。
ン文書の「3.システム要求」や「4.検証」について，モデル図などを用いて発表・
コーディングはデザインの一部である。これに対しては同様の主張が沢山あ り組んできたものと比べるという機会がこのコンペ参加での学びの深さをつけ そうではなかったので、質疑内容がぼけてしまっていた。審査員もコンペにする 業務構想書について：実現方法が指定されていたので、もっと自由に発想でき 意見交換を行うことがあまりできませんでした．運用コンセプトのみならず，シる。[「コーディングは設計か製造か」という考え方の違いた要因だとも思ったのでこれからもこの取り組みは続けていただきたいし、大き 等の工夫があると良いと思います。（A氏）
るようなテーマなり、記述内容のほうがよいと思った。また、現実とは異なる設 ステムの機能や検証方法に関して，もっと議論を深めることができればより有](http://tsuyok.hatenablog.com/entry/2013/03/21/235525) 建築において、デ な意義を持っていると感じました。
・コンペ後他の参加者から、モデリングがしたいという意見を聞いた。今回のシ 定だったため、少々混乱した。まとめ：デザインを伝えることに向き合える良い 意義なコンペにすることができたと思います．
ザインと施工を分離できるのは、施工が物理制約を強く受けるがゆえに、物理ステムコンペは、かなり以前に開催されたモデリングワークショップとは異なる 機会となりました。ありがとうございました。
今回はISO/ISE15288準拠のシステムズエンジニアリングに基づいた情報シス的な基準、標準を策定可能だからである。これは、ISKENチームにドメインエキという認識であるが、その違いがあまり認識されていない様に感じた。この点
テムのデザイン方法やモデリング言語・ツールの使い方を復習するとても良いスパートがいなくても、 書籍「建築工程表の作成実務」をもとに工程表を作成は審査基準の整備が進むと解消されると思います。（B氏）
機会となりました。また、このような機会がありましたら是非ともよろしくお願いできてしまうことでも分かる。
します。
一方、ソフトウェアは物理制約が少ない。デザインの成果物もコーディングの成※アンケートのフォーマット改善要
果物も「情報」である。情報の解釈は、個人の解釈能力に依存する。よって、コーディングの段階になっても、個人の解釈能力の差により成果物の品質には大きなばらつきが発生する。結果として、高精度な標準工程は作成できない。
デザイン以降の作業が標準化されていないのに、デザイン以降の作業を他者に依頼するという考えには無理がある。デザイン段階での後工程の見積もりが、建築同様にはできないからである。

(2) 建築業界になぞらえて、「デザインだけでビジネスを成立させる」という考えは、多重下請け構造を容認、助長しかねない[これからの「SIer」の話をしよう － ITエンジニアが生き延びるための処世術](https://thinkit.co.jp/article/10634)など、「ゼネコン型」多重下請け構造の害に関する話題はたくさんある。「ゼネコン型」も「デザインコンペ」同様、建築のメタファの悪影響である。 個人的な技術講師の経験から言えば、設計講座に対する要望として、SIer、ユーザ企業からの「設計書のレビュースキルを身に付けたい。ただし対象者はコーディングスキルがない」という相談を受けることが複数ある。コーディング作業を他社に任せた結果、このような相談をすることになるのである。 建築のメタファを適用するのであれば、そのマイナス面も考えないと、ソフトウェア教育としては「悪い」ものになる。

2. なぜ、建築では「デザインコンペ」が必要なのか?
建築においてデザインコンペが必要なのは、何より「実際に同一敷地に建築して同時に比較することが不可能だから」である。 対して、ソフトウェアは「実際に構築したものを比較することが可能」である。このことは、今回 ISKEN、cgems両チームが、実際にデモとして、稼働するソフトウェアを持ち込んだことからも明らかである。この2チームのデモが説得力を持っていたことからいっても、「実際に構築したもの」と言えるはずである。
3.「デザインコンペ」の改善課題抽出
冒頭の基調講演でもお話のあった通り、「デザインコンペ」が失敗するとしたら、運営側の準備不足によるものが大きいと考えられる。
(1) 題材選定のまずさ
施工管理システムは、現在クラウドサービスも含めてたくさんある。DevOpsすら必要ない場合が多い。マスカスタマイゼーションの実現例も複数ある。建築業界で標準化され、新規性のない題材を扱っても、デザインを競う効果は限定的である。ISKEN、cgemsともに既存成果物のマッシュアップである。その程度で実現できる題材なのであれば、コンペにて競争する点は開発費用くらいである。
(2) 評価者の不在評価者の中にマンション建築のドメインエキスパートがいない。これでは「コンペ」として成立しない。 要件にない事項を勝手に仮定してよい、としたことも、適切な評価者(要件に責任を持つ人)を定めていないがゆえである。ISKENの、CoffeeScriptによる拡張方式は、半蔵門建設の要件に対する仮定と して妥当なのか。セキュリティ上の問題はないのか。こういった慎重な講評が行われなかったのは、 まともに評価者が意識されていなかったからであろう。

(3) 評価基準蓄積手段の不備
評価者にシールを貼ってもらうだけでなく、「何が良かったのか」「何が悪かったのか」のコメントをもらう仕組みを作るべきだった。今回のデザインの評価基準は、「参加者が貼ったシールの数の多さ」 だけである。これでは「何が良いから」評価されたのか分からない。 評価の理由が不明なのでは、デザイナ同士でさらに良いものを作る参考になり得ない。最もシールを集めた学生チームに対する主催者のコメントが「学生ががんばって発表していたから」というもので あったところからも、「デザインを評価する基準」の「実践的な検討」に失敗した様子がうかがえる。

B氏:評価者が課題を読んでいないと困る
評価者が発注者よりだったりITの専門家だったりして誰向けへ説明したらよいかわからなかった評価者もどう評価したかを述べて、その評価軸が適切かどうかも意見交換してみたかった
一般の評価者よりも設計者同士で意見交換する方が、苦労や工夫したところが共感できて楽しかった。コンペの種類を決めたほうがよい（アイデアコンペ、DB？DBOコンペとか）懇親会が楽しかったので、今度はプログラムに組み込んでほしい（学割ありで）
C氏:提案者も，全てのチームのプレゼンを聞けるようにして欲しい。
コンペの種類を決めて，もう少し，同じ視点で提案を見られるようになると良いと思う。企業のビジネス目的がはっきりしており，ビジネス特徴がある題材でのアイデアコンペがしたい。設計者同士のディスカッションは，とても良かったので継続して欲しい。

4. 課題に基づく改善点(1) 例えば、課題を「『デザインコンペをサポートする、盛り上げる』ためのシステム」とする。
これなら、ドメインエキスパートは自分達である。また、既存システムの流用ではなく、「新規性」を競うことができる。
(2) 評価者にはシールではなく、「良い点、悪い点を書き込む付箋」を渡す。
評価基準を実践的に検討するのならば、評価者としてのコメントを求めるべきである。
5. ソフトウェア開発における、理想的な「デザインコンペ」とは何か
本来、ソフトウェアのデザインは、優劣をつけるものではなく、「創発」するものである。よって、「プログラミングコンテスト」の中で、設計成果物を比較検討するのが理想的であると考える。コードのみの評価では、開催期間内での性能最適化が優先されがちである。一方、設計成果物はもっと長期的な保守性を狙ったものが評価されてよい。
6. ソフトウェア開発における、より良いメタファは何か
ソフトウェア開発は情報を作る。建築は建築物を作る。この最終成果物の違いを無視したメタファの 適用は弊害を生む。ソフトウェア開発を学習する上でメタファを適用するのであれば、建築の分野での活を盲目的に実施するのではな
く、よりよいメタファを探求すべきである。成果物が最終的に情報となる、大規模な開発活として、たとえば「映画製作及び制作」が考えられる。