Ads by Google
新しい記事を書く事で広告が消せます。
リーダーシップ力の欠如は停滞につながる
政治の世界ではリーダーシップ力が重要だ。マーケットは政治に対して、強い意志を持ったリーダーシップ力に反応する。会社組織も同じ。リーダーシップ力の欠如は停滞につながる。リーダーシップ力を発揮するのは経営者かも知れないし、経営者の意思を受け継いだ現場のリーダーかも知れない。そう、どんなに小さなグループ組織でも、リーダーシップ力の欠如は発展性のない集団にしかなり得ないと思う。すべてフラットに横一列ではダメなのだ。
見積りは無料ではない
いろいろな見積りをしていると、RFPの手本となりそうな素晴らしい要件仕様が提示される場合もあれば、これで何を見積もって欲しいのか困惑してしまうほど資料の少ない依頼もある。システム開発の見積りは、クルマを買うときのように定価が決められた商品と工賃の組み合わせで積算できるものではなく、ひとつひとつの機能について難易度や規模などをはかり、実際の工数にできる限り近づける高度な作業が必要だ。依頼主が十分な見積り材料を提供せず、要件を引き出す手間を強いられても、ソフトウェア業界では一般的に見積り作業は無料である。これは悪しき慣習だ。受注できるかどうかも分からない引き合いに、そこまでコストを掛けられない。見積りは無料ではない、という意識が必要だ。
キーマンを発掘する
ソフトウェア会社の組織構成を考えるとき、キーマンとなる人材の発掘は重要だ。
SEには英語辞書が必需品
プログラミングの実装やデバッグを円滑に行うには、少なからず変数名やクラス名のネーミングが影響すると思う。変数名やクラス名が実際の利用内容とズレていると混乱の元凶。日本語のローマ字表現も最悪。どれも似たようなアルファベットの並びになってしまい、分かりにくいことこの上ない。10年くらい前の業務アプリではローマ字表現もまかり通っていたが、文字の読み違いによるケアレスミスに毎回、遭遇したことを思い出す。この時代はなんとものどかな時代だった。いまやインターネットの普及で技術者は海外の英語ドキュメントを読むのが常識。英語が分からないから日本語のローマ字表現を使おう、なんて言ってるようでは通用しない。
しかし日本人にとって微妙なニュアンスの違いを適切な英単語で表現するのは難しい。和製英語で恥ずかしい思いをするのも良いと思うが、やはり海外で通用するエンジニアを目指したい。そう思うと英語辞書は必需品。オンラインの翻訳サービスも使えるが、微妙なニュアンスの違いを調べるにはやはり“英辞郎 ”を傍らに置いておきたくなる・・・。
しかし日本人にとって微妙なニュアンスの違いを適切な英単語で表現するのは難しい。和製英語で恥ずかしい思いをするのも良いと思うが、やはり海外で通用するエンジニアを目指したい。そう思うと英語辞書は必需品。オンラインの翻訳サービスも使えるが、微妙なニュアンスの違いを調べるにはやはり“英辞郎 ”を傍らに置いておきたくなる・・・。
工数と開発期間の差をうめる経営努力
ソフトウェア開発では作業にかける時間（工数）とカレンダー上の時間（開発期間）が一致しないことがよくある。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)
・条件を満たすときの書式として、背景色に薄めの色を与える。
表の行と列を罫線で区切ると格子状になって視認性が悪くなってしまう。なので行か列のどちらかの区切りには罫線を使わず、１行（または１列）ごとに背景色を変えるとスッキリする。行に対して行うか列に対して行うかは内容次第だが、雑誌やカタログに掲載されている表をよく見てみると、少なくとも行と列の罫線で単純な格子状になっていることはない。
