« 2013年7月 | トップページ | 2013年9月 »

2013年8月23日 (金)

三人寄れば文殊の知恵が、、、、、まとまらない

ここ1,2週間、数人での作業が発生した。イメージ的には文章の手直しの作業で、時々意見の相違が発生した。「てにおは」の修正のような(ある意味)微々たる事項から、論理的な文になってないなど様々。ある意味そのための作業であり仕方ないし、話すことで妙案に進展したものもあったが、各自の考え方の相違で多少平行線のものがあった。似たような作業でのここ1年くらいでは、ヒートアップ度やその回数が一番大きかったかもしれない。

で、ふと思い出したのが、開発時の会議や設計ドキュメントのレビュー時の意見対立。直接レビュー会議のような場での意見提示でなくても、トラッキングシステム(大昔なら紙に記載してその紙を回覧しながらコメント記入)でも相反する意見が出ることがある。書いたのがAさんなら、修正案がBさんから出て、別修正案がCさんから出たり、元々のAさん記載が良いとの意見が出たりする。

ものの本ではレビューの必要性などが書かれているけど、レビューの必要性よりもどう収束させるかが悩ましい。その部分は、大昔から良い解法がないように思う。ある意味ではレビュー技法などが発展してないとも言えるし、レビューを実施している人達はレビューに関する記事や論文を余り当てにしてないのかもしれない。より正確な表現を使えば、レビューを実施している人達にとって参考となる記事や論文は少ないのかもしれない。

もちろん、論理的/合理的な説明で収束したり実験検証に委ねたりするケースもあって手法もあるが、リーダー格が「えいやっ」で判断せざる終えない局面もある。平行線になった場合、そのような判断を誰かがしていかないと、効率が悪くてしょうがない。

ここ1,2週間での作業で、意見の相違が多かったのにそれなりにまとまったのは、リーダー格を明示的に決めていたことだったろう。当然と言えば当然だけど、今回は皆さん意見がばらけるかもとの意識があったせいかと思う。

ちなみに、”インスペクション”手法での役割として”モデレーター”があるが、ここで言ってる意見集約での責任者という意味では、個人的にはちょっと違うと認識している。ファシリテーターに近いし兼ねることが出来るかもしれないが、合意形成を素早く行ったり判断が必要な点でも少し異なるように思える。なおここでのリーダー格がちょっと大変なのは、せっかく合意形成が出来たり自分が判断したのに、特に上司や他部門によりひっくり返される時があること。しかし、まっ、こればかりは仕方ないと割り切るしかない。


さて今回の作業などで、つい思い出したことがある。2つのプロジェクト。片方は開発ドキュメントもそうだが、特許明細とか営業やユーザ向けの文書チェック作業も発生。冒頭で書いたような「てにおは」の修正にも神経を使ったそうだ。(大変だったろうが、後述するプロジェクトよりは遙かに精度が高いことになる。)

もう一つは聞きづてのもので、納品物のドキュメントに対して「○○が書かれてないから記載して欲しい」とか誤字脱字の指摘を行った人の話。委託先から一言あってPLも誤字脱字“ばかり”指摘するのもと、修正に消極的。他の件もあって、システム化への意識のもなく横柄なPLとの印象もあって、結構プロジェクトそのものに幻滅したとのこと。本人は、不明な未記載ロジックの記載が主で、誤字脱字はついででの指摘のつもりだったのだが。

結局、納品物はそのままOK。検収とか支払いが絡むからだったのかもしれないが、何のための納品チェックなのか??? 修正などを見越してないやり方だったと言える。案外、請負や丸投げでの根本的な問題なのかもしれない。


つまりレビューをすることの必要性などが記事や論文で書かれているけど、それをそう反映するとか、契約と絡めて議論していかないと/組織体で解決策を持っていないとメリットが生まれない。逆にレビューをやっているところは、反映方法や契約と絡めた対処法をより向上させるべきだろう。

8月 23, 2013 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年8月22日 (木)

ソフトウェアのお掃除タイミング

しばらく前から気にしてた事項に、ソフトウェアのメンテナンス時期があった。OSSなどを使っていたらセキュリティパッチの情報により、更新したりが必要である。プロダクトラインでの管理をしていたりそうでない場合でも、他機種での変更情報が自分担当の機種に関係するかが気になったりする。

開発中や直近で出荷したものならまだ開発メンバーもいるが、出荷後に期間を経た場合はメンバーが別部署に異動しているケースもある。あるいは退社したり、委託先の会社が消滅していることもありえる。

組込み機器の開発でない場合でもセキュリティパッチへの意識は同様だし、ITシステムの場合は利用側からの変更要望が発生したりする。

セキュリティパッチの場合は、パッチ発生の度に対応していたら効率が悪いことがある。再テストもそうだし、多少厄介なのがパッチリリース自体にバグが潜んでいるケース。かといって対応を延び延びにしていては、忘れてしまったりして重要なトラブルになってしまうことがある。次機種や次のITシステム開発の場合でも、従来のソースコードを見直さないと潜在的なバグが次機種などで発生することがあったり、リファクタリングのための工数が見極めにくい。

つまり、問題発生時や新機種/新システムの開発に向けてのソースコード見直し以外に、ソースコードを綺麗にしたり問題点を見つけておくことが必要だ。ソフトウェアのメンテナンスをコンスタントに行っておく意識が必要。また、集中的なソースコードレビューは行われるだろうが、どうしても重要な部分に限定されたり、時が経つと修正などが入ることがある。自分の経験則では、リーダーのような直接タッチしてない人が何気にソースコードを眺めた時にバグやコーディングルール逸脱が見つかることがある。そう考えたら、ふと家事の特にお掃除のスケジューリングってどうしてるんだろうとか、どう教えてるのか気になった。


で、自分の卒業した高校には、当時”家政科”なるものがあって、同窓会のちょっとしたイベントの時に聞いてみた。「授業で、家事のスケジューリング方法とか教えた?」と。返事としては、習わなかったし実際の主婦でもスケジューリングまでやってる人は少ないかもとのことだった。ある意味、予想どおり。

そこで、ネットで調べると授業の格好でまとまっているのは見かけなかったけど、個人ブログで各自の工夫として掲載しているのはいくつか見つかった。もっと良いのがあるかもしれないが、見かけたのは以下。

http://kajirakuraku.com/cleaning001.html
月と週でスケジュール表を作ってみようというもの。

http://ameblo.jp/kajino-chie2525/entry-11442422842.html
どちらかというと、年/月レベル主体でのスケジューリング。

http://ameblo.jp/logica/entry-10460566887.html
ファストフード店などの掃除の仕方を参考にして、表に掃除する日をマークして、実施したら名前を書くようにしようとの提案。

皆さん、それぞれ工夫している。


そうこうしているうちに気になったのが、事業所での掃除や害虫駆除。法律での背景があるように聞いたので確認してみることにした。(法律が根拠と思ったけど、実際は法律に直接書かれているわけではなくて、基準での運用だった。)

http://www.sharosisikaku.com/backnumber/anneihou/20060318.html
掃除や害虫駆除に関してフランクにまとめてあった。

http://www.mhlw.go.jp/bunya/kenkou/seikatsu-eisei10/
厚労省の「建築物環境衛生管理基準について」のページ。

半年に1度は大掃除をして、害虫がいないかの調査をしなさいとある。


他を参考にする限りでは、曜日や月を決めてソフトウェアのメンテナンスをするのが良さそうだ。また、それらはソースコードをいじっている人以外も巻き込んでスケジュール案を検討するのがよいと言える。暗黙なり明確に、その組織体でルールを決めて実施したかの確認まで行と良い。

(掃除をしたかしないかが一目瞭然なように)ソースコード上のどこを見直したかが視覚的に分かるように工夫したり、出荷後に期間を経た場合でも定常的な業務項目としてノミネートしておくなどすれば完璧だろう。

追記:2013/12/18のNHK「あさイチ」で、掃除術を放送していた。

http://datazoo.jp/tv/%E3%81%82%E3%81%95%E3%82%A4%E3%83%81%28%E6%B0%B4%E6%9B%9C%E6%97%A5%29/689108

その中で登場したのが”予定掃除表”。冷蔵庫や換気扇の掃除予定に○をつけておき、実施したら塗りつぶすというもの。予定の横軸は、曜日だったように思う。

8月 22, 2013 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2013年8月12日 (月)

街路樹とケーブルの共存

今日は出掛ける際にデジカメ持参して、前から気になってた街路樹をパチリ。

P8123141P8123142電線などが木の中腹を横切ってる。結構長い距離にわたって、この光景が続いてる。

都内でも結構この類の光景は多い。暴風雨になったら、停電や通信途絶の可能性が大である。ちょっと/いや結構不安になってきた。特に、昨今は異常気象で、強風や竜巻になることも多い。また電柱の上にまで木が伸びるということは、木の方に落雷する可能性が高いということ。そうなるとケーブルの被膜が燃えたりすることもありえる。

全部地下化しろとまでは言わないにしても、剪定して高さを低めにするなども考えないと行けないと思う。また、電柱やそのケーブルまでを考慮した街路樹の選定なども必要になってくるだろう。

備えあれば憂い無し、、、、。


8月 12, 2013 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)