平成28年度秋期 システムアーキテクト 午後Ⅱ 問3

OSS導入を評価するための視点

OSSの導入を考えるときは、目先の便利さや費用だけに寄せず、利用後も継続して管理できるかという観点に絞り、担当者、変化への対応、問題時の備えを順序立てて整理しましょう。

この問題で問われていること

判断の中心を、導入時に得られる効果だけではなく運用期間全体の持続性に置き、管理の担い手、更新への対応、問題発生時の備えを同じ基準で見比べ、長期的な負担も確認してください。

視点

OSSは導入時点の機能だけで評価せず、利用を続ける間に誰が状態を把握し、変化へ対応し、必要な支援を確保できるかという長期的な管理の視点で整理します。

確認ポイント

• 導入後の管理を担当する主体と役割が明確か
• 更新や仕様変更が起きた場合の確認方法を考えたか
• 障害や脆弱性が見つかった際の対応体制を確認したか

解説

本問は、組込みシステムへのOSS導入を題材に、導入目的、利点と注意点、関係部署との協議、ソフトウェアの組合せ、開発後の判断と今後の対応を一貫した実経験として論述する問題です。

問題の全体像

問題文は、組込みシステムで高度な機能と短い開発期間を両立するため、LinuxやAndroidなどのOSSを外部技術として利用する場面を示している。OSSには無償利用、既存成果の活用、デバイスドライバや標準的なインタフェースによる利便性がある一方、保証・サポートがないこと、ライセンスによっては自社開発部分の開示が必要になること、性能要件や独自ハードウェア制御のために改変・組合せが発生することが注意点として示されている。したがって、単にOSSを使うか否かを書くのではなく、自分が携わったシステムで何を目的に導入を検討し、関係部署とどのリスクを協議し、OSS・市販品・自社開発ソフトウェアをどのように組み合わせ、開発時の結果を踏まえて判断を評価したかを、設問アからウまで一貫させて述べる。出題趣旨では、利点・注意点、協議内容、適用方法、判断の妥当性を具体的に論述することで、システムアーキテクトに必要な設計能力と統合力を評価するとしている。採点講評でも、問題文の観点を一般論として並べるだけでなく、実際に検討・協議したことを具体的に書くことが求められている。

設問ア

まず、後続の設問で使う一つの組込みシステムを具体的に設定し、製品・装置の目的、利用者、主要機能、開発上の制約などを簡潔に示す。その上で、社内にない技術や標準機能を短期間で実現する必要、顧客からのOSS指定、開発費や納期、既存資産の活用など、OSS導入の是非を検討するに至った経緯を書く。目的は「OSSを使った」ことではなく、開発期間短縮、標準機能の利用、対応機器の拡大など、対象システムの課題解決として明確にする。800字以内なので、システム概要、検討の契機、導入目的を後続の設問で詳述できる粒度に絞り、利点と懸念を一つずつ示して問題意識を作るとよい。採点講評が重視する実体験の具体性に合わせ、一般的なOSS論ではなく、自分の担当範囲と検討対象を明らかにする。

設問イ

設問アのシステムを前提に、OSS導入の是非を決めるため、どの関係部署と何を協議したかを具体化する。例えば、開発部門だけでなく、品質保証、法務・知財、調達、製造、保守、営業・顧客など、実際に影響を受ける部署を挙げ、性能、品質保証、ライセンス遵守、脆弱性対応、納期、費用、保守責任などの論点と協議結果を結び付ける。さらに、OSS、市販品、自社開発ソフトウェアを機能・責任範囲・変更可能性などで比較し、どの部分をどの方式に任せるか、インタフェースをどう定義するか、OSSを改変する場合の管理や将来の更新をどうするかを述べる。重要なのは、利点と注意点を列挙することではなく、システム要件に照らして組合せを選んだ理由と、関係部署との合意形成の過程を示すことです。800字以上1、600字以内のため、協議相手、論点、選択肢、採用した構成、リスク低減策を複数の段落で具体的に展開する。採点講評でも、OSS導入の検討への関与が分からない説明や、システムの説明だけにとどまる論述は不足とされるため、協議と適用方法を中心に書く。

設問ウ

開発段階で実際に発生した課題を、設問イで選んだ構成と関連付けて述べる。性能不足、改変による不具合、OSS更新との適合、ライセンス確認、品質保証や保守の責任分担など、実際の開発で現れた問題を取り上げ、その原因、対応、結果を具体化する。その後、設問アで掲げた導入目的がどの程度達成されたかを、納期、機能、性能、品質、費用、保守性などの観点で評価し、導入を採用した、範囲を限定した、又は見送った判断がなぜ妥当だったかを説明する。最後に、今後のOSSの更新・脆弱性対応・ライセンス管理・担当者育成・再利用方針など、開発後の対応を示します。600字以上1、200字以内なので、課題、対応、達成度、判断の妥当性、今後の対応を漏れなく押さえつつ、結果を抽象的な反省で終わらせない。採点講評が求めるのは、開発時に検討し取り組んだ実践経験であり、既存システムの説明や構成要素の列挙だけでは評価されにくい。

学習のポイント

OSSの知識だけでなく、設計上のトレードオフを整理し、関係者を統合して判断した経験を具体的に書く力が重要です。