GIGAスクール構想の実現 教育情報セキュリティポリシーに関するガイドラインの改定を読んでみた
はじめに
２０１７年１０月に発表されていた教育情報セキュリティポリシーに関するガイドラインであるが、２０１９年１２月に改定があったので、さっそく読んでみた所感を述べる。
背景、改訂の方向性
引用：文部科学省 教育情報セキュリティポリシーに関するガイドラインの改定について 概要資料
コメント
いよいよ、教育の分野でも、クラウド・バイ・デフォルトの原則が明文化されましたね。
校務系、学習系のネットワークの分離についても、誤解がないよう改訂されたようです。
要は、セキュリティをきっちり担保すれば良いということです。（⇒これが仕組み化するのがしんどいのですけどね・・）
今まで、どうしても校務系にあるデータ（日々の生徒所感、成績、健康診断のデータなど）の活用の道を示すのが難しかったのですが、国単位でガイドラインを改訂してくれたおかげで、今後、データの利活用ビジネスが教育分野においても展開していくと思います。
しかし、ガイドラインが改訂されたからといって、教育委員会や現場の方々の「セキュリティ本当に大丈夫なの？」という不安はまだあると思います。 オンプレミスがあたりまえ、校内ネットワークはインターネットとつながらないが当たり前の学校さんが多いためです。
さらに、校内LANの整備や１人１台のPC導入の検討も進めて行くことになるため、検討事項は山積みです。
このように、便利にはなりそうだけど、多くのことを考えなければなりません。
私はベンダーの立場なので、こういう現場の苦労部分をトータル的にサポート、整理できるような、ご提案ができればいいなと考えています。
問題解決パレット
普段の仕事で大事にしている問題解決の取り組みについて記載します。
問題解決の必要性の検討
そもそも、問題解決すべきかという話です。
個人では問題だけど、チームとしてどうか、プロジェクトとしてどうか、お客様からみてどうかを検討しています。
たとえば、プロダクトのバグであっても、お客様の視点では、迷惑がかからないものもあります。
そのようなバグであれば、無理に現状の作業を手戻りさせる必要はありません。
次改修時に一緒に対応するといった判断もありです。
後は、代替手段があるかどうかです。 代替手段により、直接の問題を回避できるのであれば、 問題解決の手段として取り入れることを検討します。
その上で、解決が必要であれば、以下のパレットを活用して情報収集します。
問題解決のパレット
解決したい問題に合わせ、情報収集の確度が上がる媒体を選びましょう。
欲しい情報を自ら生み出す呼び水となれ
解決したい情報を「確認系」領域でピンポイントに探すのは、時間がかかりすぎる場合があります。
そのような場合には、欲しい情報を自ら積極的にまとめ、有識者に聞くといった「質問系」領域の問題解決を心がけましょう。
アジャイルなプロジェクトの契約と問題の回避方法
アジャイルなプロジェクトを運営するために、どのような契約手法が良さそうなのか、様々な事例を見て得た知識を発信します。
理想の契約
理想は、すべて準委任契約で進めるのが良いと思っています。
マネジメントさえ間違いなければ、不要なプロセスやモノを作らずに済むからです。
ユーザ側、ベンダー側両者に言えることです。
たとえば、不確実性の高い事柄を予測するプロセスに過度にリソースを使わなくて済むし、一度実施を決めたプロダクトやドキュメントがあまり役に立たなそうであれば捨てて、他のことにリソースを使用することも可能です。
現実の契約
しかし、世の中の事例を聞く限り、すべて準委任では進められないケースもあります。
たとえば、ユーザ側が、発注リスクを抑えたいがために、無茶な契約を提案してくることもあるそうです。
「契約は請負で、開発だけスクラムで」とか、「イテレーション単位(2週間)で契約を結ぼう」とかです。
1つめの契約はベンダーにとっては悪魔の所業ともいえるようなものに感じました。
2つめは期間が短すぎますよね。開発案件の契約作業は少なくとも1週間はかかると思います。
それを毎イテレーションごとにするのは、お互い大変です。プロダクト作りとは違う部分で時間とお金を流し続けます。
発注者側は知らないかもしれませんが、見積にはそれなりに時間とお金がかかっています。
一方、ベンダー側も実力がなく、時間だけ浪費し、ユーザー側に大きな負担を背負わせる場合もございます。
だから、準委任だけの契約はなかなかできないのだと思います。
改善案
では、どうするか。
他の企業様での取り組み事例を聞く限り、2つの案を耳にします。
すべて準委任は難しいという方々は、検討してみてはいかがでしょうか。
事例1は、先程話題に出た2週間単位の契約ではなく、2～3ヶ月くらいの単位で契約した事例です。
少々長めに契約することで、ユーザはプロジェクト失敗のリスクを小さくできますし、ベンダーもプロダクトづくりにある程度集中できるはずです。
事例2は、要件定義だけ準委任でまずは開始。ドキュメント作りだけでなく、モノも作ります。
ユーザからのフィードバックをもとに、プロダクトの方向性や要件をしていきます。
両者にとって有益な効果が示されれば、後工程もアジャィルな開発ができるよう、スクラムなり、XPなりを採用して開発を進めればよいのです。
ここで言う良い効果とは、プロダクトに対する良いアイディアが生まれたり、ベンダーの腕が証明されたり、ユーザの案件参画度合いが熱心で、ベンダーを下請けでなくパートナーとしてみてくれる等を意味しています。
事例2に関しては、他社事例だけでなく、自社の事例(ベンダー目線)もございます。
とあるウォーターフォール型、段階リリース前提のプロジェクトがございました。
１段階目の受け入れテストで、ユーザからの不満が多く、追加要求も多く、信頼関係は崩れておりました。
そこで、２段階目のリリースからは、すべてアジャイルな開発に切り替えました。
手法はスクラムです。１～１．５ヶ月単位の長めのスプリントです。
その結果、ユーザの信頼改善に繋がりました。
モノに触れることで、早期に業務イメージがわいたようで不要な仕様を排除できました。受け入れテストでも「これじゃあ業務が回らない」と言われなくなりました。
契約の問題を回避するための取り組み
上記の契約をうまく結べたとしても、案件が開始してから問題は出るものです。そこで、少しでもその問題を回避できるような案を考えてみました。
アジャイルな開発(お客様との協調が大切等)の価値観を共有
プロダクト価値を最大限に引き上げるためです。たとえば、アジャイルな開発では、顧客との協調を大事にする価値観がございます。たとえ問題が発生しても、顧客とベンダーが案を出し合い協力することで問題解決を早められる。だから、顧客との協調を大事にするのです。
他にも大事な価値観があるので、アジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則は、皆で読み合わせをしたいものです。
プロダクトのゴールやプロダクトを作る理由を確認
我々はアジャイルな状態で開発ができているかを問いかけ、今後のプロダクト作りの判断(今何をすることが価値が高いか)精度を上げていきましょう。
このような判断ができれば、膨大な要求が出たとしても、皆で、今後どの要求を取り入れるべきか選択できるようになります。
必須要求以外の要求は調整対象になりうることを伝える
アジャイルな開発といえど、通常、期間と予算には限りがあるためです。
開発スコープの広さは大枠で考えると思うのですが、中身の深さは調整対象(必須でない要求)にすることを共有しないと、トラブルの元となります。
調整の仕方の例として、データ閲覧画面がほしいという要求で、最低限、月ごと、部署ごとの○○データに絞って閲覧できるようにするのが必須要求だと決めたとします。
この要求の中で、たとえば、部署ごとのランキングを表示したい、年間のデータ件数グラフも表示したい等の要求は必須ではないので検討が必要です。
たとえば、プロダクトにとってメイン機能であれば、他の機能を削ってででも取り込むという検討結果はありです。一方で、サブ機能であれば、要求があったことは残すが、開発対象には現段階で入れないという検討結果もありだと思います。
このような検討ができるように、業務運営上ないと業務ができないもの、プロダクトをつくる価値がゼロになってしまうといった必須な要求と調整対象の要求を説明しましょう。
何でもかんでもプログラミングしない
プログラミングはコストが高いためです。
要求を多少整理し、価値が高そうだと思う機能に関して、開発を進めるのが良いと思います。
優先順位や重要度を考慮ぜず、とりあえず機能を作るのは時間がかかります。プログラムを作るだけが、アジャイルな開発ではありません。
紙芝居で業務イメージが十分にわく、また、次の開発につなげるフィードバックが得られるのであれば、プログラミングをするのではなく、紙芝居で済ませるのもありです。
もしくは、重要度が低い機能であれば、いっそのこと作らない、より重要度の高い機能を開発スコープに入れる。
プログラミングだけでなく、価値あるプロダクトを早く作る営み全般がアジャイルな開発だと考えています。
おわりに
アジャイルな開発はとても価値あるものだとおもいます。
一方で、単純な請負契約と違い、まだまだトラブルも多いはずです。
わたしもまだまだ素人です。
他にも、こんな契約形態とったらお互いうまく行ったよとか、逆に、失敗したよ というお話を聞かせていただけると幸いです。
参考サイト
以下、契約関連で参考になりそうなリンクを紹介します。
参加レポート RPA DIGITAL WORLD TOKYO 2019
はじめに
12/9(金) 東京国際フォーラムで行われたRPA DIGITAL WORLD TOKYO 2019に参加しました。
最新のRPA動向やRPA導入の苦労話、ノウハウを聞けるので、次回も参加したく思います。
1つだけ反省点です。予約を1週間前くらいにしたのですが、遅かったらしく、ハンズオンや小さな人気セッションは、満席で入れなかったですね。
次回は、もっと早く予約しよう！
セッションの傾向
以下のような印象でした。
１）RPAと関連技術の組み合わせ
RPA-OCRの紹介が多かったです。
全体的に判断にAI絡めるなど、RPA＋αするフェーズになってきている感じを受けました。
例えば、アビームコンサルティング社は、RPA-OCR-Chatbotを使って領収書処理の自動化をしていましたね。
２）RPAに付随するビジネスの紹介
RPAの属人化を防ぐためのマニュアル作り、自動化候補となる業務抽出サービス、RPA人材派遣サービス
３）サーバ型、デスクトップ型
サーバ型のRPAが増えてきている印象。ロボット導入が増えたことによる一括管理や野良ロボット対策。 個人レベルではなく組織的改善に取り組む場合にも適していると思われます。
デスクトップ型のように、PCつけっぱなしも防げます。
学んだこと
※@以下はセッション登壇会社
顧客からの要望
- 万全な問合せサポート@クレオ
早いほうが嬉しい。情報(ログや画面キャプチャ)を提供すれば、確実に解決出来ると思いたい。
だから、画面共有のサポートを用意した。 - マニュアルを作って欲しい@クレオ
TENDA社のDojoを組み合わせている。システム操作手順をキャプチャーし、自動で手順書を作成してくれる。
TENDA社はRPA対象業務の分析と効果予測をしてくれる製品D-Analyzerも扱っている会社。
ロボットを作る部隊と業務部隊が分かれる組織で需要があるそうです。 - RPA導入理由@RPA Community
①作業の時間的、心理的負担の削減
②人員の再配置
③対外アピール
- RPA導入理由@BluePrism
①業務委託、BPOをRPAで代替（アウトソーシング）
②定形作業から社員を開放。働き方改革
③高付加価値業務、ボトルネック業務を社内が行える
RPA導入業務例
目指す削減工数@デジタルフォルン
自動化された年間工数：中央値13,000時間/年（電力、ITベンダー、金融除く）である。 まずは、この数値を目安にしたら良いのでは。導入事例（営業）
- 請求書発行
- 売上実績登録
- 売上集計レポーティング
- 見積製品の最新価格チェック
導入事例（人事・総務）
- 期間満了予定者のチェック
- 入退室時間のチェック
- 勤務時間管理
- 健康診断の未実施者へのフォローメール
導入事例（マーケティング）
- 競合価格調査
- 口コミチェック
- 株価チェック
- バズワード掲載サイトチェック
導入事例（経理）
- 投資ガイドラインの違反チェック
- 貿易書類のチェック自動化
導入事例（IT部門）
RPA導入成功例
- 早期に経営効果を出すための普及シナリオの検討@パーソルキャリア
- ロボの共通部分化（スニペット化）が大切@パーソルキャリア
メンテナンス工数を減らせる。
例えば、名前や年収を入れるプロセスなど、必ず入力項目にあるようなものをスニペット化。 - 事前の実態調査@パーソルキャリア
連携先WEBサイトがいくつもある場合、その利用実態を調べてみる。
実際、2社だけで5割超えの利用率となった。つまり、ロボット化はその2社を基準に作成すれば良い。 - 受け入れやすい業務プロセスの設計@パーソルキャリア
負荷を増やしたり、プロセスの大幅変更はNG - 戦略を立てる@パーソルキャリア
目的(Why)、ゴール(経営効果)、登り方(成功事例の展開)の定義。 人材@パーソルキャリア
RPA伝道師を作る、増やす。受け入れてもらう工夫@パーソルキャリア
RPA化のメリットを説明。実際に触ってもらって納得してもらった。
この会社では、メールのような非構造化データを扱う部分を、WEB入力に業務変更してもらったとのこと。
非構造化データを扱いづらいというのは、RPAの都合である。 その部分に対してのアプローチとして参考になった。 BluePrismも似た改善で効果を上げた事例をパンフレットで紹介していた。 業務に必要な情報が3つのDBに分かれていたものを統合したそうだ。デジタル従業員を作る考えを持つこと@BluePrism
何十万の削減時間はどこにいったという企業が多い。 経営効果(人員の再配置など)が出て初めて効果ありと言えるのでは。
例えば、バックオフィス人員を７０から５０人に削減し、再配置。
削減した工数を非優先業務に置き換えたら何も意味がない。経営効果を定義しよう。人事評価とRPA推進をつなげる@BluePrism
RPAのロボット作りをボランティアにしてしまうと、大きな改善は見込めない。 目的を持って戦略的に。人事考課にもきっちりつなげることが大切。
RPA導入失敗事例
- 組織人数があまりに少ない。4名かつエンジニアのみ。@パーソルキャリア
「RPA導入する→業務改善する」ではない@RPA Community
改善には濃度がある。数%しか改善しない場合もあれば、100%改善することもある。 RPA導入を0、100で考えない。 業務整理しないまま、とりあえずRPA化することはやめよう。RPA提案のNGワード@RPA Community
提案する企業によっては、ざわざわしたり、怒られが発生するワードがある。
例）
「価値のある作業を」
「付加価値の高い作業を」
「単純作業を」
「無駄な作業を」
「24時間365日働ける部下ほしくないですか」
⇒「そんな無駄な仕事でも誇りを持ってやっているんだ」と言われたことがあるらしい。
⇒そこで、言葉を見直した話を聞けた。たとえば単純作業を定型作業に。
⇒社員に寄り添う姿勢が大切。RPAは人の仕事を奪うツールではなく、人と共存するツール。RPA化を目的にしてはいけない
どのセッションでもおっしゃっていた気がする。- 不安定だからといって諦めない。@デジタルフォルン
RPAはすべてがカンタンではない。不安定な動作も起きうる。
しかし、自動化した場合の効果が高いのであれば、自動化に挑戦すべき。
気持ち的な話
まずは試してみよう。
これなら簡単にできそう、人に勧められそう、という手応えが得られる。「早くカンタンに作る」という言葉は何かを犠牲にしている。本当にいいことなのだろうか。@BluePrism
実はメンテナンス性を落としていないだろうか。
ユーザに負担をかしていないだろうか。
Blue Prismの強み
もっとたくさんあるのだろうけど、一番学びが多かったのでご紹介。
- RPAという言葉を生み出した企業 RPA老舗ならではの知見を提供してくれる。
セキュリティ
ログが強み。ロボットが何を登録したかまでログ出力してくれる。監査で使用可能。
他社の場合、ロボットが動作したかどうかはわかるが、何を登録したかまではわからない。ライセンス
ライセンス費用は本番環境のみ発生。素敵！
また、ロボットの同時稼働の数が課金対象。同時稼働させなければ費用がかからない。
1ロボットあたり120万円/年。- すべてサーバ型
セキュリティが主な理由と理解した。 野良ロボットが動くのを防ぐため。 ロボットやその利用者を適切に管理するため。 個人業務をガンガン改善したい人には向かない。
AI OCR “Tegaki(手書き)”
Tegakiは、手書き書類をスキャンして取り込むだけで簡単にデータ化して保存ができる手書きOCRサービス。RPA-OCRを紹介していたほとんど企業がコレだった。
セキュリティ
入力項目ごとに分解し、ばらばらにサーバに送信する技術もある。
例えば、アンケート用紙であれば、個人が何を入力したかわからないよう、名字と名前とアンケート項目をそれぞれ別のタイミングでサーバに送信する。接続性
Tegaki単体だけでなく、APIから利用することも出来る。 APIを用いて、Tegakiのクラウドサービスと連携する。
VPNや専用線接続も検討してくれる。- 性能
手書き文字認識率99.2%
チューニングも出来る。例えば、この項目はカタカナのみ と定義すると、認識率の精度が上がる。
しかし、チューニングも時には仇となるようです。
デモに参加したのですが、わたしがたまたま、カタカナチューニングされたフリガナ部分を、ひらがなで記載したら、まったく意味不明な回答が返ってきました。
AI OCR “Tegaki(手書き)” ご紹介資料 株式会社Cogent Labs
日本マイクロソフトの週休3日制から何を学びとるか
SNS上で話題になっていた、このニュース。自分の職場でも何か導入できないか考えてみました。
8月の金曜日を休業日とする週休3日制を試験的に実施した日本マイクロソフト このほど、生産性が大幅に向上するなどの効果があったと発表した 1人当たりの売上に換算した生産性は、前年同月比で40％ほど向上したそう
自分の職場で実践できそうなものはあるか
正直、週休3日制の導入を自分の職場に導入することは難しい。会社の人事改革をするのは、とても苦労するからです。 他にもっともっとおもしろい仕事がある中で、個人で、わざわざ手を出す必要性までは感じておりません。
// そういう人が多いから日本人変わらないのか 苦笑
でも、「これなら自分でもできるのでは？」というものを、当ニュースから発見したので、ご紹介します。
勤務時間の短縮に加え、管理職は従業員に対し、会議や電子メール対応に費やす時間を減らすよう促した。 会議の時間は３０分を超えないよう求め、メッセージングアプリを使うことで会議そのものを開かないことも奨励した。
ポイントは「会議は３０分を超えないようにする、メッセージングアプリを活用する」だと思ってます。 素敵だなと思ったのは、単に「会議やメールを減らそうよ」というのではなく、具体的な方法まで全社的に考えている部分です。
昨今の働き方改革、職場でも「無駄な会議多いよな～なくしたいな～」と思えるような人が増えてきました。 ですが、まだまだ、無駄をどうにかする行動までは移せていない人も多いため、まずは、自分から何か行動しようと感じました。
自分ならどうする
今後、以下の手順でコミュニケーションを検討します。
（今まで会議、メールが主体だった社内コミュニケーションが対象）
- チャットで話せるか検討する。
- チャットが非効率だと判断したら、会議を検討
- 会議前に分かるものはチャットや口頭で解決
- それでも会議が必要なら、基本30分を前提にアジェンダ作る
- 30分で終わらすためのシナリオを考えておく。
- スリム化された会議の遂行
- 振り返り
「とりあえず、会議は1時間位予約しとくか～」という甘い考えを捨てます！
可能な限り、会議をスリム化していきたい！
最初のうちは、会議室だけ1時間で予約しておいて、計画通り、会議を進めながら、 時間が余ったら早く切り上げればよいのです。
はじめは、時間がかかるかもしれませんが、訓練だと思って実施してみます。 世の中には、エレベータトークや1分で話せみたいな話題があったりするので、きっとできるはず。
おわりに
会議の目的をいかに素早く達成するかという思考を重ねれば、 結果的にハイスピードに仕事が進められる人材になれるのでは。
週休3日制が無理なら、まずは、そこらへんから始めてみようよ！という話。
