みなさまこんにちは。
エコモットの板橋です。
前回は「1文節1仕様を導入してみた」について記載しました。
これは主に、要件定義や設計書に記載する内容について、可能な限り曖昧な記述を排除するための対策として導入した手法でした。
今回は、トレーサビリティに関して書いていきたいと思います。
今まで書いてきた記事の中でも、少し匂わせぶりに書いてきましたが、それは「とっておき」だからではなく、どのように書いたら分かりやすいかなぁ、、、と悩んでいました（苦笑）
では、今回も文章量多めですが、進めていきましょう。
こんにちは！SJC共同開発推進室の坂根です。
早いもので、入社から3年が経過し、エンジニア4年目に突入しました。
新人だったころに比べると、知らない技術への抵抗感はかなり減ったように思います。
最近では、知らないライブラリや新しいツールを触る機会でも、「とりあえず触ってみよう」「サンプルを使ってコードを書いてみよう」「調べながらで何とかなるだろう」と思える場面が増えてきました。
生成AIの存在もあり、以前よりハードルはかなり下がったように感じます。
逆に、最近難しさを感じるのは、何年も運用されている既存システムです。
今回は、4年目になった今だからこそ感じている、「新技術より、長く動いている既存システムのほうが怖い」という話をしようと思います。
皆様、こんにちは。
エコモットの板橋です。
前回投稿した「バグ分析」は、主にシステム開発の下流でいかに状況を把握して、リスクコントロールしていくかというお話でした。
今回は、同じプロジェクトで同時に導入した要件定義～設計工程までに導入した「1文節1仕様」というルールについてお話ししたいと思います。
※実際は、上流から下流に至るまでのトレーサビリティもやっていますので、現実的には「1文節1仕様1ID」なんですけど、”1ID”の部分はまた今度…
なお、この記事は以前に書いた「察する文化」がシステム開発と相性が悪いという現実の深掘り・導入編に該当するものです。
まだ読んでいない方は、先にお読みいただくことで、導入のきっかけや考えについて理解が深まると思います。
続きを読む
皆様、こんにちは。
エコモットの板橋です。
前回は「バグ分析のすすめ」という事でバグ分析の価値について書いたのですが、このままだと、ただの理想論で終わってしまいますので、今回は具体的にどうやって導入したのかや、苦労した話などチームに定着させるまでのリアルな話をしたいと思います。
この記事は下記の記事の続編として記載しており、その内容を前提として進行していきます。
まだ読んでいない方は、先にお読みいただくことで、より理解が深まると思います。
バグ分析のすすめ
みなさまこんにちは。
エコモットの板橋です。
今回は唐突に本題に入りますが、皆さんのチームでは、開発工程で発生したバグの情報をどの様に活用していますか？
え？ 納品物にしか使っていない？
それはもったいないお話ですね。
バグの情報は、プロジェクトのバイタルサインとして使える事を皆さんは知っていますか？
新年度を迎えたという事で、新たなプロジェクトの立ち上げ準備を進めている方もいるかと思いますので、この機会に是非「バグ分析」にトライしてみてはいかがでしょうか。
進捗を管理するだけの退屈な「管理作業」が、アグレッシブな「知的業務」に代わるはずです！
続きを読む
みなさんこんにちは。
エコモットの板橋です。
現在は3月末という事で、3月末納品に向けて燃えている全力疾走中の所もあるのではないでしょうか。
先日公開した「プロジェクトのゴール設定」の話、「察する文化はシステム開発と相性が悪い」話と、少し関連してくる話になります。
今回はソフトウェア業界で良く飛び交う品質について掘り下げて考えていきたいと思います。
※今回ここに記載した内容は、執筆者である私の私見になります。
この記事を読みながら、一緒に皆さんも考えて頂けると嬉しいです。
