久しぶりの投稿で初めてではあるが小生の生業である情報処理部門について語ってみようと思う
四方山話のはじまりはじまり
昨今EngineerやProgramerが人手不足で技術養成指導をする企業も増えてきた
更にこの業界は一企業にいるよりも個人で活動した方が技術やSkil向上の上で都合が良かったりする
なのでこれまで多くの業種を経験し多くの技術を培ってこれた
８歳の頃からComputerはいじっており人間の年齢で換算すれば50年近くになるだろうか
とは言え太陽周期で年齢を重ねるというのはあくまで宗教の儀式なので個人差はあるだろうが小生は未だ30歳である
話がそれたがEngineerの登竜門はProgramingから始まる
私の場合はBasicから始まった
最初は他人が書いたCodeをものまねで書き込みこれを実行するのだがそうそう簡単に動いてくれるものではない
当時今ほど専門誌もなかったし父の職場のPCだったので利用する機会も少なかったが一つ目のProgramが正常に動作する事は出来た
当時はたった白と濃い緑の２色しか表示出来なかったPCではあったが
それでも動いてくれると嬉しいものだし今日の様にPCが進化するなど露ほどにも思わなかったので無理もない
なので個人のPrograming歴は先にも書いた通り人間の一生を100年とすればその半分はこれを占めている事になろうか
だがProgramingはあくまでEngineerとしての登竜門に過ぎないしCodingが速いからと言って優秀なEngineerとは言えない
開発工程において下流から順に遡っていくとProgramerのCoding作業の前にはEngineerによる設計工程がある
更に設計工程の前には要件定義という開発の屋台骨となる重要な工程がある
この工程を手を抜くと必ず移行の設計や実装そして試験段階で手詰まりとなり所謂炎上という事になる
なので要件定義はとても重要な工程なのだ
にも関わらずこの工程を工数が足りないと度外視する開発がとても多い
画面仕様とDatabaseのTable定義だけ決めて後は設計でおまかせというところも少なくない
あれ？どうして要件定義って工数が少ないんだ？
ふとある事に気づいた事がある
どうして要件定義に工数をかけない理由についてである
その前に要件定義の手順を簡潔に説明する
例として最近良くあるOpre-miseからAWSやGCPやAzureなどのCloudに現行Serviceを移行するというものとしよう
そしてほぼ対となるFlameworkの変更についてである
Server構築やNetworkなどの移行は個々のCloudの提供するServiceに従っていれば程なく移行出来るほど最近は便利になっている
なのでこの点は割愛する
重要なのは現行の機能要件を如何に移行するかにある
ここを間違えれば折角Cloudで準備した新環境でServiceが動かない事になるのだ
そしてこの移行を誤りProject自体が炎上しているのが本当におかしいほど多いのが現実だったりする
この様な要件定義においてはまず現行の機能要件を調べる必要がある
調査する対象は以下のものになるだろうか
・業務仕様
・画面仕様
・Database仕様
・その他上記以外のSystem仕様
要件定義に重要な情報とは？
さてここで意地悪をしてみた
人間の思考から上から順に記述されたものが重要だと思うものだ
なのでこの場合業務仕様がとても重要だとは気付くだろうし
利用者に対する画面やその際に必要な情報も重視するだろう
そしてその他のSystem仕様にはさほど興味を示さないものだ
ところが実際の重要度はそうではないのだ
・業務仕様
・その他画面とDatabase仕様以外のSystem仕様
・画面仕様とDatabase仕様
となる
ところでこの業務仕様がない既存Serviceも多いのが困りものである
業務仕様の核となるのが業務FlowであるがそのFlowを作らずにServiceを提供しているとんでも無い企業も多い
幸い障害があまり発生しないためなのだろうが
いざ障害が発生してしまえば障害要因を探すための手立てが業務Flowがないので追えなくなる
これも担当者の勘所を頼りにしているのだろうが障害当日に担当者が欠勤していたりしたら対応が遅くなるだろう
更に障害対応を一個人の勘所に頼るのは企業の資質を疑う事にもなりかねない
なので要件定義の段階で業務Flowすら提示できない企業は論外である
要件定義の一般的な手順
要件定義ではまず現行の内容を調査するところから始まる
所謂現行要件分析である
最近はこれをASISといって我々専門職は要件定義を行う
要件分析にに必要なのは上記に挙げた３種である
業務仕様や業務FlowそしてSystem仕様内のSystem Flowを元に利用者のActionに対して個々のCRUD単位に機能処理を掘り起こしていくのだ
例えば利用者に中古車の販売を提供するServiceがあるとする
業務FlowとSystem FlowがあればこのServiceの一連の流れが理解できる
まず業務Flowから利用者が欲しい中古車を選択し注文や問い合わせが可能な情報を提供する対面業務がある
そして注文や問い合わせを受け付けて内部で処理するための内部業務がある
業務Flowでは大抵その際に使用する情報が記載されている
この場合は注文情報や問い合わせ情報になる
System Flowはこの業務を補助するために自動化されたものを図式かするものだ
この場合対面業務にあたるものがFrontendとなり内部業務にあたるものがBackendと呼ばれる
System FlowにはFrontend側の注文や問い合わせ情報がDatabaseの項目に従って記載されており
Backend側はDatabaseへこれらの情報を格納する処理Flowが記載されている
要件分析ではこの一連の流れを機能として捉えているのだ
なので画面仕様だけで機能分析をしたと思っていたら大間違いなのである
更に業務FlowとSystem Flowには注文や問い合わせ時に障害が発生し利用者の満足を得られなかた事を回避するための異常系と呼ばれる対応処置についても記載がされている
これにより障害が発生しても迅速に対応が可能になるのだ
だからこそ業務FlowもSystem Flowも存在せずServiceを提供している企業は論外だと言っている
この様に利用者のActionに対して機能が一つ一つ検証される
この時点で要件分析者は現行要件つまりASISをほぼ理解できている
この要件分析で機能は以下の区分に分類される
・新規にDatabaseに情報を登録する機能：Create
・Databaseの情報を参照する機能：Reference
・Databaseの情報を更新する機能：Update
・Databaseの情報を削除する機能：Delete
これをCRUDと呼ぶ
次にこの一個々の機能に対して詳細を調査する事になる
これを設計工程で行うProjectも多いがそれは間違っている
この機能詳細は処理Flowや処理詳細説明書などで構成されている
ほとんどこれが更新されない運用が多いので分析には時間を要してしまって本当に工数がもったいない
一個々の機能の処理詳細の調査まで完了した時点で移行の要望を分析する段階となる
ひどい要件定義はこの要求を要件として扱い結果Projectが炎上している
要望内容を要件定義ではTOBEとしている
TOBEの内容は様々なのでここでは割愛する
要件定義では次に現行要件のASISと要望内容のTOBEを比較し差分をする分析作業を行い
分析結果から一個々の機能に対して以下の移行方針が決まる
・機能維持：移行に際して維持する機能
・機能追加：移行に際して追加する機能
・機能変更：移行に際して変更する機能
・機能削除；移行に際して削除する機能
これを機能要件区分と呼んでいる
これをわかりやすく差分表にまとめ違いを明確化して作られるのがASIS TOBE差分となる
差分により一個々の機能の詳細機能において差分が明確になる
ここまでが一連の要件機能分析の作業の内容となる
ここで漸く移行先の機能要件を定義する作業になるのだ
如何に画面仕様やDatabase仕様だけでは要件分析が難しいかお分かりいただけただろうか？
ASISとTOBEの差分により機能要件の詳細を理解出来る段階となったのでここから移行先の機能要件の定義に入る事になる
後は要件分析で使用した各々の文書を新規に刷新していけば良いのである
今回は機能移行を例に挙げているが新規開発でも機能改善でもこの一連の流れに大差はないのである
なので機能要件区分を汎用的にまとめると以下の様になるだろう
・機能維持：機能要件定義に際して維持する機能
・機能追加：機能要件定義に際して追加する機能
・機能変更：機能要件定義に際して変更する機能
・機能削除；機能要件定義に際して削除する機能
機能要件定義作業は大抵設計担当から要件分析担当に入ったばかりのEngineerが行う事が多い
こうやってEngineerはひとつひとつの工程を経験しPMとしての資質を培っていくのである
つまりPMとはこの工程を経験し理解したものにしか出来ない仕事なのである
後は作成したこれらの要件定義書を元に設計をしていけば良いのだ
設計やその後の実装や試験についての解説はここでは省略する
疑問の答え
さて最初の疑問に戻るとする
（どうして要件定義に工数をかけない理由についてである）
その答えは極めて単純で明快だ
つまり自分達の提供するServiceや利用者に全く興味がないのである
人間というものは本来怠け者である
怠惰であればあるほどその環境から抜け出る事を拒む生物である
これは厳しい自然環境から人間社会を培っていった歴史の中で困難に立ち向かう気力を怠惰という環境が与えたからであろう
一方興味のあるものには好奇心が生まれそれを追求する欲求が生じる
興味が原動力となり更に他人に対する愛情が改善という創意工夫を育むのだ
つまり興味がなければ現行業務Flowがあろうがなかろうが上からの指示に従ってその場凌ぎで事を済ますという怠け者なのである
そんな怠け者が表面ではUI/UXとか言っているのだからこれこそ滑稽である
UI/UXの基本は以下の６つになる
・使いやすいこと：Usable
・役に立つこと：Desirable
・探しやすいこと：Findable
・Accessしやすいこと：Accessible
・信頼に値すること：Credible
・価値を生み出せること：Valuable
これをHoneyCombと呼ぶ
業務FlowもSystem Flowも知らないServiceはこの事を全く知らずにUI/UXと言って画面仕様だけを重視しているが
本当にお笑い種である
またVendorやSIer等の開発業者に自分達の業務FlowやSystem Flowを作らせるなど言語道断であり何様のつもりなのだろうか？
更に要件定義の工数を省いておいて設計や実装で遅延が出てくると業者に圧力をかけて無理やり工数いないに作業を簡潔させようとする厚かましさは看過できないものがある
正直こんな企業にはServiceの提供なんてして欲しくはないが改善するのなら助力は惜しみはしない
更に要件定義の工数を省くならASISの更新を常に行なっていれば良い
ASISの更新とは要件定義の成果物を次回の要件定義のASISとして使うという事だ
そうすれば要件分析の作業はTOBEとの差分検証から始められる
こうやって常にASISを管理する事でより迅速に開発作業を進められる様になるのだ
という事で疑問も晴れたところで今回のBlogはお開きとしましょう