新しいシステムを0から構築することもありますが、既存システムの改修プロジェクトの方が多い印象です。実際にプロジェクトにアサインされると、プロジェクトやシステムの概要の説明を受けます。その後、既存システムの仕様書のフォルダのパスが連携され、資料を読むように指示されます。
でも、資料はたくさんあるし、どこから手をつけていいかわかりませんでした。さらに資料を読んでもよく理解できない経験もありました。少し経験を積んできた今日この頃、「この順番で見ると仕様把握しやすいかな」と思うところがあったので、メモとして残してきます。
0.仕様把握の大まかな手順
まず、指示を振り返りましょう。「資料をみておいてね」という指示は「資料をただ読んでね」のではなく、「このシステムの仕様を把握してね」という意味です。今後、タスクを振られることを前提にシステムの全体像や各機能を把握して、タスクを着手できる状態にしておくのがミッションです。
だいたい資料はたくさんあるので、効率的把握するには 「工夫」 が必要です。把握しやすくするために工夫したいのが 「順番」 です。まず、俯瞰できる資料から手を付けて、順に、詳細の資料を確認していきます。
システムは何らかの目的を叶えるための手段であり、前提や大きな流れを理解することでシステム理解がスムーズになります。また、最初に細かい機能を理解しようとすると、「なぜこの機能が必要なのか」がみえづらくなり、本質的な理解がおろそかになってしまいます。大枠から捉えると、把握すべき事柄の抜け漏れが防ぎやすくなります。
ここでいう大枠とは、システムだけに限りません。先述したように「システムは何らかの目的を叶えるための手段」なので、システムだけではなく、もう少し大きな枠組みから抑えられると「なぜこのシステムが必要か」ということもみえてきます。具体的には、「事業/サービス」→「業務」→「機能」という流れに沿って、大枠から把握できる資料から確認していきます。
＊
では、どのように把握するのがよいでしょうか。やり方は様々あると思いますが、個人的には 「資料化」 がよいかなと思います。資料を読んでいるだけだと、体系的に理解するのが難しいです。実際に自分でメモを取りながら（資料化しながら）資料を読み進めると、足りない情報に気がついたり、体系的に把握することができます。
資料化するポイントとしては、 粒度が異なる資料を簡単に複数作成すること です。1枚に大枠から詳細までまとめてしまうと、1枚の情報量が多くなり把握が難しくなります。見た目のきれいさはさほど気にせず、簡易的な資料を複数作成する方が様々な観点で情報を拾うことができ、重層的にシステムを理解することにつながります。
資料化のポイント2つ目は、 時間軸を入れること です。もう少しいうと、作業や処理の流れに沿って書くことです。前後のタスクを書き込んで整理することは、視野を広げて、文脈を意識して把握ができます。
そして、資料を作成したら、作成資料をもとにしてリーダーに理解した内容があっているか認識合わせをします。このことによって、理解のずれがあるかを確認し、ずれがある場合は軌道修正します。
一方でデメリットもあります。時間がかかることです。簡易的な資料としても全体像をつかもうと図解したりすると、時間がかかります。しかし、最初の仕様把握で間違えると、その後の実作業に影響がでるので、（欲を言えば）資料化など工夫して仕様把握をしたいです。私は、資料化するときにはExcel、PowerPoint、drawioを使うことが多いです。
＊
資料化の際に疑問点が出てきます。疑問があったときの動きも最初に整理しておくと、後々スムーズな仕様理解につながります。まず、整理することの1つ目は、 「誰に疑問をぶつけるか」 です。当然ですが、システムのことを知っている人に聞きます。PLなのか、保守チームなのか、そのほかの人なのか、確認しておきます。
2つ目は、 「どのタイミング、どんな方法で疑問をぶつけるか」 です。質疑応答のやり方です。個人的には、Excelなどで質問回答一覧を作成して、一か所に質問と回答をまとめておくとよいと思います。1つずつ質問するのは答えるのが大変なので、疑問がある程度たまったら、質問します。また、質問する相手は別業務をしていることがほとんどなので、相手の時間を奪わないように注意したいです。ただ、リーダー側の立場を経験した身からすると、初見のシステムの資料を読んで質問が出てこないと「本当に把握できているのだろうか？」と心配になってしまいます。
＊
具体的に資料を確認するポイントを以下の流れに沿って整理します。
1.プロジェクトを知る/自分の立場を知る
2.事業/サービスを知る
3.業務を知る
4.機能を知る
1.プロジェクトを知る/自分の立場を知る
システムを把握する前に、自分の立場やプロジェクト内容を確認します。まず、自分がどの立場でどんなことをするチームに配属されているのか、グランドスケジュール、プロジェクトとして成し遂げたいこと/制限事項を確認します。そして、プロジェクトの目的や自らの立場を確認し、チームや個人の期待値を把握します。また、会議体の開催概要、直近のスケジュール、ステークホルダーなども簡単に把握しておきたいです。プロジェクト運営ルールの確認です。
プロジェクトを知るには、 キックオフ資料 を確認します。キックオフ資料には、プロジェクトの目的、体制、スケジュール、納品物、チーム運営に関わることが記載されています。納期、コスト、品質、スコープについてチームの考え方がわかるとなおよいですね。変更管理に言及があればしっかり読んでおきます（後々この知識が必要になることも多々あるので）。量は多くはない場合がほとんどだと思われるので、資料化はせず、読むだけになるかと思います。
2.事業/サービスを知る
システムをどんな目的で使用するのか理解を深めるために、事業の概要やビジネスモデルを確認します。
・事業の目的
・誰をターゲットにしているのか
・どのように価値を創出しているのか
上記のような情報はキックオフ資料に記載されていることは稀です。ただ、ネットで一般に公開されている企業のコーポレートサイトでおおよそ把握できます。細かく正確に把握する必要はないので、おおまかなにざっくりと把握できればOKです。
「どのように価値を創出しているのか」の部分をシステムで実現させていることがあるので、ターゲット情報も踏まえて、注視しておきたいです。そして「納品」をシステムで行うこともあるので、事業を知ることがシステムの理解を助けることにもなります。
＊
「サービス」についてもざっくり把握しておきたいです。ここでいうサービスは「お金という対価を払うことによって、得られる恩恵」のことです。このサービスを提供するのに、システムが使われます。
サービスを知るには、営業担当者がクライアントにみせる営業資料として、サービス内容、期間、料金などをまとめたものがあると思うので、この営業資料を確認します。そうするとサービス内容がわかります。
見せてもらえなくても、Aプラン、Bプランなど契約プランやプランの内容・期間、制約あたりは把握しておきたいです。プランによって選択できる項目や数量が変わるなどシステムに影響することがあるからです。プランによって業務フローが変わる場合もありますね。
少し脱線しますが、「年度の周期」も把握しておきたいです。「年度の周期」とは、何月から何月までを1年とするかです。例えば学校では、4月スタート翌年3月終わりです。一方、企業によっては、9月スタート翌年8月終わりというパターンも存在します。システム上、このような周期の影響を受ける箇所が時々あるので、押さえておきたいです。
さらに、サービスに関する知識は、発注者と会話するときの共通語になり、サービスの深い理解がお客さんからの信頼につながることもあります。逆にいうと、サービス理解がおろそかだと、お客さんから不信感を持たれることもあります。わからないならわからないなりに、質問をどんどんしてサービス理解を深めていきたいですね。営業資料数が多い、複雑と見受けられたら、簡易版資料を自分で書き起こして、情報を整理することがあってもよいかもしれません。
3.業務を知る
次に、業務を知ることに努めます。この業務はシステム内外を問わず確認したいです。すなわち、サービスの企画から、納品・検収まで一連の流れを確認することがベストです。ただ、すべての業務フローを洗い出すのは大変なので、現実線としては、システムが介在するだろう業務とその前後の業務の確認をすることになるかと思います。
システムに関係する業務を把握するときのポイントは 「本筋業務の流れを大雑把につかむこと」 です。業務には様々な種類がありますが、細かい業務や発生頻度が低い業務は一旦おいておいて、大筋のみを大雑把に把握します。「誰」が「どの順番」で「どのシステム」で「何をするの」か、をみていきます。
「誰が」は、社内のユーザーであれば営業、経理、人事など部署や役職の情報も捉えます。社外のユーザーであれば、一般ユーザー、○○業者など取引のあるユーザーが登場しそうです。さらに、システム起点でタスクが処理される場合やデータの格納先として登場することもあるので、「システム」も「誰が（または、誰に）」という情報になりえます。
「どの順番で」は、作業の流れのことです。タスク完了がしたら、次の担当者やシステムにタスクをパスするので、時間軸に沿って前後関係を確認します。
「どのシステム」は、一連の業務を行うのに複数のシステムを使用する場合があるので、どのシステムで行うのか確認します。この連携している外部システムを把握するのは地味に大切です。業務の確認など、大雑把に全体像を把握する段階で外部連携システムの存在に気づき、詳細な仕様書を読んだときに外部連携がある程度イメージできる状態にしたいです。
「何をするの」はタスクの内容と対応内容です。具体的には、「○○情報を登録」とか、「○○をダウンロード」とかです。
＊
業務を把握するには、 業務フロー を確認します。業務フローとは「ある業務やプロセスがどのように進行するかを図や文章で表したもの」です。業務の全体像がわかり、上記で記述した「誰」が「どの順番」で「どのシステム」で「何をするのか」が整理されています。（縦レーンで記載する場合は）作業の順に沿って上から下、左から右にタスクが流れるように記載されることが多いです。
＊
「本筋業務の流れを大雑把につかむこと」が業務を把握するときに大切なのは上述した通りです。全体像をまずは掴むことを意識します。全体像を把握する際に、どんなアクターが登場するのか確認しますが、アクターの背景や仕事内容は資料にまとめておくと、業務の理解が進みやすくなります。
例えば、人事1課と人事2課が登場するのであれば、↓のように簡単に業務内容を整理しておくと業務フローが読みやすくなります。
・人事1課：新卒採用を担当。夏頃のインターンシップの企画運営も行う。就活イベントの参加などから学生とのやり取りまで、新卒採用に関わる業務全般を担当
・人事2課：中途採用を担当。各部署から要望取りまとめから、求職者とのやり取りまで、中途採用に関わる業務全般を担当。
＊
そして、システムは業務を効率的に円滑に進める手段となるものなので、実際にシステムを使っているところを想像して把握したいです。ただ、「どの画面でどんな項目を入力するのか」のような詳細は今の段階では細かすぎます。それは機能仕様など詳細な仕様書を確認する段階で十分です。業務フローの段階では全体像や各タスクの概要レベルで十分です。
業務を想像するときに着目してるポイントは、 「作業（または処理）ができる状態になっているのか」「タスクの作業開始のトリガーは何か」 です。業務フローではタスクを矢印によって繋げていて、そのつなぎ目を注目します。
例えば、人事担当者が求職者の情報をシステムに入力するタスクがあったとします。「作業（または処理）ができる状態になっているのか」という観点で作業を深堀りすると、「人事担当者はその入力情報を知りえているのか？」を想像します。そして、そのタスクの前で「就職サイト側から求職者のデータを連携されているかも」と予測をたてます。実際に業務フローに記載があれば、フローに整合性が取れていて深掘りできたことになります。反対に、業務フローに記載がなければ、（データ連携という）隠れたタスクがあり、それ（入力情報）はどこからやっているのか？と解消すべき問いをたてられたことになります。
また、「タスクの作業開始のトリガーは何か」という観点で作業を深掘りすると、「データ連携した際に通知メールが人事担当者に飛ぶ」と記載があれば、担当者がタスクに気づいて作業着手することを想像でき、業務フローの矢印がちゃんとつながります。反対に、通知メールなどトリガーの記載がないのであれば、「タスクが発生する契機は何か」と問いをたてられことになります。
4.機能を知る
事業、業務を概要を掴んだ次は、機能を確認していきます。ログイン機能から、検索、登録、変更、削除などなどシステムで何をどうすることができるのか、確認していきます。
もちろん、バッチ、APIや帳票、メール送信などもすべてです。ただ、すべての機能の詳細を把握するのは時間がかかってしまうので、完璧は目指しません。まず、機能一覧、画面一覧、画面遷移図、ER図、DB定義書、データフロー図、バッチ一覧、帳票一覧、ファイル一覧などを俯瞰できる資料見て、詳細が記載されている画面仕様書を見ていきます。ここでも、大枠から、細かく見ていきます。
機能を把握するときのポイントは、 「実際に画面を動かしながら資料と合わせて確認する」 です。もし、検証環境など触ってもよい環境があれば、なるべく自分で手を動かして、理解を深めていきたいです。仕様書と実際の動きを確認して、動く/動かすイメージをつけていきます。まずは、メインとなる機能から洗って、少しずつサブ機能を見ていきます。
できれば、業務が流れる順番で画面を動かしていきたいです。細かく見ようとすると時間がかかるので、あくまでもざっくりとみるようにします。ただ、手を付けてはいけないデータや機能はあるかもしれないので注意事項は守りましょう。
終わりに
簡単なプロジェクト説明の後、「資料をみておいてね」と言われて作戦を立てずに資料を見ていたことがありました。フォルダの上から出てきた資料をなんとなくみる…というような場当たり的な流れ見てました。結果、理解度の低い状態でタスクが降られて、いいスタートが切れませんでした。
振り返ると、資料を確認するポイントは誰かがレクチャーしているところも、レクチャーされているところも見たことがありません。基本的に個人の裁量に任されています。自分はうまく資料の確認ができないタイプでした。そして、何度か資料確認を経験してコツを掴めそうになったので、ブログに書き出してみました。
本稿で書いたようなことは、資料確認ポイントまとめ資料を起こしたり、レクチャーするまでもないことかもしれません。ただ、知識としてあった方が仕事がスムーズになるかと思います。自分でも手が届きそうだけど、なかなか届かないことをブログにするのは集合知の醍醐味と思います。本稿が誰かの役に立てたらうれしいです。
最後まで読んでいただいた方、ありがとうございました。