# 22.（2013年）要件定義の必要性と人材育成（IT研修内容） 平成25年12月17日 電子情報部　中山 ## 目次 ```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` ## 1. 要件定義の必要性 - 以前は、IPAでソフトウェア生産性向上に関連する事業、セキュリティセンターに従事 - 2002年に入館以来、当館のシステム開発に関して、直接的、間接的に関与させていただいている。 - その間、職員、業者の努力により、他の省庁と比べると、各段費用対効果の高いシステムを構築していると思う。 - しかしながら、予算が大幅に削減される状況において、システム開発の更なる効率化が必要と認識している。 ## 2. 知識情報基盤の構築 - 「科学技術基本政策策定の基本方針」として、平成22年6月総合科学技術会議基本政策専門調査会で、国の第4期科学技術基本計画（23年8月閣議決定）に知識インフラ関連の言及を入れてもらうために作られたイメージ図。（当時の科経の本吉課長） - それを先行事業としての大震災に当てはめたもの。 - 外部プレゼンではよく使われるが、館内ではほとんど使われない。 - 当館の電子図書館中期計画2004、科審での知識インフラの構築、使命・目標で示される当館のデジタル関連の事業の目指すものは大きく変わっていない - これの実現を目指すサービスの実現のために業務・システムを組み立てているところ - この概念は、大きな枠組みの中では、当館は情報を集約して提供する組織のOneOfThem。しかしながら、大量の資料を保有しているが故に、分散保存、ポータルとして、中核的な役割を果たすことが求められている。 ## 3. 最適化計画の考え方 - 昨年度から策定してきた「業務・システムの最適化」の考え方（川島氏作成？） - 目的と位置付け - システムに求められる要件（仮定） - 最適化の基本方針 - 目指すべきシステムの姿 - 取組み事項 - 実施方法 ## 4. 使命・目標達成に向けた考え方 - これも最適化計画策定に当たって示された図（川島氏作成？） - 最適化計画は、サービスを決めるのではなく、サービスを可能にする計画 - 最適化を行うことで、費用対効果の高いサービスを構築し、それにより、新たなサービスを生む余地を作る ## 5. 館の情報化推進体制 - 今年度の情報化推進委員会で提示した姿勢（25年4月館長作成） - 情報化の推進を図るために、総合的な考慮が必要 - サービスを実現するために - 業務的観点（システム抜きには業務は成り立たない） - システム的観点（システム化は業務・サービスを向上させるためにある） - 実施に当たっては、戦略的な経営資源の配分（人・物・金） - CEOが行司役（システム化を通じた業務の変更、業務向上のためのシステム変更） - それにより、情報化推進委員会の委員長は総務部長とした。 ## 6. 情報化のプロセスと考慮点（サービス構築の流れに沿って）（流れ図参照） 電子情報部を設置する時に、各部局との役割分担を共有するために作成したもの。特にサービス要件定義の担当と、成果物の名称を示した。最適化計画本体にも記述されている。 ### (1) 「私たちの使命・目標」、年度活動計画 - あるべき姿の検討、サービスの理念、活動の方向性、サービスの項目と概念、スケジュール感 ### (2) 基本計画書、サービス実施計画書 - 使命・目標の達成のアプローチとして、サービスの提供の方向性、具体的なサービス、システムのイメージの想定 - 何をしたいか？（サービス部門） - 何ができるか？（システム部門） - カバレージとして、フロントエンドは利用者へのサービス、バックオフィスも職員へのサービス ### (3) サービス要件定義書 - サービスは、業務とシステムで構築 - 業務とシステムで連携・分担して、フロントエンドサービス、バックオフィス業務として何ができるようにするかを明確にする。 - 主たるサービス要件より、サービスの実現当たって例外的に行うべき要件の明示が重要（後述） ### (4) システム構築 - システム化要件定義書 - 業務・機能要件定義、非機能要件定義 - 開発プロジェクト標準、技術標準適用指針、技術標準適用ガイドラインに沿って - 見積もり依頼書 - 予算、実施内容を決定するに当たって重要な書類 - 必要スキル、工数が算定できるレベルの仕様書の提示が必要 - 調達仕様書 - 価格競争の場合は、実施すべき事項を明確に提示し、実施内容が業者によってブレないようにして、安い方を落札。 - 仕様が明確に提示できない場合は、実施内容、方式を提案させる形での総合評価での競争にし、必須項目でも、優れた実施内容、将来への拡張性の配慮の内容には大きく加点する。 - 契約書 - 総合評価での契約書に添付される仕様書は、提案書相当。 - 提案書の内容をベースに検査仕様書を作成し、成果物の検収は、提案書の内容が実現しているかを検査する - システム設計書 - 開発担当者に向けた資料。 - サービス要件に従ってシステムで実現することが明確になっている調達仕様書通り作られていれば、ユーザ部門は読む必要がない。 - 調達仕様書、提案書通り、設計がなされないで、開発を行うと大きな手戻りが発生する - システム運用手順書（マニュアル） - 開発時に、ほとんどゼロ知識でもできるレベルを求める ### (5) システム運用 以降、今回は時間がないので割愛 ### (6) 業務構築 - 業務要件定義書 - 業務手順書（マニュアル） ### (7) 業務運用 ### (8) 制度構築（制度に関しても同様） - 制度設計 ## 7. 過去の問題事例 - 前の基盤システム（A社、H社） - _最低1ユニット500万での工数見積もり_ - _同一業者で開発運用しているにも関わらず、影響度調査名目で大きな工数_ - _ファンクションポイントで工数を算定したとき、同様の更新処理を、数分だけ積んだ。_ - 前のDAシステム（N社） - _開発の予算を認識せず、予算・内容ともに実施が不可能な設計_ - _設計・開発の工程及び成果物のレベルの認識に齟齬（基本設計、概要設計、詳細設計、外部設計、内部設計）_ - NET4（H社） - _基本設計書が曖昧すぎて、詳細設計で手戻りが多くなりそうなので差し戻し。_ - _運用に入ってから、ファイアウォール、端末の移設等、軽微な作業に対して、大きな工数を見積もられている_ - 今の業務基盤システム（E社、N社） - _総括メモ（F氏メモ）_ - _前年度の成果物を要求要件としたが、設計書等が不十分だったため、後工程で大きな工数を要した。_ - _当館、工程管理支援業者、設計開発業者での作業スコープ、役割、作業の責任範囲が一致していなかった。_ - _一部担当者の暗黙知として蓄積されていた_ - _リリースされたプログラムの品質が悪く手戻りが発生した_ - リニューアル総括資料 - リニューアル総括（25年6月）参照 - （教訓）「企画段階で、サービス要件定義について、全館で合意を形成する」 - システム化要件定義段階で、「サービス要件定義書と、業務・システムで実現可能な内容のFit&Gapについては、実現可能な範囲で合意を形成し、サービス要件定義書にフィードバックする - NDLSearch（N社、H社） - 開発、機能強化、運用と、交互に落札しているようなシステム。ソースコードのリファクタリングが必要になっている。 - 大震災アーカイブ（N社） - NDLSearch、DAをベースに、発展形として、両システムの統合の足がかりになることを想定したが、違う方向を向いていった。 ## 8. 要件定義の重要性と考慮点 システム部門を担当して、部内、館内で示してきたことを、思いつくまま列挙したもの。 体系的な説明は、CIO補佐官の解説に委ねる。例外的なサービスを網羅的に（網羅性の確保） ### (1) 重要性は、ソフトウェア開発に限らない - 組織間、部局課係間、担当者間での曖昧な内容での指示は、作業スキル、必要工数の算定で大きな齟齬が発生し、安全を見込むと大きな見積もりとなり、また、過小評価すると、後で大きな工数を要する。 ### (2) サービス要件の定義は、基本計画書の行間を埋めるもの - 使命・目標は概念であり、基本方針・基本計画書は、利害調整で玉虫色になっていることが多い。 - 合意形成のために、意識的に、サービスの実施内容が曖昧になっている - 概念・方向性は認識できるが具体的なサービスの実施内容が判断できない - 基本方針、基本計画の策定において検討したメモ、カットされた記述が重要。それがベースとなって、明確な要件となる。 ### (3) 開発に大きな工数が掛かるのは、例外処理の規模と将来への拡張性への配慮 - 例外的なサービスを網羅的に（網羅性の確保） - 例外的なサービスは条件と実施内容を明確に提示 - 例外的なサービスの内容が明確でないと、認識の齟齬により次工程でもめる ### (4) サービス要件定義段階での合意形成が最も重要 - 後工程でシステムの根幹に関わる変更は不可能 ### (5) 業務、システムの構築は、論理的に明確なサービスの要件がなければ構築できない （システムに限らず、法制度化等も同様） - 曖昧なまま、業務構築、システム開発を行った場合、過大な見積もり、大きな手戻りが発生する - 齟齬の顕在化が後工程になればなるほど、工数が大きくなる - サービス部門とシステム部門で暗黙知でなく、形式知化した形で合意しておく必要がある⇒サービス要件定義書 - サービスの実施内容があいまいなまま、業務構築、システム開発を行った場合 - システム化要件定義書が曖昧になる - 開発規模感が掴めない - 調達仕様書が曖昧になる - 開発者は安全を見込み、見積もり額が大幅に大きくなる - 開発工程で手戻りが発生する - 納品されて検収する際に、必ずもめる - 仕様書は担当者のスキルレベルに依存しないように明確に - やるべきことを明確に（曖昧性の排除） - 論理的な思考で、条件と内容を明確に。曖昧な文章表現ではなく、箇条書きで、判断要素は断定的な記述に ### (6) 業務とシステムでの分担は明確に - システムでできないことの許容 - 経営資源、適用可能な技術の面から、システムで実現可能な範囲が小さく、業務で行わなければならないことの負荷を許容できるかは大きな要件 - 業務とシステムの分担は図式化して共有 - ユースケース図（人とシステムの役割） ### (7) 情報（データ）と機能の流れは明確に - 機能情報関連図（DFD図：情報と機能の流れ（サブシステムレベル））、実体関連図（ER図）等で ### (8) サービス要件は、開発過程、検証中に、なんらかの変更があることを前提とする - 事前に変更の可能性がある部分は明示が必要。 - 変更による後工程への影響を極力小さくするためにも、早期発見が必要。 - ⇒開発前に要件が明確にならない部分は、プロトタイピング手法が有効 ### (9) サービス要件定義には、全体最適化の観点でシステムサイドからの助言が必要 - サービス部門が主体となってサービス要件定義書を策定するが、サービス要件にサービスの方法、手順が示されていても、それに捉われず、 目的を確認して、全体最適化の観点で、より最適な方法がある場合は、システム構築の立場から、助言する ## 9. 各工程での成果物の妥当性評価 ### (1) 全ての工程での仕様書について - サービス要件定義書、システム化要件定義書、調達仕様書、開発段階での仕様書、作業指示書等、全ての工程で、作業依頼書として、人から人へ伝えていくもの。成果物は、次のステップの作業依頼書となる。依頼書が曖昧であれば、成果物のレベル、内容もぶれる。 - 打合せ等で、意見でなく質問が出されるのは、ドキュメントが曖昧だから。全てが妥当な内容であるか評価が必要。 ### (2) 曖昧性・不確実性の排除 - 「仕様素案」、「基本設計書」、「概要設計書」、「詳細設計書」、、、 - プロセスと成果物の具体化度を明確にしないで、成果物名のみの提示は齟齬が生じる - 「柔軟に対応できること」「原則として～する」「～する場合もある。」はNG - 図表を駆使することも明確化に繋がる ### (3) 読むべき人が理解できるか？ - その仕様書をインプットとして、暗黙知なしで、難易度の認識、実施内容、妥当な工数見積もりできるかを評価 ### (4) 将来のコストを削減するか、当面のコストを削減するか？ も重要な観点 - コストが高くても将来性、柔軟性のある方法 - コストが安いが、当面の課題は解決できるか。 ## 10. 参考見積書の評価 - 曖昧な仕様書では安全係数が大きくなり、高額な見積もりになる - 業者の高額な参考見積もりを鵜呑みにして安易な要件緩和やスペックダウンはしない - 提案もしくは指示した実施方法が明確な場合は、具体的な作業と要する工数を評価する - 評価に当たっては、ある程度の実地の経験は必要 - 競争入札になれば、適正な価格に近づく。随意契約の場合は、妥当と思われるまで調整する必要がある - **「人件費単価が高いから見積もりが高くなる」という評価は正しくない。** - スキルの高い人が担当するので単価が高いなら、工数は少なくなるはず。 ## 11. ステークホルダーとの関係での留意点 - 館内での役割分担 - 会議体 - 意志決定、合意形成、実施調整・進捗管理 - 企画部門 - サービス部門 - 開発部門 - 運用部門 - 業者との役割分担 - 調達支援業者 - 工程管理業者 - 開発業者 - 保守業者 - 統合運用業者 ## 12. まとめ ### (1) 方針 - これから、さらに財政事情は厳しくなる。 - システムの開発に限らず、費用対効果の高いサービスを構築していく必要がある - 資源の無駄遣いの排除 - 必要性の低いサービスの構築 - 要件定義の不備による手戻り - 要件定義が曖昧なための高額見積もり - 考慮不足による機能改修の高額化 - 確保した人・物・金の資源の無駄遣いをなくして、よりサービスの向上を目指していただきたい。 ### (2) ソフトウェア開発と取引の諸問題の再確認 - ステークホルダーと、密に連携を取りながら、それぞれの立場でシステム開発に参加、関与し、必要な役割と責任を果たさなければ、満足のいくシステムは開発できない - 言葉 - 開発工程と作業内容（成果物の詳細レベル） - 保守の範囲（瑕疵、軽微な改修、機能強化） - 要件定義や役割分担 - 企画から要件定義、開発、運用に至るライフサイクルを通して、タスク、アウトプットは、暗黙の了解でなく、必ず明文化し、関係者で共有 - 誰が決定するかも明確にすることが重要 - ステークホルダーの合意 - 誰がどの段階で何を行えばいいのか、ライフサイクル上で明らかにしておく - 不明確な取引 - 外部委託に関して、発注者側からお願いしたい範囲、内容を明確にして、この範囲でお願いするということを明確に伝える - 見積もり - 要求が曖昧なままでは、見積もりは高額になる - 仕様変更 - 「仕様に含まれている、いない」、「ITのプロなら行間を読め」 ## 13. 標準類 ### (1) 開発プロジェクト標準 - システム毎に異なる作業プロセス・成果物の共通化・標準化が必要 - 受託業者毎の標準に依存しないもの - プロセスの区切りと成果物の具体化度を明確に - ステークホルダーとの関係、役割分担、対応姿勢を明確に - 可能な限り、世の中の標準に準拠する ### (2) 情報システム調達のための技術参照モデル（TRM）平成24年度版 - 分離調達に関する留意点 - スキル - 役務の分類 ## 14. 各種標準の概要 ### 14.1. 情報システム調達のための技術参照モデル（TRM）平成24年度版 #### (1) 分離調達に関する留意点 - 全体アーキテクトの確保 - システムの要件はプロジェクトの初期段階では曖昧で、システム開発が進行するに従い徐々に明確になっていく - 長期に亘るプロジェクトの場合、途中で要件が変化することも多い - 全体アーキテクチャの策定を行った事業者がシステムのサービス開始までのアーキテクチャの維持・改善を実現することが望ましい #### (2) 役務の分類 - 新規開発、システム更改、ハードウェア更改、機能追加（サブシステムレベル） - 改修（部分改修、機能追加、バグフィックス） - 開発プロセスを伴わないAP保守単体での調達 - AP保守以外の保守 - ポイント - 瑕疵担保はどこでやるか？ #### (3) スキル - 情報化推進（企画・調整） - 経営資源の配分（人物金） - システム化を通じた業務の変更 - 業務・サービスの向上のためのシステムの変更 - 全体管理アーキテクト - 技術面の整合性の確保だけではなく、業務面から見た整合性の確保も必要 - 複数プロジェクト（業者）間の責任分界点を適切に定義できる能力 - IT システムの設計に関する十分な経験に加え、システムがサポートする業務に対する知識 - 長期に継続するシステム化対象の継続的な変更への対応が軸になるため、業務についての将来的な見通し - 企画・調整から、サービスの開始まで関与 - アーキテクチャ策定と、個別事業者を統制するプロジェクトマネジメント能力 ### 14.2. 情報システム調達のための技術参照モデル（TRM）に基づく工程とアウトプット #### (1) サービスの構想 - 「使命・目標」 - 戦略的目標、年度活動計画 - サービス実施計画 #### (2) サービスの実施計画⇒サービス要件定義 #### (3) システム化構想立案⇒業務・システム最適化計画 - 現行システムの課題抽出（※現行システムが存在する場合） - システム化要望の調査 - 技術動向の調査 - システム化構想書の作成 等 #### (4) システム化計画立案⇒最適化実施計画（実施班作業） - システムの概要検討 - 設計･開発･移行･運用スケジュールの策定 - 概算見積もりの実施 - システム化計画書の作成 等 #### (5) 最適化計画の確認･評価･改善･効果算定（CIO補佐官） - 最適化計画の確認、評価及び改善提案、最適化効果の算定 #### (6) 要件定義（個別サービス毎） - 調達対象となるシステム、業務に係る要件定義 - スケジュール定義 - 業務･機能要件定義⇒サービス要件定義から導かれるもの - システム方式要件定義 - 情報･データ要件定義 - ユーザインタフェース要件定義 - 外部インタフェース要件定義 - ネットワーク要件定義 - ソフトウェア要件定義 - ハードウェア要件定義 - 情報セキュリティ要件定義 - 設計･開発要件定義 - テスト要件定義 - 移行要件定義 - 運用･保守要件定義 - 規模性能要件定義 - 信頼性等要件定義 #### (7) システムコストの試算 - 要件定義に基づいたシステムの構築･運用コストの試算 #### (8) 調達業務 - 調達計画書の作成、調達仕様書の作成、意見招請対応、事業者の評価等、調達関連業務 ## 15. 開発・運用の問題と解決に向けたアプローチ ### (1) 問題点 - 統合運用への引継ぎに手間がかかる - 職員担当者だけでなく、業者担当者も工程によって変わる - 個別システム毎にドキュメントレベル、手順が違い過ぎる→分かりやすい文書とは ### (2) 再確認事項 - 新しいTRMでの方向性の再確認 - 統合運用の委託の在り方 - 現在の契約の提案内容の再確認 - SMO→全体SI→統合運用 - 体制 - 統合運用業者と職員の役割分担 - システム運用担当は、どの程度、システムの内容に関する知識、ノウハウが必要か - 開発とAP保守と統合運用の役割分担 - 機能強化と軽微な改修 - 個別システムの運用 - 分担の再構成 - 実施準備 - 開発／運用の標準化 - 上流工程での運用設計 ### (3) 見直すべき事項（案） - 運用における業務システム運用係の負荷の低減 - 個別システムの開発内容の詳細及びノウハウを要しない形にする - 障害発生時の個別システムの保守事業者対応は統合運用業者に任せる - 開発から統合運用への引継ぎは業者間で直接行う - 統合運用業者の役割の明確化 - 旧システムでのSMOの役割の実施 - 業者体制 - 全体管理（全体SI、調達支援、工程管理支援） - 個別システム開発・構築事業者 - 個別システム開発・構築成果保守事業者 - 統合運用事業者 - 個別保守事業者への作業指示、作業結果の取りまとめ、統合運用管理職員への報告 - 職員体制 - 開発体制 - 開発、機能強化、瑕疵対応、開発を伴う保守（軽微な改修） - 運用体制 - 統合運用管理 - 原課との対応 ### (4) 見直しのスケジュール ## 16. IT人材確保 ### 16.1. 国のIT戦略 #### (1) 国の「新たなIT戦略」（IT総合戦略本部） - 省エネ社会の実現、遠隔医療の実現、自宅で働ける環境の整備等、幅広い分野でIT技術が活用される世界最高水準のIT社会を実現する（「情報資源／データ立国」へ） - 準備 - 統廃合、政府共通プラットフォームへの移行によるクラウド化等、今後の方向性を検討する #### (2) ITの利活用は課題解決の横串ツール（情報資源／データの活用が鍵） - データの収集（蓄積）／見える化／共有／連携／分析 - これらを可能とするシステムや仕組みづくりが必要 #### (3) 世界最高水準のIT社会の実現に向けて - 産業再興・経済活性化への貢献（イノベーティブな社会へ） - 国民の安全・安心への貢献（レジリエントな社会へ） - 行政機能や政策効果の向上を目指した「真の行政改革」への貢献（利用者視点に立った行政のデザインとガバナンスの強化へ） ### 16.2. NDLにおけるIT活用の位置付け #### (1) ITの位置付け - IT はあくまで手段。システムの導入にあたっては、既存業務の見直し、BPR を徹底的に行い、PDCA サイクルをしっかりと回していくべき。 #### (2) ITの活用 - 戦略的経営判断のためのICT - ERP、BPR、EPM - 図書館におけるICTの位置付け - 図書館サービスのためのICT - 職員業務改善のためのICT - 広報のためのICT #### (3) IT人材育成 - ライブラリアンからITスペシャリストへ - Code4Libに参加できるレベルのスキル ### 16.3. IT人材育成の必要性 #### (1) IT融合を進めるIT技術者育成 - 作る技術者から価値を生む技術者へ #### (2) ビッグデータを利用したサービスの創出において - これまでとは違った発想からアイデアを導き出す人材 - 技術からその産業にこれから求められるサービスまで横断的に分かる人材 - これらを社会に実装する人材など様々な人材が必要になる。 #### (3) 短期的には - 必要な人材は外から集めてくるというのは正しい #### (4) 長期的には - 一定規模の母集団があればという前提であり、この母集団を膨らませるには中長期にわたる施策が必要である。 - また、その産業も魅力あるものでなければ、母集団を形作る若い人材も入ってこない。 - このような母集団の形成を一企業や業界団体でやるとなると、その業界特有の常識が、革新的なサービスを創出するネックになることもある。 - ビッグデータを利用する産業や情報処理についての知識は必要であるが、 - それだけに縛られない垣根を越えた考え方をするようなITによる産業の融合を進めるＩＴ技術者を育成する必要がある。 ### 16.4. 必要なITリテラシー #### (1) 図書館の組織の在り方 - 日本の図書館がいつまでも前時代的な図書館のままでいいはずがない。 - 経営学には「生き残れる組織」に対する考え方がある。ビジネスの世界で生き残れるのは，大きな組織でも強い組織でもない。それは「変化できる組織である」とよく言われる。時代のニーズ，社会のニーズをとらえ，それをきちんと提供できる。そのために変化することには果敢に挑める。そのような組織。 - 今の図書館を変えたくない，という方も少なからずいることは，耳にしている。ただ，変えないことは組織の老化現象となり，いずれ組織／機関そのものが老化し，いずれ死に至る病となる。 - ICTに明るいライブラリアン像のひとつは，「自らネットやデジタルの世界で遊び，自分で課題を見つけ，自分で検索するなどして解決し，試しては壊し，壊しては創りをできる人」である。 #### (2) 必要なITリテラシー - これからの図書館員に求められるICT素養（リテラシー） - レファレンスサービスとしてのICT素養，サーチャー（情報検索技術者）としてW e b資源，オンラインデータベース等から適切な情報を得て利用者に提供できるスキルが必要 - 利用者サービスのためのICT素養 - TCP/IPによるネットワークの基礎知識，WiFi接続に対するノウハウ（特にWindowsマシンでは，本体内の無線LANのON/OFFや無線L A Nアダプタごとに異なる接続プログラムの操作方法など）である。また基本的な印刷やUSBメモリなどの取り扱いから始まり，We bサイトを作りたい，動画を編集したい，携帯音楽プレーヤーで音楽を聴きたいなど，実にさまざまなパソコンサポート - リレーションシップとしてのICT素養 - 本来のPublicRelations（社会との関係づくり）ととらえ，そこにデジタルやインターネットなどのスキルを使って情報を発信したり，利用者へのサービスを提供すること - システムライブラリアンとして - 図書館としての基幹業務が正常に動作しているか，不具合が発生した場合に対処できるか図書館員自身が行なえるレベルと業者が責任を持って行なうレベルとを把握 - デジタル資料の収集／作成／編集／組織化 - デジタルアーカイブからデジタル資源管理（デジタル・アセット・マネジメント）に対する考え方 #### (3) 職員のITスキルと組織の現状 - 図書館員一人ひとりの素養は，諸外国の図書館員と比べてもそれほど大きな差は無いのではないか - 意欲を阻害している要因があること - 一人ひとりの取り組みを活かせる仕組みがないのではないか - 全国すべての図書館にI C Tに明るい人材がいる， - ICT素養を発揮し，図書館サービスを刷新している人たちをネットワークでつなぐこと #### (4) 図書館の意思決定者に対する人材活用のアドボカシー（政策提言） - スキルを身につけたライブラリアンたちが，図書館の現場でその能力を遺憾なく発揮するための環境づくり #### (5) 前業務システム最適化、新利用者サービスの計画で目指したこと - ICTに明るい図書館員がWebを活用した非来館型図書館サービスの充実を図り、各種APIを取り込んだサービスを構築しやすい土壌をつくるため、図書館情報システムに共通のAPIを持つことである。