「ADPISA-H」IS実践研究の中間発表を終えて

こんにちは、かみちゃんです。
青山学院大学が主宰する、情報システム（IS）アーキテクトを目指す人のための社会人向け履修証明プログラム「ADPISAｰH」（アドピサ エイチと読む）についての体験記3回目です。
前回はこちら

6月下旬からスタートしたプログラムも、いよいよ残すところあと1ヶ月と少し、ということで終わりが見えてきました。
しかーし、ADPISA-Hを修了するには、IS（情報システム）実践研究をクリアしなければなりません（汗）。
その中間発表会が昨日ありましたので、今回はその内容と感想を書きたいと思います。

ADPISAｰHのゴール「IS（情報システム）実践研究」

約5カ月弱のADPISAｰHの山場？集大成？が、「IS実践研究」です。
どんなものなのか私なりの言葉で表現すると「（広義の）情報システムを捉え、企業のビジネス或いは仕事のやり方をチェンジする提案とその実践」です。それを、ここまで学んできた知識や体験を総動員して立案しなくてはなりません。
ビジネスアナリシスを真ん中に置き芯となる要求や課題を引き出しながら、ビジネスモデリングでAs-IsとTo-beを明らかにし、データサイエンスを使って課題の発見に使うもよしソリューションとして使うもよしで、それを複数のプロジェクトとそれを構成するプログラムとして推進していく、というイメージです。

中間発表会とその学び

そして、昨日がそのIS実践研究の中間発表でした。
中間発表は、実践の前の提案までとなります。時間は1人15分程度で発表する分量との指定がありました。
提出期限を超えてなお、修正や追加をするメンバーも多く、平日仕事と並行してやることの大変さはもちろんですが、みんなの真剣度合いが伝わってきました。
かくいう私も、3連休の間も頭の中はIS実践研究のことで頭がいっぱい。
本当は3連休で仕上げたかったですが、全く筆が進まない状況が続いて（にも関わらずNetflixで「極悪女王」を観てたのは内緒）、「終わらないかも・・・」と一瞬頭をよぎりました。が、何とか提出期限前の26日（木）朝には出すことが出来ました。
さて、私のテーマはこちら。

内容はここではあまり触れませんが、現在とある育成プログラムを社内で推進しており、それをいかにビジネスの現場の実践や価値に接続するか、そのためのチェンジを題材にしました。
講評は15分のプレゼン後に、宮川教授、戸川教授、居駒教授の3名から頂き、当日参加のクラスメート18人はSlackで感想やアドバイスなどをそれぞれの発表に書き込むという形式でした。
先生方々からの講評はもちろん的確なご指摘の数々なのですが、同級生たちからもらえる様々な視点での感想や情報、アドバイスたち。これもとってもありがたい。「うちでは育成はこんなことやってます」とか「提案にあるやり方を実践したことあるけど、この点はうまくいったけどこの点はうまくいかなかった」などなど。これが様々な業種から一定以上の経験を有する社会人が集まり学ぶ「ADPISA-H」ならではの大きな価値かもしれません。

他のメンバーの発表はどんなものだったかというと、ERP導入やAI導入といった企業のIT部門ならではのお題や、営業改革、オフィス改革など、バラエティーに富んでいて、プレゼンを聞くだけでもたくさんの学びがありました。

チェンジの提案に大事な「課題」の特定

まだ総括するのは早いと思いますが、今回の中間発表に向けて自分のテーマをまとめる中で気付いた事があったので最後に書き記しておこうと思います。
書き始めた最初の3日くらいうーんうーんと唸り全然進みませんでした。正確に言うと書いては消して、作ってはスライドを削除してと、一進一退でした。
が、ある時から一気に劇的なスピードアップで進み始めます。 それは取り組むべき「課題」を特定出来てからだったと感じています。
「課題」の捉え方が広すぎれば何でもかんでもやらないといけなくなりますし、逆に狭すぎるとその課題を解決したとしても求められるNeeds（要求）に応えられません。
また、課題の次元（レベル？）みたいなものがあると思っていて、高すぎては（例：会社の売上が伸びない）抽象的になりチェンジの対象が広範かつ曖昧になりそうだし、低すぎる（例：営業トークがうまく出来ない）と具体的かも知れないが、インパクトが出ないものになりそうです。
今回、ちょうど良くて且つ意味がある「課題」にたどり着けたことで、提案にたどり着きました。
では、どうやってその「課題」にたどり着けたのか？
2つありそうだなと感じています。

1.課題を構造化して捉える

課題って、多重階層構造になっていることが多いのです。
例えば、以下のようなケースです。
売上上がらない　→　受注件数が少ない　→　提案件数が少ない　→　訪問件数が少ない　・・・　
「売上が上がらない」課題の下位には「受注件数が少ない」という課題があり、またその下位には・・・　といように階層構造になってます。
しかも、ここでは分岐はしていないですが、売上が上がらない原因には「単価が低い」といった要因もあれば、「商品が悪い」要因も考えられます。
なので、本当に解くべき課題は何なのか？構造化して捉えないと適切でない課題を「課題」としてとらえてしまう可能性があります。
これを構造化するには、ロジックツリーなどを使うと良さそうです。
※今回使いました。

2.コンテキスト（制約条件）を捉える

ビジネスアナリシスの講義でやったBABOKとBACCM（Business Analysis Core Concept Model）で、私はこの考え方を学びました。
その組織やビジネスの周辺に存在する文脈を捉えることがチェンジには重要だとBABOKならびにBACCMでは定義されています。
組織体制、トップの性格、市場環境などなど、それによって課題の認識は変わりますし課題の打ち手で取れないオプションが存在するはずです（だから制約条件と言っているようです。）。
このコンテキストの整理を課題の特定をする際に並行して考えておくと、解くべきちょうど良い「課題」なのかどうか取捨選択できるような感覚を持つことができました。

この2つに気付いたのが、私にとっては収穫でした。
参考になれば幸いです。

最終発表に向けて

と少しなんだか偉そうに書いてしまった気がしますが、先生たちからは「このKGIの設定で提案が通りますか？」「行動変容を起こすには何をするのかが不足しているのでは？」といった的確かつ鋭いご指摘を自身の提案には頂きました。
まだまだ、教わったことが咀嚼できていない実践に結び付けられてないことは多々ありそうです。
11月上旬の最終発表に向けて、少しでもレベルアップできたらと思っています。

ということで、今回はこの辺で。

#ADPISA #青山学院大学 #BABOK #ビジネスアーキテクト #ISアーキテクト