変な社長シリーズ(3) ― 2007年05月06日 01時39分54秒
小さい会社、それも、ソフトウェア開発を行う会社の場合、社長自らがエンジニアとして開発業務を行う場合が少なくありません。 ここで紹介するのは「変な社長」というよりも社長の仕事やエンジニアの仕事を分かっていない、という実例です。
人手が足りなくて仕方なく、誰でも良いからエンジニアとして補充が必要でたまたま社長がそれを担当する、というような状況で仕事を請けるというのならばまだ良い方です。この場合は人員の補充ができれば引き継げばいい話。比較的良くある話だからです。
この社長、自社の社員やパートナーの補充の当てがないにも関わらず、一括の請負の仕事、しかも現場に常駐が必要な仕事を2件請けていました。そのような状況を発注元に正直に明かして理解してもらった上で請けているのならばまだしも、そのような状況は隠していました。そして、自らを担当エンジニアとしてアサインしたのです。
このような仕事の請け方をした時点で、社長としてもエンジニアとしても失格です。工数、人員、品質、設計、全ての管理が出来ていない証拠です。
なぜ、このようなことを行ってしまうのかというと、「責任を持つ」ということについて間違った認識をしているからに他なりません。
社長としてどのように判断したのかというと、せっかく注文があるのに、断ることになると、今後の取引に支障がでる、といったところでしょうか。 しかし、そのような仕事の請け方をして、仕事を完遂できない場合の会社の信用度のことまでは仕事を請ける段階で考えていません。社長としては余りに視野が狭すぎます。
エンジニアとしてはどうでしょう。一括で請け負った仕事だから開発場所、この場合は主にプログラミングですが、自分で頑張ればどうにかなると思って、B社のプログラミングをA社の作業場所で行うなどということを行いました。B社の機密保持契約が曖昧だということも問題ではありますが、A社の業務について、真剣に取り組んでいないところにも大いに問題があります。 複数の仕事をそれぞれに理解してもらった上で請け負った側で適当に配分するのは間違いではありませんが、この社長は両社に隠していました。社長として隠すのは分かりますが、エンジニアとしては隠すべきではありません。 エンジニアとしての誇りがあれば、このような中途半端なことはできるはずもありません。
この社長はどのように行動すべきだったかを以下に箇条書きにしてみます。
- 納期と人員の関係を適切に判断してB社の仕事は断る
- 断らないのであれば、人員の状況を説明して納期の条件を出して納得の上での発注をしてもらうように調整する
- 調整が出来ないのであればやはり断る
組込み屋さんではdoxygenは普及していない ― 2007年05月06日 04時44分57秒
UNIX系の開発もしくは開発環境に慣れ親しんでいる方たちでdoxygenを知らない方は多分いないと思います。
しかし、UNIX環境が無縁の組込みの現場で既にdoxygenを活用していた、などという現場に出会ったことがありません。
doxygenはC/C++/JAVAなどのソースプログラムからそのソフトウェアの構造や関連を「みえるようにする」ためのツールの一つです。 特に、組込みの特徴の一つである、「コピーして派生物を作る」というスタイルにならざるを得ない開発スタイルの場合、必要不可欠のツールといえます。
にも関わらず、組込みLinuxでの組込み以外の組込み開発の現場では使われていません。
doxygenは当初はUNIX環境でしか動作しませんでしたが、現在はWindows環境での動作も問題なくできるツールで他人の作ったプログラムを解析するのにはなくてはならないものです。 また、納品物としての仕様書をdoxygenで我慢してもらうというような場合にも十分に使えるものです。
現在私が常駐している開発現場でも誰一人doxygenを知りませんでした。 ですが、勝手にソースコードレビューを行うためのツールとしてdoxygenを使っています。
変わり映えしないESEC ― 2007年05月19日 08時17分21秒
ESEC、組込みシステム開発技術展に行ってきました。
去年は３日間の開催期間全てに行きましたが、今年は最終日のみ見学しました。
結論から言えば、ほとんど見るべきものがない。 というか、何を誰に見て欲しいのかを端的に表した展示をしている会社がほとんどない。つまり、マーケティングの必然として展示会に参加している会社がほとんどない、という言い方もできます。
この展示会は全体としては誰に対して展示しているのかというと、何らかのメーカをターゲットにしています。
展示している会社はチップメーカ、基板メーカ、アセンブリメーカ、機器メーカ、デバッグ機器メーカ、半導体商社、機器商社、ソフトウェア開発ツールメーカ、ソフトウェア商社、基本ソフトメーカ、などなど・・・多岐に渡ります。
メーカが自分たちが抱えている案件で適用できるチップやツールを探しに行くため、現物に触れることができる、ということが展示会を開催する大きな意味であると思います。
であれば、それぞれの展示会社のターゲットは最初から決まっているわけで、不特定多数に漠然としたメッセージを投げかけるような展示は無意味です。
そんな中で一目で目的がわかるのは技術誌を出版している会社ですね。単に本を売りたいという目的がはっきりしているし、ターゲットもメーカではなく、展示会に訪れた技術に関心のある人全て、ですから。
一番意味不明な展示が、いわゆる、映像関連の機器を使って、映像を流すような展示です。 確かに見た目は分かりやすいですが、何屋さんなのかは分からない。
- 映像コンテンツのデコーダチップのメーカ？
- デコーダチップを使ったソフトウェアを開発したメーカ？
- それを内蔵した機器のメーカ？
- その機器を販売する商社？
- コンテンツを提供するシステムを開発するシステムインテグレータ？
- 映像コンテンツを伝送するための通信機器のメーカ？
- 伝送チップのメーカ？
そしてそういう分かりやすい展示に限って、関係ない客で賑わってしまって、肝心の本当のターゲットとなる客に十分な説明が出来ず、きちんとメッセージを伝えられない。
一方で、隣接している「Web2.0マーケッティングフェア」の方は非常に展示が分かりやすかった。マーケティング主体なだけに、伝え方がうまい。ESECの方はほとんどの会社が会社名を大きな字で展示しているのに大してWeb2.0マーケティングフェアの方は「何を伝えたいのか」をメインに展示していました。
また、いわゆるIBM PC ATアーキテクチャのPCベースの小さ目のマザーボードを組込み機器として扱っていますが、私の分類では組込み機器ではありませんので、ここでは採り上げません。普通のマスコミでのESECレポートでこの分類のものを採り上げていますが、裏を返せば他に何もレポートすべきものがなかったということです。
あえて、一番面白かった展示を挙げるとすれば、IPAのブースでしょうか。未踏ソフトウェア系の試みで小さなソフトウェア開発会社がアイディアの面白いソフトウェアの成果を発表していました。
なお、説明員は絶対にネクタイを締めたスーツ姿は避けるべきです。そのブースに入りたくなくなりますから。そんな基本的な展示会戦略が出来ていない会社が多いのもESECの特徴かもしれません。
ライセンスフィーしか考えないメーカの存在 ― 2007年05月20日 22時09分01秒
ESECでとあるPC周辺機器を開発するメーカと商談する機会がありました。
商談の相手は企画部署の責任者で、そのメーカには自社にソフトウェアの開発を管理する人間を置いていません。そのため、この企画部署の責任者が外注のソフトウェア開発会社のコントロールを行ってきたようです。
そこで分かったのは「まだまだ知らない文化の存在」です。
この担当者。いわゆるソフトウェアの「受託開発」という契約形態を異質なものとして受け入れていません。
ある機器に機能を追加するためにはハードウェアを追加しない場合はソフトウェアで機能を追加する必要がありますが、この担当者は開発費を考えていません。機器１台あたりのソフトウェアのライセンスフィーがいくらか、という考え方しかしないのです。１台の機器にそのソフトウェアを追加すると１００円とか。１０００台の機器が売れれば１０万円ということです。仮に開発費に２００万かかったとしても１０万円は変わりません。 ２万台売れれば元が取れて、それ以上売れればかなりの儲けにはなります。
但し、このようなライセンスフィーの考え方の場合は台数によって単価が変わりますので、台数が多ければディスカウントが必要になりますので、単純に儲けがでるわけでもありません。
もちろん、ライセンスフィーですからソフトウェアのソースコードを提供する必要はありません。逆にきちんとしたバイナリのインストール手順が必要です。その機器のソフトウェアの開発を全体的に行っているのであれば何の問題もありませんが、実はこのようなことは意外とむずかしい。つまり、その機能を追加する担当のソフトウェア開発会社以外の会社の開発物も同様にソースコードが提供されず、仕様書すらまともかどうか分からないわけですから。
個人的にはこのような機器メーカの考え方は正しいようで間違っていると思います。逆の立場で全く物事を考えていないからです。その機器に対応するための開発環境整備には意外と金がかかりますし、目的の機能を追加する以前に全体の把握も必要です。そのような初期費用を請求できないのだとすると、誰も望んでこのようなメーカの開発は請けないでしょう。私も請けません。
ISO9001と形骸化した無意味な品質管理 ― 2007年05月25日 00時30分08秒
大手の企業を中心にISO9001の認証を取得して、品質管理が徹底していることを誇示することが流行っています。
ここで言う、品質管理とは、
- 品質管理のための手順がマニュアル化されている
- マニュアルどおりに実施する
- マニュアルどおりに実施していることを監査する
- 監査した結果をフィードバックする仕組みがある
というような「手順を守っている」ということであり、必ずしも品質が高いということではありません。
このような風潮の結果何が起きるのかというと、
- 手順だけが重視され中身の濃い検査が行われない
- 形式的な部分が重要視され本質の理解がない
- 本質を理解した検査項目を考えないため無駄な時間を費やす
- 本質を理解していないという自覚がない
- 無駄な時間を費やしているという自覚もない
- 問題意識の高い人間のモチベーションが下がる
- 問題意識のない人間だけが組織の歯車になる
- 本質的な品質が低下する
- 品質が低下しているという監査を誰も行えない
ということになります。
最近のコメント