皆さんこんにちは。
エコモットの板橋です。
弊社は、自社サービスを運営しており、継続的な機能の改善や強化に取り組んでいます。
そんな中で「サービスを今後どの様に発展させていくか」だったり「価値を高めていくか」といった事をよく考えます。
今回は、そういった場面で役立つ２つの考え方（概念）について書いていきたいと思います。
なお、”概念”と記載した通り、考え方はもちろん、場合によっては私の主観が含まれる内容です。
皆さんも、想像しながら読んでいただき、皆さんなりの受け止めや考えを整理してみると良いと思います。
みなさまこんにちは。
エコモットの板橋です。
前回は「1文節1仕様を導入してみた」について記載しました。
これは主に、要件定義や設計書に記載する内容について、可能な限り曖昧な記述を排除するための対策として導入した手法でした。
今回は、トレーサビリティに関して書いていきたいと思います。
今まで書いてきた記事の中でも、少し匂わせぶりに書いてきましたが、それは「とっておき」だからではなく、どのように書いたら分かりやすいかなぁ、、、と悩んでいました（苦笑）
では、今回も文章量多めですが、進めていきましょう。
皆様、こんにちは。
エコモットの板橋です。
前回投稿した「バグ分析」は、主にシステム開発の下流でいかに状況を把握して、リスクコントロールしていくかというお話でした。
今回は、同じプロジェクトで同時に導入した要件定義～設計工程までに導入した「1文節1仕様」というルールについてお話ししたいと思います。
※実際は、上流から下流に至るまでのトレーサビリティもやっていますので、現実的には「1文節1仕様1ID」なんですけど、”1ID”の部分はまた今度…
なお、この記事は以前に書いた「察する文化」がシステム開発と相性が悪いという現実の深掘り・導入編に該当するものです。
まだ読んでいない方は、先にお読みいただくことで、導入のきっかけや考えについて理解が深まると思います。
続きを読む
皆さんこんにちは。
GXソリューショングループの板橋です。
前回は、「システム開発プロジェクトのゴールは、安定した運用の状態に設定したほうがいいですよ」という話をしました。
今回は、システム開発失敗の大きな原因とその背景について少し掘り下げて考え、私のグループで実践している対策を少し紹介したいと思います。
※今回も文字成分多めになっちゃいました（ﾃﾍ
続きを読む
