ブログを始める事で業務改善を試みる

自分がブログを始めたきっかけは、社会人2年目の時に言われた上司からの一言だった。

ブログを書くことで日々勉強した内容をまとめ、人の目に触れても問題ないような形でアウトプットすることで、復習にもなるし、もし忘れてしまった時も自分のブログを見れば思い出せる。

これに加え、最近ではもうひとつ別の効果を期待できるのではないかと考え始めた。

その効果というのは、

ブログの記事にするために、日々の業務において常に問題点を意識し改善策を考える

というもの。

ブログなんかに頼らずともそんなことは当たり前だと思います。

ただ、目の前の業務に追われ、ついつい問題に気付きはすれど後回しにしがちというのが常日頃。

そこで

日々の業務　→　ブログにまとめる

というベクトルだったのを、

ブログに書く内容　→　日々の業務

という方向に働かせることで、ブログに書きたいことを日々の業務の中で探そうと意識し始めます。

そして問題点が見つかれば、その問題の原因とそれに対する改善の考察をしなければ、文章として公開できるような内容にはできないので真面目に考えるというサイクルが出来上がります。

あとは改善点を業務に生かし、結果報告を改めてブログで紹介するという流れです。

自社オリジナル製品における「暗黙の了解」、「見えざる仕様」がもたらす害

入社5年目になっても、「今日、初めて知った」という仕様があったという話を耳にしたので、製品における品質と絡めて考えてみました。

結論から言うと、

自社製品において「暗黙の了解」「見えざる使用」が多ければ多いほど、 製品の品質を確保することが困難になる

ということが言えるのではないかと思います。

「暗黙の了解」が、設計当初から考慮できる熟練者であれば問題にはならないかもしれないが、経験が浅い担当者であれば、その「暗黙の了解」に気付くことさえなく、リリースされてしまうことがありえるかと思います。

当然、レビューを実施していれば防げる問題かもしれませんが、必ずしもレビュー時に拾い上げることができる状況とは言いがたいのが現状です。

そういった状況で開発が進んでしまい、製品がリリースされないまでも、リリース直前で問題が発覚することで、問題に対応するためのスケジュール調整および発覚した問題への対応がドタバタした状況下で始まります。

当然、納期の遅延、想定外の追加原価の発生など、喜ばしくないことばかりで変に疲れてしまいます。

こうした状況を避け、品質の確保および手戻りをなくすためには、日々現場で行われている一子相伝的な情報のやり取りではなく、目に見える形での情報伝達が必要となってきます。

「暗黙の了解」のような情報をきちんと伝達し、品質確保および手戻り削減を実現するためには、

• 如何に効率よく集め、
• 必要なときに必要な情報を取り出せるようにできるか？

に尽きると思います。

口頭での仕様確認を減らし、データを蓄積し、他の人からも閲覧ができることを考えると、障害報告や問い合わせ等に redmine を活用した情報のやり取りが定着しつつあるので、redmine をベースとした情報共有を進めていくということも「暗黙の了解」「見えざる仕様」を減らすことができる手法となるかもしれないので、まずは身近なところから初めて見ようと思います。