はじめに
- これから上流工程の作業を行おうとしている人
- 興味があるので教えてほしい
と言う人に向けた物です。
いつも通り、業務も環境も十色なので、これが正解等言うわけではありませんが、ひとまず入り口と慣れるようにまとめた物です。
最終目標は
①企画 ：お客さんに提案し
②要求定義：企画した内容をお客さんと共に整理し
③要件定義：要求定義を案件化できる要件定義にまとめる
事が出来る様にすることです。
そもそも上流とは何なのか？
上流という言葉
上流という言葉には主に二つの意味が含まれています。
- 川の流れ等の源に近い方
- 階級としての地位が高い身分
ですが、もちろん開発プロジェクトでの上流とは前者であって、上流工程の作業が出来るから偉いって訳ではありません。
以下の上流の種類順からお客さん寄りの作業、つまり源に近い方になります。
そのため、上流工程と呼ばれます。
上流の種類
まず、上流工程の種類ですが、諸説ありますがここは俺の思う定義で進めます。
システム開発における上流工程とは大きくは
- 企画
- 要求定義
- 要件定義
- 基本設計
- 計画
のような物があります。
ざっくり説明すると
- 企画 こんな事しません？
- 要求定義 何が必要なのかまとめましょう？
- 要件定義 したいことを実現する目標をきめましょう。
- 基本設計 目標に向かって実現する手段をきめましょう。
- 計画 どうしたら、この開発が旨くいくか計画しましょう。
のような感じになります。
開発者の関わっている領域
この中で、主に開発のメンバーが関わることになるのは「4．基本設計」「5．計画」になります。
「そもそも上流とは何なのか？」を説明するために
ちょっとシステムがどうやって開発しようって話になって実際に開発に至るか？
を俯瞰して観ていきたいと思う。
その中で自分が今どの立ち位置で仕事に関わっているのかを観ていきたいと思う。
システム開発とはどんな範囲をカバーしているのか？
逆に皆の分かる世界から話していこうと思う。
ここでは開発の工程の
入社して最初は、先輩やリーダーから言われた仕事をこなすって所から開始すると思う。
それは、システム開発で言うと「プログラマー」が活躍する範囲だと思う。
その外の世界には「物理設計」をする領域の仕事があって、システムを実現するための設計が行われている。
この設計段階においてはユーザはほぼ関与していない。
その外の世界には「論理設計」をする領域の仕事があって、システムの振る舞いのための設計が行われている。
この段階では、ユーザとシステムを使った業務フローなどの詳細や、画面レイアウトなどユーザインターフェースに関わる設計を行う事となる。
その外の世界には「要件を定義づけ」する領域があって、システムに求める要件の整理をユーザと行うことになる。
要件定義を行うことで、システム化範囲はめいかくになり、見積もりや開発計画などが行えるようになる。
言えば、この辺りから上流工程と呼ばれるものになるのだろう。
そしてシステム開発と言ったときにカバーするのもこの範囲を指すことが多い。
その外の世界には「要求を整理する」領域があって、ユーザがシステムに求めるものの分析を行うこととなる。
基本的にこの領域になるとお客さん主導の世界。
その外の世界には「業務の問題を解決しようとする企画フェーズ」があって、営業なんかがキャッチアップしてフォローしていくことになります。
システム開発の領域ってのは、この狭い世界の範囲で行っています。
この外の世界が上流で扱う世界です。
ちょっと上流の先の話（超上流）
あくまで、システム開発における上流工程でしたが、さらに外の世界があります。
超上流という世界です。
まずは、システムはユーザの業務活動の一端を担っているに過ぎず、システムの外には「業務」の世界があります。
この業務を「IT戦略により、システム化するなどの構想を立案」する領域があります。
主にITコンサルなどが行う領域ですが、開発ベンダーなどに相談が来ることもあります。
さらに、外の世界には社全体の「業務分析・業務改革」を検討する領域があって、この段階でベンダーに声が掛かることはほぼ無いですが、過去に納入したシステムの評判によっては、社レベルで相談が来ることあります。
このさらに外の世界では「経営戦略・事業戦略の策定」を行い「システム化の投資計画」や「ITガバナンス・リスク管理の検討」等を行う「社の活動」の領域があります。
ここは流石に他社が入り込む領域ではありませんが、コンサルなどが助言していることを考えると、ITコンサルとして「ITガバナンス・リスク管理の検討」は携われる可能性もあります。
ここまで来ると一つのシステムか担う領域はその会社にとって、実はかなり限定的な領域で、その開発という領域はさらに狭く、その小さな領域で閉じこもっているのはもったいない。
上流に行くほど技術の色は薄くなっていくと思われがちだが、実は確固たる技術を持っていないと上流の会話は成立しないことが多く、より技術性を求められる場面が往々にしてよくあると伝えておきたい。
超上流の外の世界
じつはまだ外の世界があります。
それは、その会社の所属する業界の世界です。
その業界に精通したシステムを作り上げた経験は、同一業界の他会社にシステムを展開する際に強力な武器になります。
また、場合によっては紹介により他社に同じようなシステムを導入することになる場合もあります。
そして、業界通しも関連業界と繋がっている場合があります。
今までに経験したシステムが意外なところで繋がる場合もあるのです。
もうこの世界に来ると、最初に出発した開発をしていた場所は大分小さくなってしまいました。
でも、これは全て地続きの世界です。
プログラマーとして関わる世界はこんなにも広いという事です。
それぞれのステージの壁を壊して是非外の（上流の）世界へ行ってみましょう。
上流の世界に行くための心構え
「すぐに上流で活躍できるか？」と言われればそれは難しいと答えるでしょうが、次の事を心がけてシステム開発に取り組んでいれば自ずと一つずつ壁を越えて外の世界に行けると確信しています。
お客さんは誰ですか？
上流では当たり前ですが、お客さんと話すことになります。
臆することなくお客さんのところに足を運んでください。
時代的にオンラインと言う事も多いでしょうが、実際にそのシステムを利用するお客さんの顔を知っているのと、知っていないのとではシステムへの取り組みが段違いに違ってきます。
百聞は一見にしかずです。
いずれにせよ、お客さんと話すということになれておく必要があります。
みんな仲良く！
ともすると、壁を挟んでとなり通しが敵になりがちです。
それは、自分の世界に壁を作って壁の中のことだけをしようとするからです。
システム開発の本質は、そのシステムが何のために必要で何を求められているかを追求することです。
その時に隣と責任の所在をなすりつけ合っている場合ではありません。
そのいざこざは結局自分たちの負債となってのしかかってきます。
まずは、隣を理解することから始めましょう。
客が敵なんて思ってシステム作っていた人も知っていますが、結局旨くいくことも、開発を着地させることも出来ないでいました。
そのシステムは何のため？
ここが重要です。
ただただ、上から降ってくる設計書通りに作っていても、お客さんの顔は見えないし、お客さんが本当に必要としていることも設計書に書かれることは希です。
特にプログラミング段階では物理設計書が主になるので、機能ベースで作業が進みます。
そんな時、思考が停止していることが多い。
ちょっとお客さんの身になって使ってみれば、使いづらいなということも分かるし、設計が間違っていることだってある。
同じテストをしても、そういった不具合を見つけることができる人と、そうでない人の差はそのシステムが何のために必要とされている物なのか？
を理解している人か、そうでない人も違いであることが多いです。
もし、ちょっと時間があったら今まで自分が携わってきたシステムが何のためにあったのか考えてみてください。
その意識で行っていたシステム開発の案件は人に説明できるはずです。
さいごに
上流工程は実は楽しい作業です。
コーディングも楽しいが、要件定義が出来たときにお客さんから「そうだったのか！こうすれば良かったのか！」とか言われる事があり上流冥利につきます。
また、上流から作業が行える開発会社は良質な案件を開発前に選別が出来ます。
要件定義に非協力的な会社はその後の工程においても変わることはほぼ無いため、要件定義時点で見極めも出来ます。
今後人手不足が囁かれているこの業界でこういった顧客は良質な開発会社から相手にされなくなっていく事も考えられます。
コメント