工数と開発期間の差をうめる経営努力
ソフトウェア開発では作業にかける時間（工数）とカレンダー上の時間（開発期間）が一致しないことがよくある。1日8時間の工数をかけて5日間 作業した場合、40hの工数となる。しかし開発期間としては5日間で終わるかというと、発注元からの回答待ちや、テスト担当者からの障害報告待ちなど、様々な要因で工数と開発期間は一致しなくなるものだ。しかし経営者は実作業の工数が40hであっても、トータルの開発期間が10日間を要するとしたら、80hの見積もりを考える傾向がある。
これは担当者の拘束期間も含めた考え方だ。客先に常駐して時間を完全に拘束されるならこの考え方は正しい。しかし、社内の受託作業でも同じ考え方をとる経営者がいる。本来であればこの場合、経営努力でリソースの稼働率を最適化し、コストパフォーマンスの改善を図るものだ。今のソフトウェア業界が他の業界に比べていかに甘い環境にあるかと感じてしまう。
これは担当者の拘束期間も含めた考え方だ。客先に常駐して時間を完全に拘束されるならこの考え方は正しい。しかし、社内の受託作業でも同じ考え方をとる経営者がいる。本来であればこの場合、経営努力でリソースの稼働率を最適化し、コストパフォーマンスの改善を図るものだ。今のソフトウェア業界が他の業界に比べていかに甘い環境にあるかと感じてしまう。
技術管理部を置くこと
ソフトウェア会社には技術管理部を置くべきだ。体力の少ないソフトウェア会社には難しいことかも知れない。しかし開発現場で働く直接部門のスタッフに、技術の管理や新規開拓を兼務させることは無謀な行為だ。直接部門のスタッフは顧客満足度を少しでも上げようと労働時間を最大限に割り振る。そのようなスタッフに間接作業（間接費に相当するような作業）を与えると、当然のように優先度は落とされ、コンスタントに作業が継続されることを期待できない。ましてや過度の労働を強いている状況ではどの道、アウトプットは期待できない。なので間接部門としての専属の技術管理スタッフが必要だ。
以前に「ソフトウェア会社に営業は必要か否か？」という記事を書いたが、“営業”という部門はいらない。営業・技術管理・PMの３つの役割をカバーする部門が必要だ。これであれば体力の少ないソフトウェア会社にとっても負担が少なく、且つスケーラブルに組織を構成できると思う。
以前に「ソフトウェア会社に営業は必要か否か？」という記事を書いたが、“営業”という部門はいらない。営業・技術管理・PMの３つの役割をカバーする部門が必要だ。これであれば体力の少ないソフトウェア会社にとっても負担が少なく、且つスケーラブルに組織を構成できると思う。
引き合い管理とプロジェクト管理
CMMIで言うところの成熟度レベル１から脱却するには、とにもかくにもプロジェクト管理からだ。プロジェクト管理というと、無責任な経営者は開発現場におけるプロジェクトマネージメントだと考えるかも知れない。これは違う。成熟度レベル１から２のようなレベルでは、開発現場ではなく経営層におけるプロジェクトマネージメントが必要だ。どのようなプロセスが発足し、どのような要件とスケジュールで、実績としてどうだったか。開発現場の人間がマネージメントする話しではない。
また実際に受注した案件だけではなく、引き合いもすべて管理すべきだ。引き合いの数や受注率、引き合い内容の傾向から経営判断の材料が得られる。このようなことを開発現場のスタッフに委ねているようでは、景気や運に身を任せたソフトウェア会社と言われてしまうだろう。
また実際に受注した案件だけではなく、引き合いもすべて管理すべきだ。引き合いの数や受注率、引き合い内容の傾向から経営判断の材料が得られる。このようなことを開発現場のスタッフに委ねているようでは、景気や運に身を任せたソフトウェア会社と言われてしまうだろう。
ソフトウェア会社には開発プロセスの体系化が必須
10年以上、ソフトウェア開発のライフサイクルを繰り返してきて思うに、ソフトウェア会社として開発プロセスの体系化を図ることは必須だと思う。今まで、そして今でも多くのソフトウェア会社は社員個々人が開発プロセスに対するスキルや経験を持ち、彼ら独自のノウハウでプロジェクトを進行してきた。高度なノウハウを持ち合わせているエンジニアは、比較的に円滑なプロジェクト進行をする。しかしそうではないエンジニアは開発そのものよりも、プロジェクト進行に迷い、無駄に時間を費やす傾向がある。仕様書の体裁や目次に迷うことすらまったくもって無意味だ。このことは結果的にプロジェクトごとのバラツキを発生させ、会社としての開発パフォーマンスを不安定なものにする。経営者としても先の予測ができない故に、突如として経営が傾く。
実はこれこそCMMI（Capability Maturity Model Integration、能力成熟度モデル統合）で示されているところと一致する。とにかく成熟度レベル１からの脱却が必要だ。ソフトウェア会社を起業するのであれば、成熟度レベル３がスタートラインだと考えるべきだ。
実はこれこそCMMI（Capability Maturity Model Integration、能力成熟度モデル統合）で示されているところと一致する。とにかく成熟度レベル１からの脱却が必要だ。ソフトウェア会社を起業するのであれば、成熟度レベル３がスタートラインだと考えるべきだ。
技術習得の労力を安く見積もってはいけない
ソフトウェア会社の経営者は技術習得のための労力を安く見積りすぎだ。ソフトウェア技術は高いお金を払って講習会に参加したところで習得できるとは限らず、ほとんどが独学や経験の中から習得する。そのため、会社にとって未知の技術分野に社員が果敢に挑み、その技術を習得したとしても、経営者は彼が費やした労力を考えようとはしない。そのような会社は社員ひとりひとりに技術があるだけで、会社としての技術はまったく蓄積されていない。プロジェクトのデスマーチ、社員の過度な労働、モチベーション低下、競争力の低迷、営業展開の行き詰まり・・・ここから様々な問題が引き起こるように思う。
バスケット買いって何を観測する？
株式市場のレポートを見ていると、「バスケット買いが観測され・・・」という表現を目にする。何かの値動きを観測しているのだろうが、このバスケット買いとは何だろう？調べてみた。バスケット買いとは大口の投資家が複数の銘柄を大口取引するバスケット取引で、一般的に15銘柄以上、かつ1億円以上の取引に適用される。立会外の時間帯でも取引できることから、前場と後場の間にバスケット取引が成立し、後場の寄り付き直後に株価がぐっと上がることがあるようだ。
ファンダメンタルズとは何者か？
経済レポートなどを見ていると、「ファンダメンタルズ」という言葉がよく出てくる。「ファンダメンタルズが良い」とか「〜が悪い」という用法で使われるので、何かモヤモヤっとしたカタチのものだとは想像していたが、調べてみたら英語で「fundamentals」、経済指標という意味だった。英語でfundamentalは「基本的な〜」とか「根本的な〜」とか、名詞で「基本」とか「原理」という意味なので、その複数形を使った経済用語らしい。国の規模で使われる場合は経済成長率などの経済指標のことを指し、企業の規模で使われる場合は財務諸表のことを指すようだ。要するに基本的な条件や要因という意味合いのモヤモヤっとしたものを指す。
名目GDPと実質GDP
GDP（国内総生産）には名目GDPと実質GDPがある。GDPとは国内の総消費金額を指すが、単純に市場価格から算出した場合、物価の動向により金額が変動してしまう。経済規模の実状を測ろうとするとき、この物価変動による影響を取り除いておきたい。そこで単純に市場価格から算出した金額を名目GDP、物価変動の影響を取り除いたものを実質GDPという。
GDP（国内総生産）とGNP（国民総生産）
GDP（国内総生産）とGNP（国民総生産）は小学校か中学校で習った言葉だが、この年になってその意味合いを明確に理解できていないことに気が付いた。GDP（国内総生産）は日本国内で消費された金額で、個人の消費や住宅投資、企業の設備投資がその内訳となる。一方、GNP（国民総生産）は日本国民により生産された総生産額を意味し、海外に進出した企業の生産額も含まれる。このようなGDPやGNPは他国や過去の推移と比較することで、その国の経済活動の強弱を測ることができる。
数字が読めない
悲しいことに数字が読めない。日本語の数字の単位が4桁ごとに変化するのに対して、欧米では3桁単位、桁区切りも3桁単位に入れる。理屈ぬきに覚えるしかない。最初のカンマはthousand（1千）、2つ目のカンマはmillion（100万）、3つ目のカンマはbillion（10億）、4つ目のカンマはtrillion（1兆）。4つ目は日本語と一致した。
もう一度、
もう一度、
thousand・・・1千しつこくもう一度、
million・・・100万
billion・・・10億
trillion・・・1兆
1兆, _ _ 10億, _ _ 100万, _ _ 1千, _ _ _では、10,000,000は？じゃー、100,000は？日常的に数字の計算をしてないとなかなか慣れない・・・。
Excelで背景色を１行ごとに色違いにする方法
Excelで１行ごとに色違いの背景色を設定する方法。条件付書式を使う。
表の行と列を罫線で区切ると格子状になって視認性が悪くなってしまう。なので行か列のどちらかの区切りには罫線を使わず、１行（または１列）ごとに背景色を変えるとスッキリする。行に対して行うか列に対して行うかは内容次第だが、雑誌やカタログに掲載されている表をよく見てみると、少なくとも行と列の罫線で単純な格子状になっていることはない。
・条件付書式の条件として、次の式を与える。MOD関数は与えられた引数の割り算を行い、その余りを返す関数。割られる値にROW関数を与えることで、その行番号を2で割ることになり、結果として１行ごとに1と0が返ることになる。1が返ったときに書式が適用されるので、１行ごとに色違いの背景色となる。
= MOD(ROW(), 2)
・条件を満たすときの書式として、背景色に薄めの色を与える。
表の行と列を罫線で区切ると格子状になって視認性が悪くなってしまう。なので行か列のどちらかの区切りには罫線を使わず、１行（または１列）ごとに背景色を変えるとスッキリする。行に対して行うか列に対して行うかは内容次第だが、雑誌やカタログに掲載されている表をよく見てみると、少なくとも行と列の罫線で単純な格子状になっていることはない。
会社案内のパンフレットで計る将来性
会社案内のパンフレットを作っていて思うのだが、パンフレットのネタに悩むようなソフトウェア会社は将来性がない。おそらく会社の方向性を定めきれていないのだ。特定の分野に何も強みを持たない受託開発しか行っておらず、自社のプロダクトやサービスも持たない。たとえ自社のプロダクトやサービスを持っていても、その内容があまりにもお粗末で、アクティブな状態ではない・・・。
―― 経営者が明確なビジョンを持っていない。戦略的ではなく、偶然の引き合いに会社の経営を委ねている。パンフレットの内容をしっかり読み解いていくと、そんなことが読み取れるように思う。
―― 経営者が明確なビジョンを持っていない。戦略的ではなく、偶然の引き合いに会社の経営を委ねている。パンフレットの内容をしっかり読み解いていくと、そんなことが読み取れるように思う。
PMとPLの違いがない！
PM（プロジェクトマネージャー）とPL（プロジェクトリーダー）の違いが明確ではないソフトウェア会社がある。以前に勤めていた会社がまさにそうだ。一般にPMはプロジェクトの総責任者で、特に開発リソースや予算に関する責任的立場だ。一方、PLは実際に開発を行うチームの指揮官であり、プロジェクト遂行の責任的立場だ。
以前に勤めていた会社のように、組織体系が曖昧なソフトウェア会社では、PM兼PLという責任の所在を担当者に押し付ける傾向がある。ましてやPMとはなばかりで、ただ書類上に名前が記載されているだけの存在も多い。「ソフトウェア会社に営業は必要か否か？」の糸口として、PMは受注活動から職務が始まり、見積り、引き合いの受注を経て開発リソースの割り当て、PLの選定を行い、そこから先はPLに実行権限を委譲する。つまり営業的な活動をもカバーする役割であるべきだと思う。ここに経営者の意図が直接的に伝わる体制が整えば、かなり堅牢なソフトウェア会社になるのではないだろうか？
以前に勤めていた会社のように、組織体系が曖昧なソフトウェア会社では、PM兼PLという責任の所在を担当者に押し付ける傾向がある。ましてやPMとはなばかりで、ただ書類上に名前が記載されているだけの存在も多い。「ソフトウェア会社に営業は必要か否か？」の糸口として、PMは受注活動から職務が始まり、見積り、引き合いの受注を経て開発リソースの割り当て、PLの選定を行い、そこから先はPLに実行権限を委譲する。つまり営業的な活動をもカバーする役割であるべきだと思う。ここに経営者の意図が直接的に伝わる体制が整えば、かなり堅牢なソフトウェア会社になるのではないだろうか？
ソフトウェア会社に営業は必要か否か？
以前に勤めていた会社で同僚が嘆いていた。「ろくにシゴトも取ってこない営業に年間600万円も払う必要があるのか？ソフトウェア会社に営業なんて必要なのか？」・・・と。確かにソフトウェア会社の多くの営業は物販で売上をあげるのは難しく、営業費という名目で間接費を消費しながら受託案件をとってくることでその役割を果たしている。しかし実際のところ、ソフトウェア開発の知識を持たない者が引き合いの勘所をつかみ、受注につなげることは難しいものだ。概算を見積る能力もないので引き合いの確度もお構いなしに開発部門に丸投げする。そして開発部門は抱えている案件の時間を削りながら、この無意味な受注活動に付き合わされる。肝臓が人より強いことだけが自慢の営業は、もうソフトウェア会社に必要ないかも知れない。
ムービー初心者の強い味方、QTConverter
最近、ケータイでムービーを撮るようになったのだが、ムービー初心者が出ばなをくじかれそうな落とし穴があった。FOMAやauで撮った3gp、3g2、amc形式の動画ファイルは、Windows Media Playerで再生できないようだ。ましてやWindowsムービーメーカーで試しに編集してみようものなら、avi形式に変換しなければならない。そんなときにQTConverterは単純明快、素晴らしく初心者にやさしいツールだ。様々な動画ファイルへの相互変換が可能になっている。
QTConvertor - Hoppysoft
QTConvertor - Hoppysoft
Visioの代用にDia
Microsoft Wordと親和性の高い図形作成ツールといえばVisioだが、文書作成の支援ツールと考えると、これがなかなかお高い。社内でひとりVisioを使ったところで、他のスタッフと連携できなくなってしまうのでこれも問題。かと言ってOfficeの描画機能では辛いところ。何かわりとスタンダードなものはないかと探していたところ、Diaを見つけた。
DiaはGTK+ベースのGPLライセンスなドローイングソフト。Windowsユーザーには取っ付きにくいユーザーインターフェースだが、Visioに近い汎用的な図形を作成できる。DFD図やER図、画面遷移図あたりなら標準テンプレートを試行錯誤して表現できる。ネットワーク構成を描くテンプレートも備わっているので、このあたりはOfficeの描画機能以上の表現をサクッと実現できるだろう。2007年4月のリリースでバージョン0.96.1。まだまだ進化してくれるのだろうか？
Dia - live.gnome.org
DiaはGTK+ベースのGPLライセンスなドローイングソフト。Windowsユーザーには取っ付きにくいユーザーインターフェースだが、Visioに近い汎用的な図形を作成できる。DFD図やER図、画面遷移図あたりなら標準テンプレートを試行錯誤して表現できる。ネットワーク構成を描くテンプレートも備わっているので、このあたりはOfficeの描画機能以上の表現をサクッと実現できるだろう。2007年4月のリリースでバージョン0.96.1。まだまだ進化してくれるのだろうか？
Dia - live.gnome.org
ユーザー企業の“チカラ”
エンジニアは技術的な知識を多く持つあまり、ユーザー企業の担当者を軽んじる傾向があるように思う。確かにコンピュータやシステム開発の知識をほとんど持ち合わせていないユーザー企業の担当者は、ときどきオッパッピーな発想をする。しかしそれはソフトウェアの専門知識を持つエンジニアではないのだから当然のこと。いやいやバカにするどころか、完成したシステムの基本的な使い方を理解すると、その応用力たるものはスゴイ。自分なりの発見を繰り返しながらシステムを活用してくれる。特にインターネット上のサービスは技術的な裏打ちよりも、運営者が作り上げるコンテンツが重要。そのサービスが成功するかどうかはユーザー企業の“チカラ”によるところが大きいことを、エンジニアは心しておく必要がある。
ゲイン/サーソン式のDFD表記
業務におけるデータの流れを表記するDFD図（データフローダイアグラム）。その表記法のひとつ、Chris GaneさんとTrish Sarsonさんのゲイン/サーソン式。データストアの左側や処理の上下の仕切り内には識別子やアクターなどを記述できる。特に記述しない場合は仕切りを省略しても良いみたい。
デマルコ式のDFD表記
業務におけるデータの流れを表記するDFD図（データフローダイアグラム）。その表記法のひとつ、Tom DeMarcoさんのデマルコ式。
executeはエクゼではない
「プログラムを実行する」の英語、executeの発音は[エグゼキュート]だと思っていたが、辞書で調べてみたら[エクセキュート]だった。略語でexeやexecと書かれていると、[エグゼ]や[エグゼック]と読んでいたが、それだとexecutive[エグゼクティブ]の略語になってしまう。つまり「役員」ってこと？
| ヌルポなクーロン |
