危険はことは避けるべき

Subversionのログを調べると、commitが衝突していて、その後、updateしてcommitしているというケースがある。
開発チームに状況を聞いてみると、複数のプログラマが同時に同じファイルを修正しているが、commitするときには調整してからcommitしているから、構成管理ミスはないという。
ログの内容から判断して、その説明もかなり怪しいが、仮に彼らの説明を信じるとしても、やはり人的誤りが起こり得るような運用は避けたほうが良いだろう。
今の場合なら、「複数のプログラマが同時に同じファイルを修正する」ような運用は構成管理ミスを招きやすいので、避けるべきだ。

• 原則として、一つのファイルは一人のプログラマだけが修正することとする
• 一つのファイルを複数のプログラマが修正する場合でも、commitできるのは一人とする

この規則を守るだけでも、構成管理ミスは減らせるはずだ。
とくに共通のヘッダファイルや設定ファイルには、この規則を徹底する方が良い。

★WOZ★

設計書を作るのに”遅すぎる”ということはない

ソフトウェア開発では、

• 開発期間が短い
• 開発メンバーが少ない
• いつの間にか納期が迫っている
• 忘れていた
• 最初から作るつもりがなかった

など、様々な理由で設計書が作られていないことが多い。
それは、設計書をつくらなくても、プログラミングさえすれば動作するソフトウェアが出来上がってしまうためだ。

実際、僕自身も仕事や勉強で使う”ちょっとしたツール”をつくるのに、わざわざ設計書を作ったことがない。機能を試しながら作ったプロトタイプが、そのまま普段使うツールになることが多い。

しかし、ソフトウェア製品となると話が別だ。
規模も大きいし、リリースした後も長く保守しつづける必要がある。
設計書がないと、検証や妥当性確認ができないし、移植や保守も非常に困難になる。

もうリリース間近になって、あるいはリリースしてしまって、いまさら設計書なんて作っても意味がないと、開発チームの人々は考えるかもしれない。

この先、その製品がバージョンアップしたり、バグを修正する必要に迫られないのなら、それは事実だ。設計はいらない。

しかし、その可能性が少しでもあるのなら、リリースしてからでも良いので、ソースコードから設計書を書き起こしておきたい。
わかりやすいところからソースコードを読み解くのが基本だが、EnterpriseArchitectなどのリバースエンジニアリングツールを用いれば、ソースコードからクラス図やシーケンス図を自動生成することができるので、設計書作成の強力な助けになるはずだ。

★WOZ★

失敗の兆候に気づいて、失敗を予防したい

ソフトウェア開発チームの仕事について、何か失敗しそうだという感じがすることがある。

しばらくの間、同じ開発案件を対象として、開発計画の進捗状況をウォッチしていたり、設計書のレビューに参加していると、とくにそうだ。

実際に失敗することもあるし、そうでないこともあるのだが、失敗した時に、その理由を調べてみると、「あの時、失敗の兆候に気づいていれば、予防できたのに、、、」と残念な気持ちになることが多い。

ソフトウェアの他の分野でも、そんなことを感じている人は多い様で、工学の一分野として研究されている。

★WOZ★

失敗学のすすめ (講談社文庫) 著者：畑村 洋太郎 販売元：講談社 Amazon.co.jpで詳細を確認する

エクセルに限界を感じたら、データベースを活用しよう

システムやソフトウェア関連の仕事をしている部門を見ていると、各種データを管理するのに、何故かデータベースではなくエクセルを使っている場合が多い。

そして、あるシートの幅が大きくなってモニター画面に収まりにくくなったら、収まらない部分だけを新しいシートに移す。

ここまで書いていて、その考え方はおかしいと思うのだが、さらに、

シートの追加を繰り返すうちに、同じような内容のシートがどんどん増えていき、周りの人はもちろん、作っている本人でさえも、それぞれのシートの役割がわからなくなってしまい、遅かれ早かれこのやり方でのデータ管理が破綻してしまう。

何故データベースを使わないのか？

• データベースの存在を知らない
• データベースを使えない
• マイクロソフトやエクセルが好きだ
• 仕事を非効率なままにしておきたい
• 早く帰りたくない
• 会社の仕事を破綻させたい

など、

理由は色々あるだろうが、データベースのほうがデータ管理も加工も簡単だ。

今ならオラクルも無料で使えるし、MySQLはもともと無料だ。

仕事を楽にするために、便利に使えるものはどんどん使っていきたい。

★WOZ★

ソフトウェアのチカラ（１）

3月から4月にかけて、人事異動や退職でチームのメンバー構成が変わることが多い。このご時世なら人数が減ってしまうチームも多いだろう。

メンバー構成が変わる時には、仕事の引き継ぎが発生するのだが、それが複雑な業務だったりすると、残りのメンバーで上手くその業務をこなしていけるかどうか、不安に思うものだ。

しかし、そんな時こそ、業務見直しのチャンスとも言える。

• これまでやっていた業務を整理して、不要なものは止めてしまう
• これまで人手でやっていた業務で、ソフトウェアでできるものはソフトウェアでする

こういったことを考えてみると、一見複雑に思える業務も、以外にシンプルになるものだ。

不要な業務をやめ、必要な業務もできるだけ効率化して、気持ちよく仕事ができる第一歩にしたいものだ。

★WOZ★

テーブルソートを実現するJavaScriptライブラリ

先日、とある情報をリスト表示するWebページを作って、仲間内で公開したところ、早速、リスト表示をソートする機能を付けて欲しいというリクエストを受けた。
そこで、tablesortというJavaScriptのライブラリを使って、さくっと作ってみた。

Webページ自体は、オラクルデータベースのデータを基に、Pythonで自動生成させており、その自動生成プログラムは、あっという間に作れたのだが、今回のソート機能も、ものの30分もかからずに作れた。

世の中便利になったものだ。

★WOZ★

KPT

KPTという言葉は、あまり知られていないかもしれないが、

• Keep
• Problem
• Try

の頭文字を並べた、プロセス改善関係の用語だ。

ある仕事が一区切りしたときに、その仕事を振り返り、

• うまく行ったので引き続きすること（Keep）
• 問題があったので、やめること（Problem）
• うまく行きそうなので新たにやってみたいこと（Try）

を整理することをいう。

ただ、一つの仕事が終わると、大抵は次の仕事が待ち構えていて、終わった仕事を振り返るどころではない、というのが現実だろう。

一度に振り返るのは大変なので、普段から少しづつ書き留めておき、最後はまとめるだけ、という具合に工夫したい。

また、KPTを整理して次回の開発に活用することはISO9001やCMMIが求める「継続的改善」にあたるので、程度はともかく、そのプロセスは実施しておきたい。

★WOZ★

相棒・最終回でのオービスの不具合

3月10日放送の相棒シーズン８・最終回で、顔認識システム（Facial Recognition System: FRS）をNシステム（自動車ナンバー自動読取装置）に組み込んだために、

• オービスが法定速度で走っている車を撮影してしまう
• オービスが2回フラッシュをたく

という不具合が発生してしまうというエピソードがあった。

フラッシュの不具合は、1回の撮影に1回のフラッシュという規則があると仮定すると、Nシステム用の撮影コマンドに加えて、顔認識システム用に撮影コマンドが1回追加されたのかもしれない。その結果、一回の違反車の撮影にフラッシュが2回たかれる。

一方、法定速度で走っている車を撮影してしまう不具合は、デバッグ用の設定をそのままシステムに残してしまったことが原因ではないかと思う。

つまり、デバッグ中はできるだけたくさんのデータを集めたいので、ターゲットが速度違反を起こすのを待っているのでは効率が悪い。

そこで、システムのデバッグ用に、違反となる速度の閾値のパラメータを下げてデータを集めた。本来であれば、デバッグが終わればパラメータを元に戻さなければならないのだが、それを忘れたので、今回のような不具合が発生したのではないだろうか。

実はこの手の人為的ミスは、コンピュータシステム開発のいろいろなところでよく起こっている。

そのつもりで、コンピュータシステムの不具合に関するニュースを見ていると、「あぁ、これか」と思い当たるものもあるはずだ。

★WOZ★

構成管理のリスク

Subversionでバージョン管理していると、updateコマンドを使うことが多い。
しかし、このupdateコマンドはリポジトリの内容で、ローカルのファイルを上書きしてしまうため、注意が必要だ。
例えば、あるファイルを修正している途中で壊してしまった場合に、updateコマンドでリポジトリから修正前のファイルをとってくるということがよくある。
しかし、ここでうっかり、そのファイルより上位のディレクトリをupdateしてしまうと、目的のファイル以外のファイルもupdateされてしまう。
つまり、もし他のファイルの修正もしている場合、そのupdateにより、意図しないファイルまで、以前の状態に戻ってしまうわけだ。

このようにupdateコマンドをうっかり使うと思わぬ失敗につながることがあるので、使うときには細心の注意を払う必要がある。

★WOZ★

ソフトウェア開発における品質と納期の優先順位

物事には優先順位があるものだが、それはソフトウェア開発でも同じだ。

よく引き合いに出されるのが、”品質”と”納期”のどちらを優先させるかという問題だが、企業のソフトウェア開発では、ほとんどの場合に納期が優先される。

それは次のような理由からだろう。

”品質”に問題がある場合、実際に客先で不具合が起こるまでは、それはリスクのままだ。もしかしたら、バグがあるソースコードが実行されることがないかもしれない。その場合は不具合は起こらない。

一方、”納期”は一日でも遅れると誰の目にも明らかな問題になる。

そのため、納期が品質より優先される。

そして、納期に間に合わなそうになると、

• 設計書を作らない
• レビューをしない
• テストをしない

ということが、納期遵守という旗印の下に、平気で行われる。

これらはいずれも、最低限の品質を確保するのに必要なものだが、納期が優先されているので省略される。

こんな省略をするのは、リリースしてから不具合が発生して騒動になるリスクを大きくしているだけなのだが、リリース前はとにかく納期に間に合わせるのが最優先なので、本来必要なことが省略される。

この状態の危険性は、開発プロセスとして本来やるべきことを知っていれば明らかなのだが、まだ開発プロセスがそれほど普及していないので、危険を前にしても、実は危険に気づいていないというのが実状なのだろう。

★WOZ★

CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて 著者：アクセンチュア 販売元：ソフトバンククリエイティブ Amazon.co.jpで詳細を確認する

構成管理のリスクを小さくする

Subversionのログを見ていると、問題が起こりそうな開発チームがすぐわかる。

例えば、ある人があるファイルをチェックアウトして、その人がそのファイルをコミットする前に、別の人がそのファイルをチェックアウトしていれば、そのファイルには上書きのリスクが発生しているという具合だ。

これなどは、あるファイルを触れるのは特定の人だけ、という規則を作ってしまえば容易に回避できるリスクなのだが、実際の開発ではそうできないと考えている開発チームが多い。

ただでさえソフトウェア開発にはたくさんのリスクがあるのだから、簡単に回避できる方法があれば、これまでと違った方法であったとしても、真っ先に適用したいものだ。

★WOZ★

PythonとPySerialでシリアル通信アプリケーションを作れる

Windows7上に作ったシリアル通信のテスト環境で、Pythonによるシリアル通信を試してみた。今回使ったはPySerial2.5とPython2.6だ。

PythonアプリケーションとTeraTermとの間で読み書きできることを確認できた。

以下は、COM20とCOM21を仮想接続した状態で、TeraTermでCOM20に接続し、PythonアプリケーションでCOM21に接続する場合だ。

（１）COM21に接続して"hello"を入力してポートを閉じる

>>> import serial
>>> ser = serial.Serial(20) 
>>> print ser.portstr       
>>> ser.write("hello")     
>>> ser.close()             

するとTeraTermに"hello"が表示される。

（２）COM21に接続してTeraTermからの入力を待つ

>>> ser = serial.Serial(21 )
>>> s = ser.read(5)        
>>> ser.close()

TeraTermで"hello"と入力すると、sに"hello"がバインドされる。
----------
PythonとPySerialの組み合わせで、このように非常にお手軽にシリアル通信を実現できる。

ところで、残念ながらPython3.1ではPySerialのimportが失敗するが、64bit-Windows7だけの問題かもしれない。またLinuxで試してみるつもりだ。

★WOZ★

Windows7に仮想シリアルドライバcom0comをインストールする

一台のWindowsマシンでシリアル通信アプリケーションのテストをする環境を構築するために、仮想シリアルドライバcom0comをインストールしてみた。

ここで注意しないといけないのは、64bitのWindows7にcom0comをインストールするには、インストール前に次の操作をしなければならないことだ。

１．管理者権限でコマンドプロンプトを起動する
２．bcdedit.exe -set TESTSIGNING ON

その後、com0com付属の設定ツールを使って、仮想的に接続したい２つのシリアルポートの設定をした後、TeraTermを２つ起動して、それぞれのシリアルポートに接続する。

シリアルポートの名前は、例えば"COM20"と"COM21"という名前にすると良い。

この状態で、一方のTeraTermに入力した文字列が他方に表示されれば、com0comは正しくインストールされている。

★WOZ★

ISO9001の文書管理

今時のソフトウェア開発では、ソフトウェアの設計書は、紙ではなく電子ファイルで管理している組織が多いだろう。

しかし、ISO9001の文書管理に関する要求からは、電子ファイルでの文書保管には注意が必要だ。

電子ファイルの管理でよくあるのが、ファイル名に年月日をつけてバージョンを表し、古いファイルも新しいファイルも、全部まとめて一つのディレクトリに入れているパターンだ。

この管理方法だと、最新版だと思って古いものを使ってしまったり、最新版を修正しようとして古い版を修正してしまうというミスを犯すリスクが大きくなる。

この問題の解決方法として、例えばoldという名前のサブディレクトリをつくり、古いものはそのディレクトリに入れてしまい、元のディレクトリには最新版だけを残す、という方法がある。

確かに、この方法だと、古いものを使ったり修正したりするリスクが小さくなるので一定の効果はあるだろう。

しかし、できることならSubversionなどのバージョン管理システムを使って、設計書その他文書を管理するのが望ましい。

★WOZ★

Pythonの辞書

Pythonの辞書はいろいろなところで便利に使える。
例えば、名前から年齢を知る辞書だと、下のように使う。

キー（名前）と値（年齢）の組を取り出すなら、

>>> adict = {'taro':20, 'jiro':15}
>>> for name, age in adict.items():
...         print name, age
...
taro 20
jiro 15

キーを取り出すなら、

>>> for name in adict.keys():
...     print name
...
taro
jiro

あるキーが含まれているかどうかを調べるなら、

>>> 'jiro' in adict
True
>>> 'saburo' in adict
False

キーのリストを作るなら、

>>> adict.keys()
['taro', 'jiro']

★WOZ★