1.　はじめに

2010年当時の富士ゼロックスでは，異業種グローバル企業の複合機市場への参入，中心とする市場がアジア新興国市場に変化したことによるコモディティ化といった変化からメーカ企業として成長に危機感があった．また，IT技術の浸透，進化により顧客要望が多様化，複雑化し，主力商品である複合機（Multi Function Peripheral，以下，MFP）とそれを活用したソリューションにおいても顧客要望との乖離がみられることが多くあり，解決の糸口を探索する必要があった．

この問題への取り組みの一つとして，直接お客様と対話することにより，経営課題や潜在ニーズの発掘，解決に向けたアイデア創出，最終的な事業化を目的としてお客様共創ラボラトリーを2010年に開設し，官公庁，教育機関，非関連企業と直接対話する活動の取り組みを進めている[1]．

こうした共創は米国ミシガン大学のプラハラードらが2004年に“価値は消費者と企業が共創する”[2]と提唱したことが起源とされており，2019年にも日立製作所や資生堂といった企業から，顧客共創が可能な新たな研究開発拠点の発表などが行われている[3], [4]．しかしながら，共創という言葉が広く使われているにもかかわらず実践的な報告が多いとはいえない．

そうしたなか，富士ゼロックスと法政大学が2012年から2018年にかけて実施した表1に示す活動が，顧客共創活動に取り組む企業組織への参考になると考えた．本稿では共創開発に至る経緯とともに，(1)プロトタイピング，(2)商品開発，(3)商品化後の機能追加と保守，といった商品化するまでの三つのフェーズで実践した6年にわたる共創について概要を示す．そして，それぞれのフェーズにおける役割分担を整理し，大学と企業の共創のあるべき姿を考察する．

2.　共創開発に至る課題

2.1　大学教育用ソリューション開発の課題

ユーザの業務課題を解決するシステムやサービスの開発は，ユーザへのヒアリングをもとに開発を担当する企業が要求定義を行い，ユーザに確認を図りながら開発し最終的に納品する形で共同作業的に行われる．しかしながら，大学教育用ソリューションは企業と大学が共同でシステムを開発しても，最終的なユーザである教員が求めていたものと合致せず利用されないことも多い．

その原因としては下記のような大学固有の特性によると考えられた．

• ・大学事務職員が主体となり教育システムの開発が行われる場合，教員の業務課題を十分に理解できていない．
• ・教員主導でシステムの開発が行われたとしても，研究・学術的な観点が強くなること，特定教員向けに特化しがちであること，システム運用に関しての考慮がされないことが多い．
• ・教員の利用は一般企業のように強制力を持たない．結果として全学的に教育支援システムを導入しても利用率が伸び悩むといった問題の原因となる．

富士ゼロックスでは，2012年当時，大学に特化したソリューションの開発実績はなかったが，導入済みのプリンタや複合機を足がかりとして大学への展開を目指しており，上記の課題を解決する必要があった．

2.2　大学における課題

大学においては，教員が授業内容・方法を改善し向上させるための組織的な取り組みとして，1999年に文部科学省がファカルティ・ディベロップメント（以下，FD）を努力義務として規定[5]したことで，その後の教育改革につながっていく．これを受けて法政大学では2005年にFD推進センターを設置したが，筆者らが所属する情報メディア教育研究センターでも，同時期にITを活用した授業改善に関する研究をスタートした．

米国の大学では1970年代にFDが始まり，1990年代後半から学習管理システム（Learning Management System，以下，LMS）の導入が始まった．法政大学においては，2002年から実験的にLMSを導入し，2011年には米国大学コミュニティで開発されたオープンソースのLMSであるSakaiをベースとした新たな教育基盤を構築した．

本来であれば，米国大学に倣い，日本の教育事情に適した独自の教育基盤を開発することが望まれた．それは，大学自身で開発するシステムは，ユーザでもある教員からの要求にヒントを得て教育理論や先進的なテクノロジを取り入れて開発されるため教育効果が期待できるからである．しかしながら，研究レベルで開発される教育用システムの品質は，企業におけるプロトタイプレベルであり，例え利用されるとしても開発者が在籍する学内の利用に限定されていた．

このように，大学における開発においては，企業レベルの製品の質や継続性を保証できないという課題がある．また，本プロジェクトが開始された2012年は，前年に導入されたLMSが順調に利用されはじめた時期であった．当時の法政大学では，専任教員の利用率が50%程度で頭打ちになっており，さらなるユーザの拡大を検討していた時期でもあった．ロジャースの普及理論[6]におけるレイトマジョリティを含む84%に到達するには，ICTスキルが高くない教員でも利用できるシステムが必要と考えていた．

2.3　共創開発のきっかけ

本プロジェクトは筆者のひとりが在籍していた法政大学の研究センターに，大学関連コミュニティで面識のあった富士ゼロックス市場開発チームの担当者から，富士ゼロックスのテクノロジを使った新しい製品開発を提案されたことが端緒となった．

それを受けて，2012年5月に富士ゼロックスお客様共創ラボラトリーに法政大学メンバが訪問し，顔合わせと同時に現状の課題やシステム動向に関する意見を交わした．その後さらに打ち合わせを重ね，複合機を活用することによって，LMSと紙メディアをつなぐシステムの開発が始まった．

3.　プロジェクト概要

紙メディアは直感的に取り扱うことができるため，スマートフォンやタブレット端末が普及した現在においても，ITシステムと比べて利用が容易である．また，授業において学生が考えを手軽にまとめる際には紙のほうが利便性が高いため，大学の授業でも紙媒体はよく利用される．たとえば，学生の理解度の向上を目的として，授業の終わりに小テストを行い，次の授業でフィードバックすることがある．こういった教材は学生に用紙で配布され，学生が手書きで記入し教員に提出する．教員は学生の提出物を採点し，翌週の授業で学生に返却する．採点の際には各学生の採点結果を，成績評価用の素点データとして表計算ソフトに転記する．法政大学においても，多くの大学と同じように期末には学生ごとに集計された素点をもとに評価し，結果を教務課に提出する．

この一連のワークフローにおいて，100人程度の履修者がいる授業では，用紙の配布，収集，採点に多くの時間がとられ，かつ授業で行った小テストや課題を成績評価のための素点としてまとめる作業が教員の負担になっていた．これらの作業は成績に関係するため注意深く行わなければならず，転記ミスを防ぐためにあらかじめ紙媒体を学籍番号順に並び替えるなどの手順を踏むことが多い．また学生へのフィードバックを目的として採点済テストを学生に返却する場合，返却だけで授業時間の1～2割程度を使ってしまう．さらに，大学の授業の多くは週に1回であることから，小テストから1週間後の返却になる．その場合，学生にとっては忘れたころのフィードバックとなり，即時のフィードバックに比べ学習効果は期待できない．

こうした課題に対し，富士ゼロックスが有する電子透かし技術により，授業情報を透かしとして埋め込んだ用紙をMFPでスキャンしPDF化する際に授業科目を取得し，さらに手書き文字認識技術により学生番号を取得することで，LMSを介して教員が採点した結果を含むPDFファイルを学生に返却できないかと考えた．

プロジェクト開始時に大学で作成したプロジェクト憲章には，開発の目標と手法を次のように定義していた．

［プロジェクト名称］

電子透かし文書を活用した教育環境構築プロジェクト

［プロジェクト目的］

電子透かしを埋め込んだ用紙を利用した教育手法を開発する．

プロジェクト憲章に開発手法の記述はないが，下記のような方針でプロジェクトを進める合意があった．

• ・企業と大学が別々の目標を持ちつつ一つのシステムを開発する．具体的には次の目標を持っていた．
  大学：LMSの利用率を上げる動機となるシステムの実現
  企業：ソリューション事業を拡大するための潜在ニーズの発掘，研究所の基礎技術の市場への適合性の確認
• ・課題の解決方法は，企業または大学が一方的に提示するのではなく，双方がアイデアを出し合う．
  たとえば文字認識率の向上は，企業側による機械学習技術の開発だけでなく，教員が学生に対して認識しやすい文字の大きさや形状をガイドすることでも達成できる．
• ・プロトタイピングにおいては，双方のアイデアを元にシステムを構築し，授業における実証実験結果を短期にフィードバックする．具体的には4週間を一つのサイクルとして提供，実験，評価を繰り返す．大学側ではそのサイクルを考慮した授業設計を行う．

ここで掲げた開発手法は，企業と大学の双方が主体性をもちながら協力して一つのシステムを開発する共創開発とみなすことができ，この時点で共創開発が始まったといえる．

通常は企業か大学のどちらか一方に置くプロジェクトリーダー（以下，PL）を，本プロジェクトでは企業と大学が主体性をもってプロジェクトを進めるため双方にPLを置いた．プロジェクトのコアメンバは次のとおりである．

• ・企業：PL，システム開発者6人の計7人
• ・大学：PL，LMS開発者1人の計2人

本稿の第1筆者が当時企業側PL，また第3筆者が大学側PLを担当した．また，第2筆者は企業側でシステム開発の中心的な役割を担った．

4.　プロトタイピング（2012/9～2012/12）

4.1　新たな開発スタイルの採用

一般的なシステム開発では，企業が主導してユーザからの要求仕様をまとめ，開発したものを納品するウォーターフォール型開発で行われることが多い．このウォーターフォール型開発は，開発初期に要求仕様から機能要件，非機能要件を明確にし，その仕様で作りこみを始める．このため，開発初期に要求が曖昧であったり，開発途中で要求仕様が頻繁に変わるような開発には不向きな面が多い．

そこで，前述した大学教育向のシステム開発の前例や特徴を踏まえ，今回の開発はシステムのプロトタイプを開発し教員の要求の明確化とシステムの仕様の妥当性を検証しながら，商品性を検討することにした．

プロトタイピングでは，比較的短期に要求獲得，開発，運用，フィードバックを繰り返すスパイラルアップ型の開発スタイルを採用し，アジャイルやイテレーション開発のプラクティスを取り入れることで柔軟な対応ができるようにした．また，システムを利用する教員の立場に立って商品仕様と技術選択の妥当性の検証に絞って実施することにし，最終的に必要となる設置や保守機能などの運用にかかわる機能開発は行わないことにした．

4.2　プロトタイプ対象の決定と計画策定

共創開発の最初として，図1に示す一般的な授業の流れと授業中に使用される紙に関する具体的な情報は大学側でまとめ共有した．複数の教員の意見を交え，法政大学の講師室に準備されている11種類の用紙から授業での利用頻度が高く教員が日常的に取り扱うかという観点で順位付けを行い，次の3種類の用紙を選択した．

• ・出席調査票/小テスト
  授業中に使用される．氏名，学籍番号のみを記載する名刺サイズのものが使われていたが，MFPで読み込み可能なA4，A5サイズとし，小テストもできる片面1枚の用紙とした．
• ・レポート
  期中に数回使用される．学生はLMSからダウンロードしたテンプレートファイルを用いてワープロにてレポートを作成しLMSに提出する．教員が両面印刷して手書きで採点するA4複数枚の用紙とした．
• ・テスト
  期中および最終の試験で使用される．あらかじめ教員が作成した問題を印刷し学生が手書きで解答する．A3，A4，B4サイズとし，片面もしくは両面印刷で使用される用紙とした．

大学との共創で授業における実証実験を伴う場合には，4月から始まる前期あるいは9月から始まる後期に合わせることで，図1に示した学期にわたる活動に合わせた検証ができる．そのため，プロトタイプ開発は後期授業中に各種評価ができるように9月に開始した．これにより，翌1月まで続く後期授業で，出席票を10月初旬，レポートを11月中旬，テストを12月中旬に提供する各1ヶ月ごとに機能提供するスプリント開発とし，各用紙を使用する機能を授業で実証することができた．

4.3　構築したシステムとワークフロー

最終的な商品も含め，開発したシステム[7]で最も利用されているものは出席票の用紙であった．この出席票を想定したワークフローを図2に示す．

• ①教員は授業の前にMFPから出席票をプリントする．この際後述する電子透かし技術を用いて授業情報などを埋め込む．
• ②教員は授業で出席票を学生に配布する．学生は配布された出席票に学籍番号を手書きし，授業の感想や理解度テストの回答を記入する．教員は記入済出席票を回収する．
• ③教員は回収した出席票を添削・採点し，MFPでスキャンする．
• ④システムは出席票から読み取った授業・課題情報と学籍番号をもとに，LMS上のデータ格納先を特定する．スキャンデータを変換したPDFファイルと採点結果をLMSに学生ごとに登録する．
• ⑤システムは全学生分の登録が完了すると，学籍番号と採点結果の読み取り結果と出席票の手書き文字部分を切り出した画像ファイルを一つのZIPファイルにまとめて，WebDAVで教員が参照可能にする．
• ⑥学生はLMSにログインし，授業・課題のページからPDFファイルと採点結果を参照する．

従来の類似のシステム[8]では，用紙の返却先の学生を特定するために，あらかじめ用紙に学生ごとの情報を埋め込んだり，学生に個人を特定する情報を埋め込んだQRコードのシールを配布し提出時に用紙に貼り付けるなどしていた．しかし，これらの手法では，学生一人一人に正しく用紙を配る必要があり，授業時間に影響を与えたり，学生が自宅に忘れるとシステムを利用できない問題があった．

この問題を解決するために，プロトタイプシステムでは富士ゼロックスの独自技術である手書き文字認識技術と電子透かし技術を採用することで運用上の問題を解決し，紙を用いた従来どおりの授業を継続しながらLMSと連携することが可能になると判断した．このワークフローを実現するためにプロトタイプシステムで採用した主な技術は，次のものである．

• ・手書き文字認識
  用紙に記入された学籍番号を文字認識し学生を特定するために機械学習を応用した手書き文字認識[9]を採用した．
• ・電子透かし
  授業・課題の情報を用紙に埋め込むために，富士ゼロックスが独自に研究した電子透かし技術である用紙全面に印刷した微細な点に情報を埋め込むMISTCODE [10]を採用した．
• ・Webサービス
  複合機とLMS間の通信は，LMSとして利用を想定したSakaiにあらかじめ実装されていたApache AxisによるSOAPを採用した．

4.4　プロトタイプシステム評価

(1)　仕様の妥当性評価

出席票を例にとり，システム利用の有無による所要時間を比較した．その結果を表2に示す．

この実証実験は，100人の履修者のいる授業で実施したが，開発したシステムを利用しない従来の方法では，回収した小テストを採点後にソートし，それをスキャナでPDF化して，100個のPDFファイルを学生ごとに選択しながらLMSにアップロードする必要があり，結果として1時間以上の時間を要した．教室で採点済のテストを配布する場合，授業時間を浪費するといった点でも課題がある．また，表計算ソフトで管理する成績表に手作業で点数を転記する場合，17分の時間を要したが，むしろ異なる学生への誤った転記の可能性が課題である．

一方，開発したシステムを利用する場合，電子透かしの入った用紙を印刷する作業として4～5分がかかるだけであり，それ以降の作業においては，システム利用無と同等もしくは時間を必要としない．

レポートとテストのプロトタイプシステムでも，同様の結果が得られた．テストに関しては，用紙のサイズがB4ないしは，A3となるだけで出席票と同じワークフローであり，出席票と同じ結果となった．レポートに関しては，学生が電子データをLMSに提出し，教員が印刷を行いコメントや評価を記載し，スキャンをすることになる．このため印刷の手間はかかるが，手書きによるフィードバックは学生の授業に対するモチベーション向上に寄与することから問題がないと判断した．

手書き文字認識と電子透かしを組み合わせたシステムは文字単位の認識率も運用には問題がなく，電子透かしについても想定内の印刷方式であれば問題がないことを確認できた．この結果から，プロトタイピングによってシステムの仕様の妥当性を検証できた．

(2)　手書き文字認識の運用結果

全14回のうち12回の授業における手書き文字認識の正解率は99.6%であり，文字認識の誤りは平均して2文字／授業であった．この結果から，従来型の授業と同様に学生に学籍番号を手書きさせるだけで，実用的なシステムを構築できることを確認できた．

図3は手書き文字認識の誤認識の例である．この結果から，文字認識の誤りには次のパターンがあることが分かった．

• ・システムが認識を誤った．（手書き文字認識技術の性能）
• ・文字がかすれていた．
• ・消しゴムなどによる修正が不十分であった．
• ・そもそも人が見ても正しく判別できなかった．

システムが認識を誤った文字については，手書き文字認識技術が機械学習を採用しているため文字の収集などを行いながら性能改善をすすめたが，実際に運用すると100%認識にはならなかった．そこで富士ゼロックスで過去に行った共同研究[11]の経験から図4のように小テストおよびテストのフォームに記載例を載せることや，教員から学生に認識しやすい文字の書き方を指示することによって，100%の認識率を達成しなくても授業での利用に供することができるとの判断をした．

(3)　電子透かしの運用結果

学生の情報を埋め込んだQRコード入りの用紙を使用する場合と比べ，学生を特定することなく配布することができ，授業時間を無駄にしてしまうことがなくなった．一方で，次のような状況があることが明確になり仕様や運用の再考が必要と判断した．

• ・教員によっては連続した授業を担当することも多く授業前に用紙を印刷する時間を確保できない．
• ・あらかじめ大学側で印刷業者に発注した専用用紙を用意しておき，それを授業で利用するケースが多い．
• ・プロトタイプシステムの電子透かしの印刷品質を保証する専用アプリケーションを教員に配布したが，非常勤講師の利用などを踏まえると前提にできない．
• ・富士ゼロックスの研究所において実験に使用していた用紙に対し大学が用意した用紙は，地色が濃く紙自体にMISTCODEが背景画像として埋め込むドットと同じような汚れがあった．その影響で，図5に示すように電子透かしが認識できなくなることがあった．

  

• ・WindowsとMicrosoft Officeの環境であれば問題なく印刷できるが，docxファイル形式をサポートしていない古いバージョンのMicrosoft Office，macOSに付属するPagesやOpenOfficeの環境ではレイアウトが崩れたり電子透かしが印刷されない場合がある．

4.5　プロトタイピングにおける共創

大学からの要求を整理して機能要件を定義し，それを企業が実装するプロトタイピングのフェーズは，それぞれが妥協をしないで目的を達成するために，プロジェクトを通じて最も共創が重要となるフェーズである．そのために大学側からはできる限り具体的な情報を提供し，企業側ではテクノロジーを入れ込む実装が行われた．

ここでは，企業だけでは情報の取得や依頼が困難だと思われる大学側で行った具体的な作業について以下に列挙する．

• ・プロトタイピングシステムを実証するための新たな授業開発を行った．具体的には，毎回の授業の最後に10分程度の小テストを実施するために単元の時間配分を変更したり，省察のために新たにマインドマップの手法を取り入れることを行った．
• ・FDに関心の高い教員に2人に依頼し，第3筆者を含め3人の教員で計4科目の授業において実証実験を行った．
• ・用紙などの教材を入手する講師室に備えられた全種類の用紙を収集した．法政大学においては，11種類の用紙を収集した．また，富士ゼロックスでも営業部門に依頼し20校，30種類の用紙を収集した．
• ・用紙裏面をメモ書きとして利用する事例などの想定外の事例を報告した．
• ・MFPの最適な設置場所を提案し，関連部門との調整を行いMFPを設置した．本来であれば，教員の動線である講師室への設置を希望したが，学内的な事情により情報メディア教育研究センターへの設置となった．
• ・MFPの用紙補充を担当する適任者を推薦した．

上記にて企業から大学に対して最も困難な依頼は，プロトタイピングシステムを利用するために授業を変更することである．多くの場合，授業は長年の授業改善によって変更の余地のないほどに完成されているため，実証実験のために企業側から授業設計を依頼することは事実上困難なことである．

5.　商品開発（2012/12～2013/10）

5.1　方針とスケジュール

プロトタイプの検証結果を踏まえ，商品化に向けて次のような方針で開発を進めた．

• ・IT化によって従来のワークフローを変えるような商品を開発するのではなく，従来のワークフローの中に違和感なく取り込めるシステムを開発する．
• ・商品企画や営業部門の声をもとにプロトタイプシステムの仕様を一般化して，より多くの大学（教員）に適合する商品仕様とする．

官公庁や大学でのシステム更新は年度末に行われることから，2013年11月までに販売を開始し年度末の商戦に対応する必要があった．営業部門からは大学の夏季休暇中に販売開始できることを望む声があったが，開発，製造を踏まえ開発から販売開始までの期間を2012年12月から着手し約10ヶ月のスケジュールとした．開発は計画どおり進み，2013年12月に“授業支援ボックス”という商品名で販売が開始された．

5.2　開発プロセスおよび開発メソッド

メーカ企業における商品開発は，プロトタイプ開発のような共創開発メンバだけでなく，商品企画，販売，品質保証，マニュアル作成，保守といった様々な部門と協業が必要である．このためにメーカ企業では商品開発を行うためのプロセスが標準化されており，多くはウォーターフォール開発を基盤としている．本プロトタイプの商品化に際しても企業が定めた標準開発プロセスに従いウォーターフォール的な開発が基盤となったが，様々なユーザ要求の中で重要な要求を探るための狩野モデル[12]の適用やストーリーポイント[13]による仕様明確化と見積り，テストファーストによる品質保証し反復的にシステムをリリースするアジャイル開発の手法をウォータフォールの商品開発に組み込む形で商品開発を実施した．特に機能仕様検討にストーリーポイントを利用したことで，共創で得られた具体的なユーザとシステムの関係およびワークフローを関連部門に示すことができた．これにより，適切なマニュアルや想定ではなく具体的な品質保証計画，販売やサポート体制などを検討することができた．また，社内で考えられた不確実な機能要求による開発スケジュールへの影響を抑えることができた．

また，プロトタイプは，機能要件の検証を主な目的としていたため，CPUなどのハードウェアリソースについての検証を行わなかったが，ハードウェアリソースは，そのまま商品原価に直結するため最適なものを選択する必要がある．このため商品企画部門や営業部門にも協力を依頼し，見込み顧客に対して適正価格などをヒアリングし，顧客の希望する価格で提供できるハードウェアを開発部門が選択した．次に選択したハードウェアが実際に運用に耐えられることを検証した．これは，営業部門の情報や実証実験から，本システムを利用する平均的な教員数を設定し，法政大学の大教室において授業を行いシステムを利用した状況で，これらの教員が当日中に処理を完了できる性能見積もりと実機による性能計測を行った．具体的には，最も負荷が高い状況としてシステムを利用する教員数を10人/日，学生数を150人とし，A4両面のテストを処理するユースケースを想定した．結果として，選択したハードウェアの処理能力は問題なく，顧客の希望する価格で商品が提供できることを確認した．

さらに2012年12月に開催された国公私立大学が会員となっている大学ICT推進協議会[14]の年次大会において，プロトタイプの展示を行った．この大会では大学におけるITにかかわる教職員と関連企業から1,000人近くの関係者が集い，大学と企業で様々なディスカッションをすることができる場が提供された．具体的に行われたディスカッションには次のようなものがあった．

• ・商品を適用できる授業規模や学生数
• ・大学で利用ないしは想定しているLMS
• ・用紙のバリエーションとカスタマイズ要求
• ・スキャンしたレポートをタブレット端末などで採点しLMSと連携したいといった要望

企画，営業担当者がそれぞれの大学に足を運ばなくても．その場を利用して様々な大学から意見を収集できたことも開発期間の短縮につながった．

5.3　プロトタイプシステムの課題解決

商品では，授業情報を電子透かし技術で用紙に印刷するのではなく，スキャン時にLMSから取得し教員が選択するようにした．4章で述べたとおり，教員は授業前に用紙を印刷することは難しい．そこで用紙には手書き文字認識の領域を特定する情報のみを電子透かしとして埋め込むことにし，教員が自由に編集したり，あらかじめ大量に印刷できるようにした．この変更によりボタン一つでスキャンすることができなくなったため，教員の操作を想定しながら画面遷移を検討し最小限のステップ数でスキャン作業を行えるようにした．

このためには，MFP側でも教員や授業の情報を管理する必要がある．従来の商品ではLMSとの独立性を保つため，MFP側でも情報を管理するような仕組みを開発していた．しかしながら，大学システム管理者の負担を軽減を考え，MFPでは情報を持たずLMSの情報をMFPから参照するように変更した．結果としてスキャン作業は図6のステップとした．

また，プロトタイプシステムでは集計結果の取得にWebDAVを前提としていたが，商品開発当時の普及率や使い勝手，非常勤講師を含む教員全体へのアナウンス等を勘案し，商品では採用しないようにした．LMSに設定されている教員のメールアドレスを参照し，処理結果をダウンロードできるワンタイムURLを記載したメールを送信することで，ユーザの分かりやすさとセキュリティ面を両立させた．

さらにMISTCODEが認識できなくなる問題については，目立たずかつ認識率が維持できるように研究所とともに設定値を再考しただけでなく，MISTCODEと同じ機能を持たせたQRコードを使用したフォームを準備した．これにより地色の濃い用紙や画像がほぼ全面を覆う原稿といったMISTCODEが適切に印刷できない環境に対応できる仕様とした．

5.4　商品開発における共創

本来は商品開発で行う機能要件や非機能要件といった要件定義の多くがプロトタイピングで完了しており，品質保証，販売および保守体制，マニュアル作成といった社内作業にとどまったため，プロトタイピングフェーズのような活発な共創活動は実施しなかった．

ただし，商品化直前の商品を，ユーザとなる大学でエラー対処や運用の視点から確認し，エラーメッセージの追加などの調整を実施した．共創が行われていない場合には，このフェーズになってからユーザによる試用のためのタスクが発生していたが，本プロジェクトではプロトタイプから始まった共創の一環として，容易に最終的な確認ができた．

6.　商品化後（2013/12～）

6.1　環境変化と機能追加

商品の販売開始後は，商品に対してのセキュリティや障害対応といった保守活動を行いながら，市場の要求に応じた機能拡張版のリリースを行っていくことが一般的である．

本活動で開発したシステムにおいては，大きく三つの側面で機能拡張を行った．

(1)　認証機能の導入

2013年末の商品販売開始後，大学内のネットワークアクセスに制限が設けられるようになるなど，セキュリティ要求は年々高まっていった．特に大学のMFPのセキュリティは社会的な問題として新聞等にも取り上げられた[15]こともあり開発当初の想定から大きく変化していった．そのため本活動で開発したシステムにも，利用時にMFPが提供するユーザ認証と連携する機能や，集計結果をシステムからダウンロードする際にユーザ認証する機能を導入した．

(2)用紙のカスタマイズ機能

メーカにおける品質保証の観点から販売開始時に本商品でスキャン可能な用紙は，商品にあらかじめプリセットされたフォームを印刷した用紙のみとした．しかし，導入が進むにつれ大学側が作成した用紙をスキャンしデータを取り込みたいという要望を受けるようになった．具体的には，これまで大学で使用されていた用紙にレイアウトを近づけたい，B判への対応，テストの合計点だけでなく，設問ごとの採点結果を文字認識してほしいといったものである．これに対応するため大学の個別要求に応じて用紙を追加インストールし，集計可能とする仕組みを導入した．

(3)保守・管理に関する機能拡張

市場における導入数が増えるにつれ，市場から主機能だけでなく保守・管理に関する機能拡張の要求が増加するようになった．これは，販売当初は教員主導による導入がほとんどであったのに対し，IT管理部門が中心となって全学的にシステムを導入する導入事例が増加したことに起因する．IT管理部門では，非常勤講師を含めたすべての教員を考慮したサポート，運用管理，導入効果やユーザ数の報告などに関し，組織的かつ継続的な業務が要求される．このような要求に対し，システム管理者が教員の利用履歴を表形式でダウンロードできる機能，集計結果取得用のワンタイムURLが記載されたメールを事務員のメールアドレス宛にも送信し取得に失敗した教員をサポートする機能などを導入し対応した．

6.2　商品化後の共創

商品化後は2，3ヶ月おきに法政大学と富士ゼロックスで定例会を開催し，共創が続いた．6.1節で述べた機能拡張のうち用紙のカスタマイズ機能は定例会のなかで要求された機能である．特に設問ごとの採点欄については，プロトタイピングした機能を複数の教員が利用した結果を踏まえて商品に導入した．

一方，保守・管理に関する機能は，大学教員と企業の共創では得られなった機能である．大学においては実験的なシステムは教員が運用し，大学として正式にサービスを提供するシステムは法人側，すなわち事務が運用・管理することが多い．プロトタイピングフェーズを終え，商品化のフェーズに入る際に，実際に運用を行うメンバをプロジェクトに含めることが望ましいという知見が得られた．

7.　共創の成果

7.1　企業側

1章で述べたとおり，授業支援ボックスは2012年9月からプロトタイピングを行い，同年12月から始まった商品企画を経て，2013年2月から商品開発に着手し，2013年12月には商品化された．商品開発には通常1，2年を擁していたが，授業支援ボックスは10ヶ月という短期間で商品化できた．俯瞰してみると本商品の開発は，プロトタイプ，企画，設計，開発，販売，保守という一般商品と同じプロセスで実施されたが，プロトタイプの期間に共創活動を行ったことが統計学等でいわれる介入とみなすことができる．その介入による効果を下記に示す．

• ・手書き文字認識および電子透かしといった自社のテクノロジが商品として耐えうるものであるかの検証を早期に行うことができた．
• ・企業側が想定した仕様に内在する問題をユーザの視点から発見することができた．
• ・大学と企業の双方にPLを置いたことでDevOpsに近い形で開発を進めることができた．これにより互いに手が届きにくいところをカバーしあい，多くの大学の利用に耐えうるシステムを作りあげることができた．

7.2　大学側

大学で開発されたシステムが商品化されることは，大学が使命とする教育，研究，社会貢献のうち，社会貢献にあたる．本プロジェクトで開発された授業支援ボックスは，共創開発により大学において直接教育を担当する多くの教員の要求を取り入れて商品化され，国内の多数の大学で利用されるようになったことは企業の存在をなくしては達成できなかった．おそらく大学が単独でできることは，本稿におけるプロトタイプまでのフェーズである．

1大学で研究・開発されたシステムは他大学に展開できるだけの品質を有さないといった課題を解決できたのは，企業側で“価値は企業が創造するもの”から“価値は消費者と企業が共創する”といった共創の意義を評価したことに起因したことは明らかである．

幸いにして，この授業支援ボックスは，法政大学では専任教員の10%となる76人が利用している．授業支援ボックスはLMSと連携するシステムであるため，これらの教員は必然的にLMSを利用しており，LMSの利用率向上にも貢献している．

社会貢献の視点から，他大学の利用をインターネット検索で調査した結果，26の大学で利用されていることが分かった．学外公開をしていない大学を含めるとその数はさらに多いと思われる．授業支援ボックスが製品化され，教員の事務的作業の効率化だけでなく，教育の質の向上にも貢献していることが，大学側にとっての共創の成果といえる．

8.　考察

前章までは実際のプロジェクト体制で実施したことを記載した．しかしながら，プロジェクトは一過性であり，同じ大学と企業でも同様の体制をとることは困難で，他の大学や企業であればなおさらである．そこでこれまでのプロジェクトを振り返って，(1)共創活動における大学と企業の役割，(2)想定外であった事象，(3)本共創活動の特徴について考察する．

(1)　共創活動における大学と企業の役割

本稿で対象としたプロジェクトにおいて，大学ではほぼ1人の教員が表3における役割を担ったが，こうしたスキルを有する教員は稀である．そのため，大学側では表3に記載した機能を3～5人程度のメンバで充足するプロジェクトチームを構成することが望ましい．このプロジェクトチームのメンバにおける役割（表中，ロール）は，全体を統括するプロジェクトマネージャ（表中，PM），実際にシステムの運用管理を行う運用管理者（表中，管理者），システムを利用するユーザの三つに区分できると考えられる．

また，システムの開発を行う企業側において共創開発は，企業が持つプロジェクト管理の手法を適用できる．実際に商品化から保守期間は，富士ゼロックスの持つ商品提供プロセスの下で企画，プロジェクト運営，開発，製造，品質保証，営業，保守といった部門のメンバが参加し授業支援ボックスという商品開発と保守を実施した．共創開発の活動を行った開発チームはプロトタイプ時には7人，商品開発時には最大で10人，保守期間は5人が参加していた．

この開発チーム内のロールには，全体を統括推進したプロジェクトマネージャおよび補佐役，基盤技術を提供する研究部門（表中，研究者），要件仕様定義から実装を行う開発者，そしてスプリント開発に対応できるフレームワークを提供やインテグレーション基盤を準備運用するインテグレーション担当者（表中，インテグ）が参加した．各々の役割を表4に示す．

(2)　想定外の事象

6年間のプロトタイプから保守期間においては，文字認識や電子透かしの印刷など，研究や社内評価の範囲では想定できなかった技術的な問題が発生した．そのなかで最も想定外であった問題はAPIの選択である．

2.2節で述べたように法政大学ではLMSにSakaiを採用しており，SakaiにはApache AXISを利用しSOAP APIによりWebサービスを提供する機能がある．プロトタイピングにおいてもMFPとの接続を行うためのSOAP APIを作成したが，当時はWebアプリケーションのAPIがSOAPからRESTに主流が変化しはじめていた．このため，他のLMSの開発ベンダからはSOAPより簡単に開発が行えるREST仕様が要望された．しかしながら量産が必要な授業支援ボックス側の変更は，品質保証，生産といった観点でも費用が発生するため，LMS側にSOAP仕様で実装してもらう必要があった．この説明を開発部門が担うことになり，結果として開発や営業部門に様々な影響を与えることとなった．実際にシステムを利用するユーザから見るとAPIの仕様がSOAPとRESTどちらであっても提供される機能に違いはないが，共創活動の中で最も想定外の問題であったと考えられる．

(3)　本共創活動の特徴

はじめに述べたように近年多くの共創開発が取り組まれているが，今回の法政大学と富士ゼロックスのプロジェクトが共創開発として成果をあげられた理由には，次の点のあると考察できる．

• ・“価値は企業が創造するもの”から“価値は消費者と企業が共創する”といった共創の意義の理解．これを経営者が示し具体的な活動を行う部門に権限を委譲し活動させたことが商品化と普及につながったといえる．
• ・共創相手の要求の変化に柔軟に追従し短期間に機能リリースを繰り返すCI/CD^*を可能とし品質を保証できる技術的なフレームワークを事前に持っていたこと．これにより短期間のスプリント開発や商品化以降の機能追加による障害を防ぐことができた．フレームワークの有無は価値の創造には大きな影響を与えないが具現化には必須であり，事前に準備されていたことが重要であった．
• ・企業内にある価値（組織力や技術）を理解し必要に応じて多数の部門が協力し活動したこと．商品化以降に参加した各部門の担当者は，既存の社内規定にとらわれることなく，開発部門から提案される開発手法や共創で得られた仕様などの取り込みに協力的であった．共創開発を行っていた開発部門側では，従来の商品開発のように最大公約数の機能を盛り込む要求が出ると考えていたが，社内的な協力もあり必要な機能を順次追加していく開発，保守を実現できた．
• ・プロトタイプ開発の発表以降も消費者と企業の間の関係を維持することができたこと．商品化後に法政大学と継続的に議論しただけでなく大学ICT推進協議会でのディスカッションを持続的に行ったことにより企業内で検討した機能の有効性を事前に検証できた．

9.　おわりに

本稿では，大学教育のシステム化とその課題に対して，2012年から2018年にかけて企業と大学が行った共創開発の概要とその成果について述べた．

大学との共創を念頭に置いたシステム開発では，プロトタイピングフェーズの共創がカギとなることを示し，それに続く商品開発では社内での協業が主なプロセスとなるため共創は一段落し，商品化後の機能拡張や保守で共創が再開したことを述べた．共創の成果は，企業においては短期間での商品化，大学においては開発された商品を通じた教育の質向上および他大学が利用することの社会貢献である．そして，最後に共創開発における大学の役割を整理した．LMS等のITシステムが普及し，システム上に学生の学習結果が蓄積されるようになったことで，学習理解度のデータ化と分析が可能になりつつある．今後は，授業で使用した紙をITシステムに蓄積するだけでなく，紙から情報を抽出する技術も重要になると考えている．今後も筆者らは，紙とITシステムをシームレスにつなげるシステムの開発に継続的に取り組んでいく．

最後に，本稿で取り上げた共創が他の教育機関と企業との共同開発に適用され，国内外の教育機関における教育の質向上につながることが筆者らの願いである．

謝辞　本活動には，法政大学情報メディア教育研究センターおよび富士ゼロックス株式会社の関係者の方々に多大な協力をいただいた．ここに深く謝意を示す．