2018年4月に着任し、2020年3月に小笠原研究室から初めての卒業生(9名)が、そして、2021年3月には11名が社会に飛び立ちました。このサイトでは、卒業研究の研究概要(A4 1ページ)の「1. 背景」から抜粋した文章を載せてあります。研究概要からそのままコピーをしたので、図表番号、参考文献の番号もそのまま入っています。これらの情報は本サイトでは提示していませんのであらかじめご了承ください。

卒業研究のテーマを決めるのはなかなか難しいですね。基本的には、学生が興味を持っていることをテーマにするようにしていますが、うまく落とし込めなかったり、よくよく考えてみるとそれは興味のあるテーマではなかった、といったこともあります。テーマが決まらない場合には、私の方からいくつかのテーマを提示して、その中からさらに絞り込むということにしています。

あと、気に掛けていることは、できるだけ手を動かし「成果物」を残すということです。成果物の種類にはこだわっていません。プログラム、仕様書/設計書、マニュアル、ガイド、手順書など、「これを作り上げた」ということを体感してもらいたいと思っています。

プロジェクトマネジメント学科では、3年生から研究室に配属になり、3年生の後期には「課題研究」を行っています。研究概要(2ページ)を作成し、課題研究発表会で研究した内容を発表するのがゴールです。4年生では卒業研究を仕上げます。卒業研究では、研究概要(1~2ページ)と卒業論文(60ページ前後)を仕上げます。途中で、中間発表があり、最後は、卒業研究発表会で成果を報告します。3年生と4年生の2年間、研究活動をとおして成長してもらえるように、サポートしています(実際には、サポートというか、一緒に検討したり議論したりすることが多いです)。卒業してから、「あの時、あんなこと、こんなこと、いろいろあったけど良い時間だったな」と振り返ってもらえるようにしたいと思っています。
  1. 卒業研究リスト(2期生:2021年3月卒業生)
  2. 卒業研究リスト(1期生:2020年3月卒業生)

卒業研究リスト(2期生:2021年3月卒業生)

  1. はてなブログを対象にした面白さの指標の提案 -面白さ分析システムの開発-
  2. 面白いブログ[1]ですら,大量のつまらないブログの中で埋もれてしまうことがある.面白いブログならば,面白いと評価される必要があると考えた.そこで,面白いと感じるブログとそうではないブログの違いを調査し,面白いブログか否かをシステムで判断したいと考えた.

  3. オンラインイベントの評価に関する研究 ~U・Iターン者向け就職活動オンラインイベントの企画~
  4. 地域活性化をする要因の一つにU・Iターン者の貢献度が高いと述べられている.一方で,ビジネスIT[1]は,コロナウイルスの影響でU・Iターン者は増加傾向にあると示している.しかし, U・Iターン者をさらに増やすためには,それを呼び込むイベントが必要だが,新型コロナウイルス感染拡大防止のため,3密になるイベントは控える必要がある.そのため,オンライン形式のイベントを企画する必要があると考えた.しかし,現状,地域活性化させたい人達は,U・Iターン者をオンラインイベントで呼び込めるか不安を抱くことが多い.そこで,本研究で,U・Iターン者を呼び込むことを目的としたオンラインイベントを企画段階から評価するシステムを提案する.具体的には,従来の対面型イベントを企画書段階からイベント関係者に対して説明できるイベント自己点検システム[2]を応用して,オンラインイベントに適応できるシステムを提案する.また,提案するシステムを用いることで,企画書作成時などに使用することができるため,そのテンプレートを作成する.

  5. 「ブロックチェーン技術を使用したデータ流通事業」の課題の明確化
  6. 近年,電子データでやり取りされる仮想通貨が世の中に普及してきている.仮想通貨は,法的通貨とは違い国家による強制通用力がなくインターネット上での取引に用いられることが多い.また,仮想通貨の取引データの管理はブロックチェーン技術で行われており,分散型台帳として記録するためのテクノロジーとして開発・運用している.
    ここで,筆者はブロックチェーンを用いた企業を調査したところ,現物のある取引や信頼性の確保などにブロックチェーン技術の考え方を導入した事例は多く挙げられている一方で,データ流通といった仮想通貨以外のデータ取引にも活用されている事例があった.このことから,ブロックチェーン技術は,仮想通貨の取引だけではなく配送システムの管理や製造元の偽造防止などのデータ流通にも活用されはじめている.しかし,ブロックチェーン技術を導入する業種に応じた問題や,より良いサービスを提供するための改善点が存在すると考えられる一方で,明確化されていない.
    そこで,本研究では,ブロックチェーン技術を用いた企業や業種の事例を基に,ビジネスモデルやCustomer Value Chain Analysis(以下,CVCA)を用いることでブロックチェーン技術を用いた企業の課題を明確にする.

  7. コンクリート品質の安定性向上の研究 ~ エアメータ試験での空気量の安定化 ~
  8. 生コンクリートの製造現場において日々の品質管理は必要不可欠である.物が悪ければ信用されなく購入してもらえない.品質管理を怠ってしまうと,コンクリートがひび割れ,寿命年数よりも早く劣化してしまう.それによってコンクリートの強度不足などにつながる.このことから,コンクリート製造現場において品質を管理することは重要である.
    筆者は,来年度からコンクリートを製造する企業に就職することが決まっている.今年度,就職に先立ちコンクリート製造現場で業務を担当する機会を得た.その製造現場で担当する作業の一つとして,コンクリート製造時の「品質データの収集と分析」という業務を行った.
    生コンクリートを製造するときに加える空気量を安定させなければ強度問題に繋がるため,空気量を安定させることが重要である.JIS規格の空気量の基準値は4.5%±1.5%である.しかし,今回対象とした製造現場では,「品質データの収集と分析方法」は未整備であり,作業者の経験と勘に頼っている部分も多いという課題があった.

  9. ファンクションポイント法の計算ツールに関する研究
  10. ファンクションポイント法は,ソフトウェアの機能の大きさを示す指標となるものである.データの入出力など計測対象や計測基準が明確なため属人性が少ない,ユーザから見た機能で計測するため客観的説明性が高いといった特徴[1]があり,そのため,見積もりや工数管理等に使われている[2].ファンクションポイント法は「ILF,ELF」のデータファンクションと「EI,EQ,EO」のトランザクションファンクションの5種類の情報と複雑度,また任意の調整係数を評価してファンクションポイントを算出し機能規模を求める[3].
    しかし,ファンクションポイント法には課題がある.それは,難解であり習得に一定の時間や金銭といったコストが必要となること,作業負荷がかかることである.具体的には「ILF,ELF,EI,EQ,EO」の情報を求めること,ファンクションポイントを算出することが大きな負荷となる.特にこの作業負荷はプロジェクトマネジメントの初学者にとって重い負担となる.そのため,初学者はファンクションポイントを選択しにくいと考える.実際,PM演習では,簡易な概算見積もりが選択される傾向が強い.
    この様な課題から,ファンクションポイント法の難解さ,習得コストや作業負荷の高さを軽減する,計算ツールを提供することでこの課題が,解決すると筆者は考えた.

  11. 動画配信事業における動画製作フローの提案
  12. 2020年,国内の動画広告市場の規模が前年比14%増の2954億円になる見通しである(図1).その背景には,動画配信サービスやSNSの利用拡大があると考えられる.また,2021年以降も,大手電気通信事業者によるモバイル通信量の引き下げや,5Gの本格的な普及が開始されることにより,ユーザーのスマートフォンによる動画コンテンツ視聴は引き続き拡大すると思われ,今後も市場の拡大が見込まれている.
    この動画広告市場(特にYouTube)の拡大に目をつけ,多くの企業や個人がYouTube事業に参入してきているのが、毎分500時間のビデオがアップロードされ,全体で最も人気のある動画の10%が、視聴回数の79%を占めているYouTubeで新規参入することは容易でない.そして,TV業界等からの進出も多くなっている中,YouTubeの動画にもクオリティを求める思想が増えてきている.

  13. アジャイル開発におけるスクラムマスターの適正に関する研究
  14. アジャイル開発フレームワークのスクラムにおいてスクラムマスターという役割がある.しかし,スクラムマスターは過小評価されている傾向にあると述べられている[1].この理由に,プロジェクトマネージャーとの違いが分からないことや,役職として置く価値を定義しにくいからである.スクラムマスターはアジャイル開発の重要な位置である.なぜなら,スクラムマスターがいることで高いパフォーマンスのチームを作り上げ,スクラム運用のメリットを最大限に発揮できるからである.しかし,スクラムマスターは適当に選ばれているのが実情である.これだと,本来スクラムマスターに期待される,リーダーシップやコミュニケーションを活用したスクラム運用ができない.
    そこで,リーダーシップの適性を測るために用いられるPM理論[2]のようなマトリクスがあれば,スクラムマスターの適性を考慮して選ぶことができると考えた.ここで,PM理論は,Pm,PM,pm,pMの4象現で示し,リーダーシップの適性を図る考え方であるPM理論をスクラムマスターの適性を図るために活用する場合,目標達成能力であるP機能は目標を達成するために時には厳しく指示する能力なので,スクラムマスターの行うことではない.そこでスクラムでPM理論を使うために,目標達成能力であるP機能を自己組織化推進能力であるO機能(The self Organization promotion function)として変更することによってスクラムにおけるリーダーシップを測ることができるのではないかと筆者は考えた.このことから,本研究では,スクラムマスターが適当に選出されることで起こる問題に対して,PM理論を応用したスクラムマスターの適性を図るOM理論を提案する.

  15. プロジェクトマネジメント演習におけるCCPMツールのガイド作成
  16. プロジェクトのスケジュールを管理する手法の一つに,Critical Chain Project Management(以下,CCPM)[1]がある.CCPMとは,プロジェクトの納期を守るためにタスクに含まれるムダを排除し余裕時間(以下,バッファ)として納期前に集中配置し,そのバッファを基にしてプロジェクトを管理する方法である[2].
    CCPMは千葉工業大学の授業のプロジェクトマネジメント演習(以下,PM演習)という問題解決型学習PBL(Project Based Learning)で,チーム課題の一つとして取り上げられている.しかし,CCPMを選ぶチームは毎年12チームの内2~3チーム程度しかない.この理由は,CCPMが難しく,初めてプロジェクトをする初学者にはあまり向かないことや,CCPMをPM演習で実施するためのツールが少ないことが原因だと考えられる.
    実際に筆者が経験したPM演習でも,最終成果物の納期は守れたが,その過程で上手くスケジュール通りにプロジェクトを進行できなかった.この理由は,タスクの依存関係やタスク内にムダが多く含まれていため,それを考慮した計画が立てられなかったことにある.これは,他のチームでも同様に起こっており,PM演習において初学者は,タスクのムダに気づかないことが多い.そのため,スケジュールを管理する手法としてCCPMを使用すると良いと考えた.しかし,現状PM演習でCCPMを初学者が実施するのは難しいという課題があるため,本研究ではCCPMを初学者でも上手く推進するためのツールガイドを作成する.そのツールとして,Being Management3(以下,BM3)を使用する.BM3は,プロジェクトの開始日や納期,リソースの情報を直感的に一覧でき,プロジェクトの危険度や作業の優先度を色で表示できるツールである.

  17. ソフトウェア信頼度推定ツールの開発
  18. ソフトウェア信頼度推定ツールは現在ソフトウェア開発の現場において多用されるツールの一つであり,テストの消化数,累積バグ件数を同一グラフにプロットしてテストの進捗状況を確認する.また,そのグラフからソフトウェアの開発や品質状況を把握するためのガイドなども存在している[1].しかし,フリーで公開されているツールSRATS[2]には課題がある.それは,バグ曲線を表示しテストの状況を確認することは出来るがバグ曲線の推定モデルは一つしか表示していないということである.また,累積バグ件数とテスト消化数の2曲線からテスト状況の把握を行うことも出来ない.以上の課題があるため,信頼度推定に必要な要素が不足している.
    そこで,昨年,図1と図2に示すようなツールが開発された[3].しかし,図1に示す通り2つのモデル(ゴンぺルツ曲線,ロジスティック曲線)を同時に表示しており注目する推定曲線だけを表示することができなかった.この問題を解決するには本来図2でテスト結果を表示したい曲線が選択できるようにする必 要がある.

  19. 初学者がプログラミングを習得できる学習環境の提案
  20. 大学などのプログラミング演習科目では,30~40名からなるクラスを1名の教員と数名のアシスタントで指導することが多いため,個々の学習者に合わせた指導が行われているとはいえない.そのため,挫折してしまう学習者が少なくない[1].また,複雑な構造を持つ言語を用いると,多くの学生が挫折を感じるとともにプログラミング嫌悪症になる[2].そこで,比較的理解しやすい言語の一つであるScratchで基本を学びながら同時に,高度なプログラミング言語に挑戦すれば,理解がしやすいと考えた.
    このことから,本研究ではプログラミング初学者が抱える嫌悪症を感じることなく学習できる環境を提案する.具体的には, Scratchを習熟させると同時に,Python言語の問題を解かせることで挫折することなく言語の理解度を向上させる.

  21. テストケースの優先度と実行工数を考慮したテストケース選択ツールの開発
  22. ソフトウェア開発の規模は増大傾向にあり,同時に不具合を未然に防ぐためのデバッグやテストの重要性が一層高まっている. またソフトウェアのテスト工程は人手によるテスト実施が多く,膨大なテストケースを一件ずつ網羅的にテストを実行することは,制約のある時間で行うことは不可能である.
    テストケースの選択はテスト技術者の技術やノウハウに左右されることがあり,最も効果的なテストケースを選択できるとは必ずしも言えない.これに対して佐々木ら[1]は限られた工数の範囲内で効果的にソフトウェアの不具合検出を可能にするテストケース選択手法を開発し提案している.この手法はテスト履歴から不具合の割合と,テスト未実施期間の2つの観点からテスト価値を算出し,制約条件を満たすテスト価値が最大となるテストケースを選択する手法である.また,佐々木らはテスト管理システムの開発を行い,テスト管理ツールであるTESTRAPLUSにテストケース選択の機能として実装している.
    現在各テストケースの優先度と実行工数の両方を考慮した,単体としてのテスト選択ツールは存在しない.
戻る

卒業研究リスト(1期生:2020年3月卒業生)

  1. メトリクスの活用をナビゲートするプロセスの開発
  2. 現在,ソフトウェア開発の環境の変化は大きくなっており,製品開発におけるソフトウェア開発の比重は高くなり,ソフトウェア開発の規模が大規模になり,複雑化が進んでいる[1].
    しかし,実際のソフトウェア開発の現場では,ソフトウェアのソースコードの規模が数十万,数百万行に達する大規模のプロジェクトを数ヶ月のサイクルで行うことも多くある.この状況からソフトウェア開発の品質における欠陥やトラブルが増加してきている[2].この問題に対して,ソフトウェアメトリクスを活用することで,定量的に開発管理をして,開発状況の可視化や意思決定の根拠の明確化,問題の早期発見などの効果が期待できる点に着目した.
    ソフトウェアメトリクスとは,ソフトウェアライフサイクルのさまざまな特性から機械的に派生した定量的な計測規準である.しかし,メトリクスは,ソフトウェア開発の現場で積極的に活用されているとは言えない.その原因はメトリクスで何をどうすれば良いのか,どのように活用すれば良いのか分からない場合が多いと考えられる.また,メトリクスを現場で効果的に活用するためには,メトリクスとデータ分析の両方の知識が必要になる.
    そこで,本研究では,PMBOKにおける各プロセスの成果物の品質状況や進捗状況を把握したうえで,プロジェクトのどのプロセスで,どのメトリクスを活用すると効果的にプロジェクトが進められるかをナビゲートするプロセスの開発を行う.

  3. ソフトウェア信頼度推定ツールの開発
  4. ソフトウェア信頼度推定ツールは現在ソフトウェア開発の現場において多用されるツールの一つであり,テストの消化数,累積バグ件数を同一グラフにプロットしてテストの進捗状況を確認する.また,そのグラフからソフトウェアの開発や品質状況を把握するためのガイドなども存在している[1].しかし,現状フリーで公開されているソフトウェア信頼度推定ツールは扱いづらいものが多く企業内で代わりとなるツールを製作してテスト記録を行っているのが現状である.フリーで公開されているソフトの中でも代表的なツールの一つにSRATS[2]がある.SRATSではバグ曲線を表示しテストの状況を確認することは出来るがバグ曲線を一つしか表示していない.また,累積バグ件数とテスト消化数の2曲線からテスト状況の把握を行うことも出来ない.そのため,信頼度推定に必要な要素が不足している.また,SRATSは英語表記であり日本人にとっては言語面で扱いづらいなどユーザーインタフェースの側面で見ても問題点が存在する(図1).
    現状,フリーで公開されている信頼度推定ツールは推定のために必要な要素や言語面で課題がある.そのため,これらを解決することで,より簡単でかつ扱いやすいツールの開発をする必要がある.

  5. ゲーミフィケーションの事例分析及び進捗報告手法の提案
  6. プロジェクトの進行を妨げる要因の一つとして,メンバ間での進捗状況の把握等ができていないというものが挙げられる.これはメンバ毎の達成率の基準がずれている事や進捗状況の把握が難しい事,進捗の遅延等マイナスな報告を避けてしまう事が原因になる[1].この対策をプロジェクトでは進捗管理ツールを導入することで継続的に進捗状況の報告をさせると共に,進捗管理の作業効率向上図ることが多い.しかしながら,マイナスな報告を避けてしまうメンバや報告を疎かにしてしまうメンバに対しては情報の視覚化や管理のしやすさだけでは対策になるとは言えないため,別の対策が必要と考える.
    上記の問題を解決するため,マイナスな報告があるメンバでも自主的に報告するようなプラスのイメージを進捗報告プロセスに加えられないかと考えた.その一つとして達成感の向上や報告に対するモチベーション向上を目的としたゲーミフィケーションの手法を導入した進捗報告の手法を提案する.また,その問題に対してゲーミフィケーションを導入した効果を評価する.

  7. テスト自動化ステップの導入ガイドの開発
  8. 現在,製品の機能や価値がシステムやデジタル情報処理によって提供されるようになり,ソフトウェア開発規模が飛躍的に増大している.しかし,その多くは人手で行われており,コスト削減の余地がある.人手で行っている以上,漏れやミスは防げず,コストも増大している[1].システムが利用される環境の多様化により多量のテストを短期間に行う必要があり,テストの質と量に対する要求が増大している[2].そして,現在,安価で,高度,かつ操作しやすいテスト自動化ツールが普及しはじめている.それによってツールによる,テスト自動化導入成功事例が増加している.一方で,テスト自動化ツールを購入してはみたものの,うまく使いこなせずに断念してしまう例が出てきている.導入したいが,二の足を踏んでいるという声も多数聞く.ツールを購入したが様々な開発部門では導入がうまく進んでいないということが見受けられる.
    そこで,本研究では,実践に基づくテスト自動化ステップの留意点についてまとめ,テスト自動化を失敗せずにやり切るための手順とポイントを『導入ガイド』として提示しようと考えた.

  9. プロセス改善推進のためのガイドの開発
  10. ソフトウェア開発の現場の実態として,開発費の総額は減少傾向にあるものの,ソフトウェアの開発費の割合は年々増加している(開発費が圧縮できていない).また,新規開発よりも既存のソフトウェア資産を流用した開発が多い(半数以上が既存資産を流用した開発である).ソフトウェアリリース後の不具合発生件数は年々増加している.ソフトウェアの品質問題が発生した際,プロセスの見直しが再発防止策として最も実施されている.
    開発者の役割には組織の改善が含まれない事が多い.プロセスの改善活動には,設計・実装・テストなどの開発者の業務スキルとは異なる専門のスキルが必要であるにも関わらず,開発者がこのスキルを業務から学ぶ機会はほとんどない.改善活動がうまく進まない背景にはこのような開発現場の現状がある.
    日本SPIコンソーシアム(JASPIC)が主催しているSPI Japanというソフトウェアプロセス改善活動で得られた技術や知見を総集し,その普及と技術力向上の場を提供するためのイベントがある.プロセス改善の最も権威のあるこのシンポジウムでは,毎年,各社から30~40件のプロセス改善の発表がある[1].しかし,SPI Japanでは,自分達の問題に対応する事例を見つけるのが難しい.それは,SPI Japanで毎年,各社から30~40件の発表がされているが,ジャンル毎のプロセス改善の分類分けがされていないことが問題である.

  11. 初心者向けプロジェクト管理プロセスの提案
  12. プロジェクトを行う際に,プロジェクト管理が大事である.そのために,PMBOKが提案され,活用されている.PMおよびPJメンバがPMBOKをより良く理解して実践することが大事である.しかし,経験の浅いPMが使いこなすのは難しく,自分で勉強しようとしても困難である[1].
    PM演習を例に挙げると,週毎に個人の工数と実績を登録し,EVMで管理している.しかし,個人がどのような作業を行い,どの作業にどのくらいの時間を使っていたのかは把握できていない.また,成果物の規模しか把握していないため,品質の確認は十分にできていないことが多い.
    つまり,現状把握→分析→改善というサイクルが回らないことになる.個人の能力を高める代表的な方法としてPSP(Personal Software Process)がある.PSPは作業の方法を制御し,管理することで,自らを改善できるように設計された自己改善プロセスである [1].しかし,これは,ソフトウェア開発の設計や実装の能力向上のためのプロセスであり,PMとPJメンバの能力向上に適した内容にはなっていない.
    そこで,経験の浅いPMおよびPJメンバにもPSPを活用して,個人のプロジェクト管理の能力を向上させる必要があると考えた.

  13. 組合せテストにおける不具合インタラクションの特定に関する研究
  14. ソフトウェアシステムの信頼性を高めるため,テストは重要な工程であるが,一方でコストが非常に大きくなることがある.組合せテストは不具合検出能力を低下させずに,コストを抑えるテスト手法である[1].
    組合せテストの例として図1,表1がある.図1は,原稿サイズ,用紙サイズ,分割,カラーの4つの項目(因子)に対して,それぞれに3つのパラメータ値(水準)があるプリンタ印刷設定の例である.この図1を基にして組合せテストを行う場合,テストケース生成には4因子それぞれに3つの水準があるため,すべての組合せのテストを行うと81個のテストケースが必要になる.81個のテストケースの中から2因子をどのように選んでも,値の組合せ(インタラクション)がすべてテストケース集合の中に現れているという条件を満たしたときに生成されるテストケースが表1である.表1のようなテストケースを生成したテストを実施したときに不具合が検出された場合,どの組合せで不具合が検出したのかを特定するには,多数の組合せパターンを確認する必要があるため,時間がかかることが多い.
    そのため,本研究では不具合発生時にどのインタラクションが不具合を起こしているかを推定する手法の提案を行う.

  15. 操作順序を考慮した組合せテストの研究
  16. 近年,ソフトウェアの多機能化に伴いテスト工程が増加しているが,テストに投入できる時間が限られている.また,品質に対する要求は以前にも増して高まっているのが現状である.こうした課題を解決するために考え出された効率的な組合せテスト技法は,大規模,複雑化するソフトウェアの組合せテスト件数を大幅に削減することが可能な技法である.この技法には,直交表とオールペア法の2つがある.ここでは直交表を例に説明する.直交表とは,実験計画法で用いられる表のことでコスト・スケジュールの制約によって,すべてのケースで実験できない時などに用いる.因子とその水準が均等に現れる実験条件を決めるために一つの列の各水準の中に,他の列の各水準がすべて同回数ずつ現れるように作られている.ソフトウェアで組合せテストをする際,すべての組合せを実施することは実質不可能であるが,直交表を使用することにより,組合せテストの効率化を図ることができる.
    しかし,先ほど紹介した技法には問題点がある.それは,テスト実行にあたっての組合せの操作順序については何も言及していないことである.これにより因子の順序関係による不具合の見落としの可能性が存在する.

  17. “売れる”営業チームマネジメントの研究
  18. 営業職は,「営業部門が弱い.昨年も目標達成できなかった.何とかしたい」という悩みや相談が,よく飛び交う職種である.目標未達の状態が続くのを何とかしようと,企業は2つの方法を考える.
    第一は,営業マネージャの訓練であり,営業管理職研修に社員を派遣する.
    第二は,営業担当者の訓練である.これも,営業担当者研修に社員を派遣する.
    しかし,どちらもなかなか成果に結びつかない.前者の場合は,マネージャが習ったことを実践しようとするが,部下たちを上手く巻き込めず,「学んだだけ」で終わるケースがほとんどである.また後者の場合は,営業担当者一人が研修で習った新しいことを始めようとすると「そんなのはいい.それよりこっちだ」という上司の指示が飛んできて,結果的に行動に移せないケースも少なくない.
    こうして,マネージャも営業担当者も研修には行ったけど効果が上がらない状態が続く.
    営業成績を生み出しているのはマネージャや営業担当者という個人ではない.支店や営業所,部や課単位のチームである.そうであるならば,「個人でなく,チームをより良いチームに変える」そのような研修プログラムを提供すれば,目標達成できるはずだと考えた.
戻る
Last Update:2021/08/13