miyaniyanのブログ

ここでは日常生活の雑感を。 

情報システム全般

アジャイルでもウォーターフォールでもなく・・・

なぜか http://www.amazon.co.jp/dp/4822281108/ が読まれているように、システム開発の特に人にまつわる問題は相変わらず変らないように思える。 品質や生産性に関する議論も、60年代あたりの調査や考え方から大きく変っていないようにも思える。(すべての…

基幹系システムを作るのは誰だ

顧客側を支援するコンサルたちへ。システムをつくりあげるってどういうことかわかってんのかね? これまでSI会社や汎用機系ベンダが中心になってやってきた。 いまも、大きなプロジェクトになれば、機器やソフトのベンダを含め、 プログラムを書く人たち、全…

業務設計が大事だといっているだろ

どうして、システム屋は、システムの機能でしか物をいわないのか。 業務フローがすごく大事で、業務ルールが大事で、それを設計できる力があってはじめて、システムの必要性や重要性、効率の勘所がわかってくるんだけど、まったく聞かない人たちだ。って、誰…

品質保証のこと

久しぶりに書く。 新年早々(じゃないな、もう2月だから、新年1発目)、あまり面白くもない話。 品質保証。今の品質保証の考え方って汎用機での開発を前提に、JavaとかC#とかVBとか、言語レベルでの応用をしているだけじゃないのか?って思った。今のオー…

複数アーキテクチャを許容する。

開発時期が違い、選択された技術も違い、使い方も違い、利用者特性も違う。 単一のアーキテクチャでは無理がある。エンタープライズレベルでは、複数のアーキテクチャが存在することを認め、それらをどう方向付けていくかが、これからの情報システム化には必…

失敗の本質

ずいぶん前に、失敗の本質―日本軍の組織論的研究って本を読んだ。 とても面白く、そのときは組織論、組織行動論などにすごく惹かれていたときだった。 人材育成や組織活性化に向けて、なにかやれないか、ということでヒントを探していたときでもあったからと…

工程の考え方を変える

設計でしかわからないのであれば先にやる。 あらかじめやったほうがいいものは先にやる。 作るために最適の工程を考える。原則はこう。・作りたいものはどういうものかを考える(要求定義とか要件定義)・作ったものがいいのかどうかを評価する(総合試験と…

アーキテクチャ

アーキテクチャは思想だ。 権力だという説もある。でも、思想だとおもう。設計の指針となる方針というか、達成したい価値というか。対象領域に適合するシステムの機能とその相互作用をあらわしたもの。ってかんじかな。しかし、ややこしい。コンピュータアー…

クラウドな話

クラウド iPhoneやiPadがもらたした影響は、デバイスだけではなく、クラウド環境との連携であることはよくいわれる。その背景には、巨大なアップルのコンテンツ流通の仕組みがあって、いつのまにやら、GoogleやAmazonと並ぶようなシステムがあるとかないとか…