ヌルポなクーロン

　会社案内のパンフレットを作っていて思うのだが、パンフレットのネタに悩むようなソフトウェア会社は将来性がない。おそらく会社の方向性を定めきれていないのだ。特定の分野に何も強みを持たない受託開発しか行っておらず、自社のプロダクトやサービスも持たない。たとえ自社のプロダクトやサービスを持っていても、その内容があまりにもお粗末で、アクティブな状態ではない・・・。
　―― 経営者が明確なビジョンを持っていない。戦略的ではなく、偶然の引き合いに会社の経営を委ねている。パンフレットの内容をしっかり読み解いていくと、そんなことが読み取れるように思う。

　PM（プロジェクトマネージャー）とPL（プロジェクトリーダー）の違いが明確ではないソフトウェア会社がある。以前に勤めていた会社がまさにそうだ。一般にPMはプロジェクトの総責任者で、特に開発リソースや予算に関する責任的立場だ。一方、PLは実際に開発を行うチームの指揮官であり、プロジェクト遂行の責任的立場だ。
　以前に勤めていた会社のように、組織体系が曖昧なソフトウェア会社では、PM兼PLという責任の所在を担当者に押し付ける傾向がある。ましてやPMとはなばかりで、ただ書類上に名前が記載されているだけの存在も多い。「ソフトウェア会社に営業は必要か否か？」の糸口として、PMは受注活動から職務が始まり、見積り、引き合いの受注を経て開発リソースの割り当て、PLの選定を行い、そこから先はPLに実行権限を委譲する。つまり営業的な活動をもカバーする役割であるべきだと思う。ここに経営者の意図が直接的に伝わる体制が整えば、かなり堅牢なソフトウェア会社になるのではないだろうか？

　以前に勤めていた会社で同僚が嘆いていた。「ろくにシゴトも取ってこない営業に年間600万円も払う必要があるのか？ソフトウェア会社に営業なんて必要なのか？」・・・と。確かにソフトウェア会社の多くの営業は物販で売上をあげるのは難しく、営業費という名目で間接費を消費しながら受託案件をとってくることでその役割を果たしている。しかし実際のところ、ソフトウェア開発の知識を持たない者が引き合いの勘所をつかみ、受注につなげることは難しいものだ。概算を見積る能力もないので引き合いの確度もお構いなしに開発部門に丸投げする。そして開発部門は抱えている案件の時間を削りながら、この無意味な受注活動に付き合わされる。肝臓が人より強いことだけが自慢の営業は、もうソフトウェア会社に必要ないかも知れない。

　最近、ケータイでムービーを撮るようになったのだが、ムービー初心者が出ばなをくじかれそうな落とし穴があった。FOMAやauで撮った3gp、3g2、amc形式の動画ファイルは、Windows Media Playerで再生できないようだ。ましてやWindowsムービーメーカーで試しに編集してみようものなら、avi形式に変換しなければならない。そんなときにQTConverterは単純明快、素晴らしく初心者にやさしいツールだ。様々な動画ファイルへの相互変換が可能になっている。

　QTConvertor - Hoppysoft

　Microsoft Wordと親和性の高い図形作成ツールといえばVisioだが、文書作成の支援ツールと考えると、これがなかなかお高い。社内でひとりVisioを使ったところで、他のスタッフと連携できなくなってしまうのでこれも問題。かと言ってOfficeの描画機能では辛いところ。何かわりとスタンダードなものはないかと探していたところ、Diaを見つけた。
　DiaはGTK+ベースのGPLライセンスなドローイングソフト。Windowsユーザーには取っ付きにくいユーザーインターフェースだが、Visioに近い汎用的な図形を作成できる。DFD図やER図、画面遷移図あたりなら標準テンプレートを試行錯誤して表現できる。ネットワーク構成を描くテンプレートも備わっているので、このあたりはOfficeの描画機能以上の表現をサクッと実現できるだろう。2007年4月のリリースでバージョン0.96.1。まだまだ進化してくれるのだろうか？

　Dia - live.gnome.org

　エンジニアは技術的な知識を多く持つあまり、ユーザー企業の担当者を軽んじる傾向があるように思う。確かにコンピュータやシステム開発の知識をほとんど持ち合わせていないユーザー企業の担当者は、ときどきオッパッピーな発想をする。しかしそれはソフトウェアの専門知識を持つエンジニアではないのだから当然のこと。いやいやバカにするどころか、完成したシステムの基本的な使い方を理解すると、その応用力たるものはスゴイ。自分なりの発見を繰り返しながらシステムを活用してくれる。特にインターネット上のサービスは技術的な裏打ちよりも、運営者が作り上げるコンテンツが重要。そのサービスが成功するかどうかはユーザー企業の“チカラ”によるところが大きいことを、エンジニアは心しておく必要がある。

　業務におけるデータの流れを表記するDFD図（データフローダイアグラム）。その表記法のひとつ、Chris GaneさんとTrish Sarsonさんのゲイン/サーソン式。データストアの左側や処理の上下の仕切り内には識別子やアクターなどを記述できる。特に記述しない場合は仕切りを省略しても良いみたい。

　業務におけるデータの流れを表記するDFD図（データフローダイアグラム）。その表記法のひとつ、Tom DeMarcoさんのデマルコ式。

　「プログラムを実行する」の英語、executeの発音は[エグゼキュート]だと思っていたが、辞書で調べてみたら[エクセキュート]だった。略語でexeやexecと書かれていると、[エグゼ]や[エグゼック]と読んでいたが、それだとexecutive[エグゼクティブ]の略語になってしまう。つまり「役員」ってこと？

　IT業界は「きつい、帰れない、給料が安い」のニュー3K。学生にとても不人気らしい。これに加えて「規則が厳しい、休暇がとれない、化粧がのらない、結婚できない」の7K。すばらしい！あまりにも的確だ！しかしまぁー、こんな3Kや7Kを右から左へ受け流しながらIT業界を漂っている私はかなり“変人”だと思う。それどころかこれは願ってもないチャンスだと思っている。
　実際、今の世の中を見渡してみると、あらゆる物にソフトウェアが関与している。ソフトウェアは物理的なカタチとして現れないので日常生活の中で気が付かないが、確実に人間社会を取り囲んでいる。その依存度がより大きくなり、より一般の人々の間で身近に使われるようになると、IT技術者の希少性が高まり、3Kや7Kが一機に逆転するに違いない。そこにチャンスがある。まだまだIT業界そのものが古い体質なので表面には現れていないが、もう一部の技術者は密かにその恩恵を受け始めているのではないだろうか？そんな技術者は3Kや7Kを右から左へ受け流している・・・。

　ウォーターフォール・モデルで言うところの外部設計で記述する仕様書は、人によって「外部設計書」と言ったり、「基本設計書」と言ったりする。若干のニュアンスの違いはあるが、基本的に同じ目的のドキュメント。Googleでそれぞれどれくらいヒットするのか調べてみた。

「外部設計書」・・・約8,300件
「基本設計書」・・・約20,000件
「ソフトウェア設計書」・・・約700件
「外部仕様書」・・・約2,800件
「基本仕様書」・・・約3,800件
「ソフトウェア仕様書」・・・約2,800件

　「基本設計書」が断トツでヒットした。続いて「外部設計書」。

　多くのソフトウェア開発が外部設計⇒内部設計⇒実装の流れに従っていた時代は「外部設計書」が主流だったかも知れないが、最近では設計全般⇒プログラム設計＋実装＋単体テストという開発フェーズの括りがほとんどだと思われるので、「基本設計書」と設計全般を思わせるコトバがしっくり来るのかも知れない。

　GPLライセンスはフリーソフトウェアなライセンスと考えられているが、具体的なところを把握しておく必要がある。まずGPLライセンスのソフトウェアを入手して、実行することは自由だ。また改変することも許され、それ故にソースコードも入手できる。さらに複製物の再頒布も認められている。ただここからが要注意。コピーレフトという考え方が組み込まれていて、再頒布物にもGPLライセンスが適用される。つまり再頒布物のソースコードも入手できる状況におかなければならない。
　ではGPLライセンスなオープンソース・ソフトウェアの一部に改変を加えたものを実行し、その上で実現される機能をサービスとして提供している場合は、改変したソースコードを公開しなければならないか？どうやらコピーレフトの考え方としては、出力物に対して適用しているのではなく、そのソフトウェアそのものの再頒布を指している。つまりGPLライセンスのソフトウェアを利用・改変したソフトウェアで実現しているサービスだからといって、そのソースコードを公開しなければならない訳ではない。

　バナーサイズには国際標準があるようだ。IAB（Interactive Advertising Bureau）という機関がバナーサイズのガイドラインを定めていて、レクタングル＆ポップアップ、バナー＆ボタン、スカイスクレーパーとカテゴリー分けされている。

300 x 250: Medium Rectangle
250 x 250: Square Pop-Up
240 x 400: Vertical Rectangle
336 x 280: Large Rectangle
180 x 150: Rectangle
300 x 100: 3:1 Rectangle
720 x 300: Pop-Under

468 x 60: Full Banner
234 x 60: Half Banner
120 x 90: Button 1
120 x 60: Button 2
88 x 31: Micro Bar
120 x 240: Vertical Banner
125 x 125: Square Button
728 x 90: Leaderboard

160 x 600: Wide Skyscraper
120 x 600: Skyscraper
300 x 600: Half Page Ad

　IAB（Interactive Advertising Bureau）

　Tomcat5.5 + MySQL5.0の環境でMySQL Connector/J（JDBCドライバー）越しに日本語のWHERE条件を発行したところ、これがなんと全くヒットしない。日本語ではなくアルファベットなら問題ない。どうやら文字コードが一致していないみたいだ。
　ログを見てみると SET NAMES utf8 は実行しているようだが、この場合はこれだけではダメみたい。MySQL Connector/JのcharacterEncodingを明示的に指定してみた。（省略すると"autodetect"となるようだが、それではうまく行かないようだ。）

<Resource name="jdbc/ClassioleDB" auth="Container" type="javax.sql.DataSource"
username="xxx" password="xxx" driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://localhost:3306/xxx?autoReconnect=true&noDatetimeStringSync=true&characterEncoding=UTF8" maxActive="8" maxIdle="4"/>

　Connector/JのDriver/Datasourceクラス名、URL シンタックス、および構成プロパティ