こんにちは。デバイスソフトウエア開発部の本間です。
弊社では、様々な IoT 機器を開発・販売しております。 私もこれまで、いくつかの IoT 機器のファームウェア開発に携わってきました。
IoT 機器に求められる機能は、センサデータの収集、異常の検知、クラウドとの連携、機器状態の管理など多岐にわたります。 これらの機能をどのような仕組みで実現するかを考えることは、IoT 機器のシステム設計における面白さの一つだと感じております。
今回は、そのようなシステム設計の一例として、Fluent Bit をイベントルーターとして利用し、複数のプロセスをイベントで連携させる構成を紹介します。
こんにちは！クラウドソリューション開発部の北島です。
ソフトウェア開発では、仕様書を用意していても、実装段階で確認事項が次々と発生することがあります。
特に API 設計においては、仕様の解釈違いや共通ルールの不足によって、QA が想定以上に増えやすくなります。
本記事では、プロジェクト運用中に発生した実際のAPI設計に関する QA 40件（Backlog履歴）をBacklog AIで分析し、どのような確認が多く発生していたのかを整理しました。
「仕様書はあるのに実装者からの質疑応答が止まらない…」という現場の悩みを解消するため、設計段階で整えておくべき4つの共通ルールとチェックリストをご紹介します。
(※本記事ではQAを「実装前後に発生した確認事項・質疑応答」として扱います)
今苦しんでいる人、これから実装をおまかせする人の手助けになればと思います。
続きを読む
皆さんこんにちは。
エコモットの板橋です。
弊社は、自社サービスを運営しており、継続的な機能の改善や強化に取り組んでいます。
そんな中で「サービスを今後どの様に発展させていくか」だったり「価値を高めていくか」といった事をよく考えます。
今回は、そういった場面で役立つ２つの考え方（概念）について書いていきたいと思います。
なお、”概念”と記載した通り、考え方はもちろん、場合によっては私の主観が含まれる内容です。
皆さんも、想像しながら読んでいただき、皆さんなりの受け止めや考えを整理してみると良いと思います。
みなさまこんにちは。
エコモットの板橋です。
前回は「1文節1仕様を導入してみた」について記載しました。
これは主に、要件定義や設計書に記載する内容について、可能な限り曖昧な記述を排除するための対策として導入した手法でした。
今回は、トレーサビリティに関して書いていきたいと思います。
今まで書いてきた記事の中でも、少し匂わせぶりに書いてきましたが、それは「とっておき」だからではなく、どのように書いたら分かりやすいかなぁ、、、と悩んでいました（苦笑）
では、今回も文章量多めですが、進めていきましょう。
皆様、こんにちは。
エコモットの板橋です。
前回投稿した「バグ分析」は、主にシステム開発の下流でいかに状況を把握して、リスクコントロールしていくかというお話でした。
今回は、同じプロジェクトで同時に導入した要件定義～設計工程までに導入した「1文節1仕様」というルールについてお話ししたいと思います。
※実際は、上流から下流に至るまでのトレーサビリティもやっていますので、現実的には「1文節1仕様1ID」なんですけど、”1ID”の部分はまた今度…
なお、この記事は以前に書いた「察する文化」がシステム開発と相性が悪いという現実の深掘り・導入編に該当するものです。
まだ読んでいない方は、先にお読みいただくことで、導入のきっかけや考えについて理解が深まると思います。
続きを読む
皆さんこんにちは。
GXソリューショングループの板橋です。
前回は、「システム開発プロジェクトのゴールは、安定した運用の状態に設定したほうがいいですよ」という話をしました。
今回は、システム開発失敗の大きな原因とその背景について少し掘り下げて考え、私のグループで実践している対策を少し紹介したいと思います。
※今回も文字成分多めになっちゃいました（ﾃﾍ
続きを読む
