上流工程、データマネージメント、情報システムもろもろのつぶやき

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

ある工程のアウトプットが次工程のインプットとして使えなければ無意味。 コンサルさんの成果物は見栄えはいいけど、残念ながら使えない場合が多い。頭良すぎるのかも・・・

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

こういう言葉も見つけた「企業内のシステム部門はそれのみにて存在する価値はない」・・・・深い

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

強い気持ちとCIOのバックアップ・・・同感です！はしごを外されると改革が頓挫しますよね。RT@hamanoyosshi: @ToshiyaSeki システム部門が業務改革の先頭に立つには、ユーザ部門の既得権益と戦う強い気持ちが必要！ CIOはこれをバックアップする役目。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

しかし、リポジトリ統合の為にディクショナリ整理してるけど、泥くせえなあ・・・まあ、これが俺のやり方だから仕方ないか・・・

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

どんなに素晴らしい「キラーパス」も、相手の裏を取る事ができ、かつ、足が速いストライカーの存在無しには無意味。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

「スパゲッティ状のプログラム」を、ベテラン達が頑張って繋げたままなのかもしれません。まさに以前おっしゃていた「データ統合の欠如」そのものかもしれませんね。 RT@mattfrafra

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

コミュニケーションの価値は受け手が決める。いくら高尚な理論に基づいた情報を発信しても、受け手が受けきれなければ意味をなさない。高尚な情報の発信を考える前に受けてのレベルを上げる事が先決。又、そのレベルも努力すれば理解可能なレベルでなければ無理。モデリングも同様。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

上流から作り込めれば理想的ですねRT@470sailer:製造業の基本ですね。テストは保証、念のためにやる RT“@bluerabbit777jp: テスト工程をきっちりやれば品質が上がるなんて幻想…品質を上げるには開発時の技術力が必須。品質は作り込みで上がるのだ。”

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

データとプロセス、そしてその交差する処をCRUDできちんと管理する・・・それだけで充分。余計な情報は人を惑わすだけ。あくまで「最小の情報で最大の成果を」がモデリングを企業活動に生かす上での基本。ごちゃごちゃ複雑な入り組んだモデルを維持できるのはほんの一握りの「エリートさん」のみ

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

更なる業務改善の検証分析の為、業務フローをごりごり書く・・・とりあえずもうそろそろプロセスモデルを安定させよう

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@sashi1958 　前工程のアウトプットが次工程のインプットとして有用でなければ意味はありません。分析と称して見栄えばかりきれいな絵を描かれて提示されても開発には役に立ちません。むしろ弊害になるケースもあります。各工程で本当に必要な成果物を理解していないコンサルも多いのでは

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

そもそもビジネスの基本がわかっていない自称SE、コンサルが多すぎます。RT@sashi1958: 先日中堅ＳＩ会社の社長と話をした。最近大手のベンダ－の上流工程の設計の質が落ちており、変更が多く苦労しているので何か対策はないか？と。ＩＴ業界で共通の悩みだな！！

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@SHINNOH 理想は「トップダウンで骨組を作り、ボトムアップで肉付けする」事だと思っています。現実にはどっちかに引っ張られてしまうことが多いのですが・・・・

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

「要求」を「要件」として纏める事がきちんとできるかどうかですねRT@470sailer:こういう機能が欲しいと言われて、その理由がわからないまま作ってしまうのは、やめるべき。理由がわかれば解決案は他にもあるかもしれない。もちろん、作る必要がない場合も。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@470sailer 　ユーザー要求のうち、「政治的に」要件として残り機能として実装したものは陳腐化が早いです。ユーザーにとって開発カットオーバー後、保守開始こそが本当の意味でスタートです。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@hamanoyosshi モデルの抽象化を高めれば高める程、汎用的になるので再利用性は高まりますが、「体で仕事を覚える」タイプの現場の人間に理解してもらうのはほとんど無理でした。汎用性が高く、かつ同時に特化されている仕組みがあればすばらしいですね！

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

リポジトリの整理中・・・・

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

ビジネス用語の意味が社内で微妙に異なっている事を感じる。DBで管理されている用語だけでなく「社内標準語」の整理が必要だ。そして可能であればディクショナリに何でもかんでもぶち込みたいものだ。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

同感です。ポーズに踊らされるユーザーは悲惨です。 RT@marotabicom:クラウドやSaaSをポーズで売っている、提案しているかどうかは問題ではなく、その先進技術を持っている、理解しているということをユーザに示す必要があるからだ。エコを知らないとはいえないのと同じだ。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

情報システムはプロセス（動的）とデータ（静的）・・・動的モデルと静的モデルを作成、維持、成長させることによりシステムライフサイクルをより長くすることができる。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

もう少し、情報システムの原理原則について議論する場があっていい・・流行廃りはあるものの昔と今で変わらないものもある。変わらないものをきちんと理解した上で、次のステップに進むべき（古いのかな）

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

「要求」をきちんと「要件」として整理し、立場の異なる者が理解できる表現でモデル化する事こそ・・・上流工程の第一歩

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@ssakamot8 ユーザーはメンテできない成果物を抱えなくて済むし、Ｓｉｅｒはソースから役に立たない成果物もどきを作らなくて済むから、両者にとって無駄な工数の削減になるのではないでしょうか？もし認識が違いが生じているならば、それはコミュニケーションの問題ですね。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

@ssakamot8 Xupperの当初のコンセプトであった「最小の情報で最大の効果」こそ成果物を作成する際、必要な考え方だと思います。

赤　俊哉@ITエンジニア／コンサルタント @ToshiyaSeki

成果物っていくら見栄えが良くて、納品用として最適でも、その後10年システムが稼働し続ける限り、有用で有り続けられなければ意味ない。Sierは無駄な成果物に工数かけて作りすぎでは？