システム開発で重要なこと
みなさまこんにちは。note３回目の投稿になります。
先日、上司と話しをしていて、自所属で色々な開発案件が炎上したり、課題が出たりする原因はなんだろう？という会話をしていて、開発案件に取り組む際、「実着手前の準備」の不足が、色々な課題の発端になるのではないかという話になりました。
そこで、割と在籍の長い私が、IT部門の同僚と、IT部門に依頼をする事業部門向けに日頃心掛けていることを話すという流れになりました。
この記事は当日話した内容を少し整理してみたものになります。
以前の記事でも書いてますが、私は非IT企業である不動産会社に新卒で入社し、営業職として現場を8年、その後部門スタッフを経て、現在はいわゆるIT部門で社内アプリケーション等の運用などを行っています。
今回、もともと社内向けの内容のため不動産関連のたとえ話が多くなることご容赦ください
0.言葉の定義
この記事では、登場人物を下記の様に定義してお話しします。
0.1.利用者
実際に対象物を利用する人、または組織
0.2.依頼者
利用者の業務内容、課題を把握しIT部門とやり取りをする人、または組織
0.3.IT部門
依頼者とベンダーの間に入る仲介人（トランスレーター）、または組織
0.4.発注者
自身の要求を整理し、ベンダへ開発の発注を行う人、または組織
0.5.ベンダ
発注者からの依頼にもとづき、開発等を実際に行う人、または組織
1.スタッフ部門の役割ってなんだ
1.1.スタッフ部門の役割
スタッフ部門の役割とは様々な「事業課題」について、その担当分野について先頭に立ってかじ取りを行い、その課題を解決することで事業活動を発展・促進することが目的です。
「意思決定」についてはより高次層の範疇となるので、スタッフ部門の具体的な役割は「意思決定を行う層が、正しい判断を行うための材料の提供、提案を行う」ことです。
1.2.コーポレートIT部門の役割
IT部門の役割とは様々な「事業課題」について、IT技術等を利用してその課題を解決、または他部門の抱える事業課題解決の手助けをすることで事業活動を発展・促進することが目的です。
また、社内という閉じられた環境だけに目を向けるのではなく、様々な技術革新等に積極的に目を向け、自社の「事業課題」解決、事業活動促進に役立つ情報収集等を積極的に行うことが必要
IT部門はもちろんスタッフ部門のひとつであるからには、「意思決定」についてはより高次層の範疇となり「IT系事業課題に対し、意思決定を行う層が、正しい判断を行うための材料の提供、提案を行う」ことが役割となります。
1.3.IT部門は「社内のITベンダー」ではなくトランスレーター
世間では「仕事を出してやってる」など、ベンダーを自身よりも下に見る傾向・風潮がありますが、システムベンダーに対してこれでは上手く行きません。むしろ、発注者とベンダーの関係性は、不動産取引でいうところの買主と売主の様な対等関係とみることが妥当だと思います
IT部門は、買主（発注者）と売主（ベンダ）の仲介を行うトランスレーターとしての役割が求められます。つまり、取引を円滑に進めるために、双方の希望や考え、背景について理解を深め、その相手方に正しく伝えられることが必要な資質として求められます。
不動産取引における仲介人と、システム開発におけるトランスレーターで違うのは、双方顧客が対等であるのと同じく、双方の顧客と仲介人も上下関係はなく、また対等であるということにあると思います。
2.依頼者は「自分がやりたいこと」を伝えることが下手
2.1.「手段」と「目的」は違う
先ほど、IT部門の役割はトランスレーターであるという話と、この任務遂行には双方の理解を深めることが重要であるとしましたがこれはどういこうとでしょうか。
不動産仲介の接客の場面でよくある例ですが、例えばお客様が「駅から近い物件がいい」と希望を言ったとして、これを受けた営業担当者はどうするでしょうか。
おそらく、熱心に駅徒歩〇分以内の物件情報を必死に探すと思います。ただ、探した範囲では適当な物件が見つからず、時間をおいても中々駅近の新規情報は出ず、お客様とも暫く連絡が取りずらくなってしまうというのはよくあるケースです。
しばらくして、対象の顧客に連絡をしてみると、なんと既に他社で購入を決めたとおっしゃいました。購入を決めた物件をヒアリングすると駅１５分の物件だったのです。
よくよく話しを聞くとお客様が「駅から近い物件がいい」といった理由は、「暗い夜道をずっと歩くのが怖い」というもので、購入を決めた物件は、「距離こそあるものの駅から続く商店街沿いにあり、暗い夜道の怖さがない」ことから気に入ったのだということでした。
つまり、お客様にとって「駅から近い」という条件は、「夜道の不安という目的」を払拭するための「一つの手段」でしかなかったのです。
システム開発の場面でも同様のことが度々起きます。
依頼者が、利用者から「○○システムの、A機能が使いずらいので、使いやすくしてほしい」という要望を預かり、依頼者はIT部門に「A機能が使いずらいという希望があるので、B機能を新たに作って欲しい」とIT部門に伝えます。
IT部門は依頼者からの要望を同じくベンダーにそのまま伝え機能開発、リリースまでこぎつけ利用者にヒアリングを行うと「こんなものは望んでいない」などと言われる様なケースは皆さんご経験があるのではないでしょうか。
この場合の問題点は、
①依頼者が利用者の課題・要望、およびその背景を正しく理解していない。
②IT部門が依頼者からの要望を深堀せず、利用者の真の課題が別の所にあるのでは無いかという確認を行っていないこと。
例えば、利用者に深堀をしていれば「使いずらい」原因は、「入力項目が多すぎて、どこに何を入れればいいか分かりずらい」とヒアリング出来ていたら、解決の手段は「未利用項目の削減、画面レイアウト変更」等となっていたかもしれないという具合です。
2.2.関係者間での意識を合わせることが重要
不動産取引に戻ったとして、では、お客様が初めから営業担当に上手く条件を伝えられていればどうかと考えると、営業担当からすれば有難いことこの上ないですが、こんなお客様はまずいないです。
それが分かっているから営業担当者は、あの手この手で真のニーズを引き出そうとするはずです。
システム開発も同じで、利用者がはじめからシステムベンダーにわかる様に要望を伝えられるということは殆どないと思います。
そのため、利用者、依頼者、IT部門は、共同で課題の深堀を行い「目的」を明確化、さらに目的を達成するための「手段」を関係者で揃える必要があります。
ただ、実務上、利用者がその打合せに出られないこともままあるため、依頼者とIT部門には次の様なスキル・資質が求められると思います。
依頼者：利用者の立場、業務背景を深く精通し、IT部門に正しく（社内用語可）で伝えることができる。
IT部門：利用者・依頼者の立場、業務を深く理解しシステムベンダーに正しく（専門用語：可、社内用語：不可）伝えることができる。また、システムベンダーからの確認事項を、利用者・依頼者の立場に即して翻訳し、正確に伝えることができる。
3.要件定義前の立ち上げ＆与件整理
3.1.一般的なシステム開発の流れ
各種システム開発の進め方のひとつに「ウォーターフォール開発」という手法がありますが、ウォーターフォール開発は、その名の通り、原則として前のフェーズに戻ることはありません。
要件定義：
開発するシステムの全体機能を定義する
設計：
要件定義で定められた内容をシステム目線でどう実現するかを具体化する
開発：
設計工程で定められた内容に従い、実際に構築を進めていく
テスト：
構築された内容が、前工程で定めた通りとなっているかを確認する
3.2.立ち上げ＆与件整理で必要なこと
3.2.1.与件整理とは
システム開発の目的は、先述の通り「課題をIT技術を用いて解決する」ことです。
ウォーターフォール開発における要件定義は、顧客側での「課題の明確化、全体での合意形成」が完了した段階ではじめて着手することが望ましく、この顧客内合意内容をトランスレーターが翻訳し相手側ベンダーとも意識を合わせることが要件定義の基本となります。
つまり「与件整理」とは「依頼者側の課題の明確化、全体での合意形成を事前に行うこと」だと思います。
3.2.2.先に待ち受けるイベントを事前共有する
システム開発の場面でよく起きるのが、「えっ、それってうちでやるんですか？」という不明確な役割分担で起こるタスクの押しつけあいです。
再び不動産仲介の接客場面を例に出すと「家を買いたい」という課題は誰が抱えているのかという話で、これはもちろんお客様ですから、お客様が良い物件を購入するために自ら活動することに特に違和感はないと思います。
ただ、お客様は不動産仲介に精通しているわけではないので、トランスレーターが初期接触の時に、今後の流れ（例えば、案内→買付→折衝→契約→金消→引渡しなど）を説明したり、発生する諸費用の概算を伝えたりといった「プロのサポート」が必要となります。
システム開発の場面では、知らなければ気づけないようなイベントの代表例としては、例えばこんなものがあります。
ベンダーとの定期打合せへの出席
自部門、他部門に渡る利害関係人への説明
構築後の受入テスト実施
ユーザー教育
予算措置
マニュアル作成
リリースに関する通知
これらは全て、基本的には依頼者が遂行しなければならない（≒依頼者にしか遂行できない）イベントですが、通常この様なイベントがあると熟知している依頼者は殆どいないので、与件整理・立ち上げ時点での事前説明が無いと「そんなの聞いてない」と炎上するのは当然とかと思います。
3.2.3.システム開発の主体
繰り返しになりますが、システム開発の目的は「課題をIT技術を用いて解決する」ことですから、リリース後の評価は「課題が解決出来たかどうか」ということになります。
では、その評価が出来るのは誰かということになりますが、答えは当然その課題を抱えている者、つまり利用者および依頼者ということになります。
4.システム開発とは（まとめ）
というわけで、大分長くなってしまいましたが、私がシステム開発で特に気を付けていることは以下の通りです。
システム開発の主体は、解決したい課題を持つ者（利用者、依頼者）。
IT部門は課題を持つ者へ適切な助言などを行い、課題解決の支援を行うことが役割。
以上です。
最後までご覧いただき有難うございました。