「業務システム開発モダイナゼーションガイド」を読み解く ー要件定義①ー

「業務システム開発モダイナゼーションガイド」

https://www.amazon.co.jp/dp/B07B8FGCGM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

(ええ感じに埋め込みする方法わからん!)

 

副題「非効率な日本のSIを変革する実践的ベストプラクティス」とある。

なるほど、実効性のないWBSの策定、Excel帳票地獄、実装能力0の割に、机上論とそ

の場凌ぎ、”謝罪”によってこれまでプロジェクトを回してきた自社にとって、なかなか

お誂えの一冊の模様。

 

SIに蔓延る問題点を前提にしながらも、開発プロセスの各タスクの要点をおさえている

ようなので、参考になりそう。ということで、読んだ内容を書き留めておくとする。

 

●要件定義とは

・システム化によって解決したい問題や達成したい目的を明確化する

・達成するために必要な機能要件と非機能要件を明確化する

ほうほう。

 

●アウトプットその1「機能要件定義書 」

・システム上でどのような機能を実現するのかを整理したものである

・「何を作らないのかを決める」ことでもある

 ほうほう。でもそんなんいきなりできひんやん普通。と、読み進めると、

機能要件を整理するためには、業務フローや業務ルールについて検討し、作るもの・作らないものを選り分けていくことも必要となる

精度の高い機能要件を行うためにはある程度外部設計の作業を先取りすることが必要になる

そうすると、要件定義⇨外部設計というプロセスを考えるよりも、外部設計で画面等を

検討していく段階で、要件を詰めていく段取りが要件定義の質の向上には適しているの

ではないか。まあこの辺りはやる・やらないとかそういうバランスもあるし、ある程度

外部設計自体が要件定義ありきな側面もあると思う。設計しながら詰めるっていう路線

もなくはないということは、堅い頭を若干柔らかくした感じ。

 

●アウトプットその2「非機能要件定義書 」

・システムがどの程度の「品質」を持つのに作り上げるのかを定義した

 ものである

・通常”〇〇abilitiy”とかいう特性で表現される

あ〜アクセサビリティとかあるね。ぶっちゃけシステムの規模(利用者とかデータ量)

次第だけどあまり検討されているイメージがない。裏を返せば、説得力のある定義が

しづらい事項と思っている。

「最低限必要なラインはどこなのか?」を考えて非機能要件定義を行う 

最低限を定義する方法がねえ、、

 

●アウトプットその3「システム構成図 」

・システムの特徴・特性、システム種別・利用者、ネットワーク構成、

 他システム連携が一目で把握できる

・1枚で全てが表現・図示されていること

 いわゆるポンチ絵ね。で、なぜ作るかというと

・メンバー全員で開発するシステムのイメージを共有する

・課題や問題点、リスクの早期把握

なるほど。まあ必要ですよね。 

 

 ということで、次回は要件定義についての続き・まとめを書きます。

 

 

1月

更新していないというのも流石にアレなんで、適当に綴る。

 

勉強

ruby on railsチュートリアルを7章までやった。全然わからん。

 

転職

・やりたいことがない

・現職で成果を上げていない

→以上2点が壁

 

読書

・小説は現実逃避に使える。人間味あふれる系の文学もの>SFや推理小説

 →脳が求めたら読む。

・知識系はビジネス本と技術本に限定する。教養ものは優先低

 課題図書を決めて読む。

 

習慣

・勉強→とりあえず上述のrailsチュートリアル日課にする。(1日半章)

・筋トレ

・読書→1冊/週ペースで頑張りたいところ

はてな→週一ペースで頑張りたいところ

 (書くことがない。仕事&内省と読書で得たつかえそうな知識でも書くかな)

 ⇨このタイミングで書くこと決めたらいい気がしてきた。

 

次回は「自己流読書術を極めるための何か」を書く。

 

 

方針とか

#目的

①やりたいこと・向いていることの自覚

②取得すべき技術の把握と選択と取得・習慣化

③良い方法・考え方の発見と定着

 

#達成点(細かいことは)

①ポジティブな転職活動(他者を関与するアクションの実行)

②スキルマップ的なものを作成する

③実用書を月3冊ペースで読んで何かを得る

Ruby on Railsで何かを作りきる

はてな(週一以上)とツイッター(都度)にてアウトプットする

⑥勉強会へ参加する

⑦何かにつけて方法論を確立する(①〜⑥のための)

 

#スペック

1992年生まれ/男/SIer(ですらないIT関連企業)所属/SE(?)4年目

 

#実務

・工期2年/工数約60人月の業務システムスクラッチ開発プロジェクト(メンバー)

・計300台くらいの業務システム用端末のキッティング(リーダー)

・パッケージシステムの導入サポート3案件くらい(リーダー・メンバー)

・工期0.5年/工数5人月の業務システム開発プロジェクト(一人エンジニア)

・他、保守

 

#実務で得たこと

・机上論的なWBS作成

・顧客を同情させる要件定義

・設計書を無理やりそれっぽく作成する力

・とりあえず仕様を満たすPG実装能力(Java,C#,javascript)

・ちゃんとしているようにみえるテスト仕様書の作成

・ゴリ押し

・雰囲気の保守サポート