« 2005年10月 | トップページ | 2005年12月 »

腐れソース

なんか、デスマーチに突入したっぽいです。
とある害虫…もとい 外注に発注してつくらせたところを引き継いだんですが、これの品質が酷いのなんのって もうありえないレベルです。

非常につらいのが 既に製品として世に出しているために 既存ソースのサポートを放棄するわけに行かないところです。とてつもない腐れソースなんで 本当は とっとと廃棄して一から作り直したいんですが しばらくはこの腐れソースと付き合っていかざるを得ません。

仕方が無いので、腐れソースの不具合対応をしながら 一から作り直そうとしているんですが あまりにも元のソースにバグがでまくるので、バグ対応だけでアップアップ状態です。
作り直しが全然できません。

はぁ… 今週末は土日が無さそう…

| | コメント (3) | トラックバック (0)

空中元彌チョップ

私は結構格闘技好きなんですが、中でもエンターテイメント系のプロレス好きです。
プロレスに興味ない人には全然わからないと思いますが、例えばWWEやドラゴンゲート(前の登龍門)は良く観てます。

同じ系統のエンタメ系プロレスということで 小川直也率いるハッスルにも興味はあったんですが これまでなかなか観る機会がありませんでした。
と思っていたところ、GyaOハッスルマニアを無料放送してましたので 今回初めてハッスルを観る機会を得ました。

で視聴の感想なんですが、これがなかなか面白いです。

中でも 和泉元彌が非常にいい味出してます。

彼が「空中元彌チョップ」という技で勝ったという記事は何回かニュースで観たことがあり、
その技名のインパクトの強烈さと、ネーミングセンスの酷さにどんな技なのか期待していました。

で、今回初めて技を観たわけですが期待に反しない技でした。
ある意味衝撃を受けました。

すんごい しょぼいです!!!

実際の衝撃は実物を見ていただきたいのですが、ある意味一見の価値があります。

| | コメント (0) | トラックバック (0)

くそース・苦ソース

 最近、仕事がややはまり気味です。
 ということで 気分転換に 少しでも妙案は無いものかと こんなワードでググってみたところなかなか興味深いものが落ちてました。
 「デスマーチからの脱出

 ここにおいてある パワーポイントの資料がなかなかいい感じです。

 特に、人間的デスマ対策PPT と プログラム的デスマ対策PPT が気にいりました。

 酷いソースを くそース というのはなかなかいい感じです。

 人に言われたらしばらく立ち直れなくなりそうな きっつい言葉なんで 本当に使うことはないんでしょうが、汚いコードを見たら 一回 仕事で言ってみたいもんです。

 「この くそース どうにかせぇ!!!!」

 ……って やっぱり駄目ですね。キツ過ぎますわ。

| | コメント (0) | トラックバック (0)

IT技術者の2人に1人は“プロ未満”

ITスキル標準(IT Skill Standard:ITSS)ってものがあります。
SEのスキルを客観的に計測・判定してくれるというものです。
(今は計測できませんが、ときどき無料で計測してくれます。)

少し前に一回計測してみたのですが、ちょうど昨日そのフィードバックの連絡がきました。

私の測定結果はLV3.6で、順位は約2000人中で約400位という数字でした。

ちなみに計測結果は、最小値がLV1,最大値がLV7で評価されていて、
ソフトウェアエンジニアの平均値は LV2.6となっています。

これが100%正しい計測結果とも思えませんが、客観的に自分がどの位置にいるかを知るのはなかなか面白いです。

私としては、とりあえず真ん中よりは上にいるということで面目は保てたかなぁという感じです。
もしビギナーなんて判定されていたら寝込んでいたかもしれませんしね…

| | コメント (0) | トラックバック (0)

エース格の外注さん

 前回、「外注さんを雇う最大の理由はいざと言うときの人減らしを簡単に行うため」と書きましたが、実際のところ、全員を解放するようなことはまずありません。
そんなことをしてしまうと、開発のノウハウも一緒に消えてしまうからです。

これは発注元のジレンマなんですが、開発のノウハウは外注さんが蓄積していくため、発注元にはなかなかノウハウが残りません。そのため ノウハウの塊のような人 いわゆるエース格の人は必ず残そうとします。逆に駄目な人は本当に容赦なくバッサリ切ってしまいますが…

また 他のチームにそのエース格の人が暇であることがバレルと引き抜かれる恐れがあるんで、少し暇になった場合 無理にでも仕事を渡して引き止めておいたりもします。

基本的に エース格の人は、引く手あまたなんで こんな無駄ことをしたりするわけですが、要するにそれほどデキル人は貴重で 大切にするってことです。

でも、まぁ 本当にすごい外注さんにめぐり合えることは残念ながら あまりないんですけどね…

| | コメント (0) | トラックバック (0)

外注を雇う本当の理由

Lv1からのSE成長日記さんへのトラックバックです。
外注さんを使う側の立場からどんなときに外注さんを雇うかまとめてみます。

ソフト開発の元請が、外注さんを使う理由は主に次のようなものです。
(1)自社要員だけで開発するには人数が足りないようなプロジェクトの場合に,人数の不足分を補うため。
(2)自社にプロジェクトを実現できる技術がない場合に、該当技術を補うため。
(3)自社社員よりも給料の安い外注さんを雇うことで開発費用を減らすため。

ちなみに、(1)や(2)の場合は、単純に外注さんを雇うのではなく中途採用 or 新人採用という選択肢もあります。

ただ、開発を行うために人を増強すると 開発の元請は大きなリスクを負うことになるため 普通は外注さんを雇います。

リスクを負う理由を説明すると、例えば大きな開発案件があったとします。
その案件を開発している間は大量の人員が必要になるわけですが、開発が終わってしまえば今度は大量の余剰人員が発生してしまいます。
この場合に、その余剰人員をどうすべきかという問題にぶちあたるわけです。

ここで、労基法第20条の問題がでてきます。
自社の社員は簡単には解雇できないという法律です。

開発案件がないのに余剰人員を抱えてしまうと赤字を垂れ流してしまいますので、普通はそんなことできません。
となると 必要に応じて人員を増強する場合 自社社員を増やすのではなく、外注さんを増やそうという話しになります。
目的は いざというときの人減らしを簡単に行うためです。

…えーと、見も蓋も無い結論ですが 自社社員ではなく外注さんを使う最大の理由はこんな感じです。

| | コメント (0) | トラックバック (0)

Windows系プログラマと組み込み系プログラマ

とある外注先に発注したソフトの出来が惨憺たるもので困っています。
ちなみのその外注先は 組み込み経験がない、Windows系のプログラマです。

プログラムの動作スピードが遅すぎてつかいものにならないのに加えて、バグがやたらめったら多くて、新しい機能を動かすたびにバグがでます。

実際に問題のソースを追いかけると、クラスの階層が深すぎるし、おんなじ名前のメソッドが山ほどでてくるし、コメント皆無だし、やたらめったらnewしまくるのにdelete忘れてるし、メンバー変数とローカル変数がごちゃごちゃでトリッキーな値の渡し方をしているし、等々…
いちゃもんを付け出したらきりがないほど酷いです。

とにかくもうぼろぼろなんですが、中でもたちが悪いのがメモリリーク(メモリの開放漏れ)です。すぐに症状がでないため追いかけにくいのに加えて、どこがリークしているのかを突き止めるのもかなり苦労します。

 メモリの獲得・開放を一対一できちんと行うですとか、担当者レベルでの単体試験を確実に行うですとか 組み込み系プログラマには常識だと思うのですが...
 
 ウィンドウズ系プログラマが皆こんなんだとは思いませんが、Windows系の実装経験はあんまり組み込みの役には立たないのでしょうか?
 まったく、やれやれです。

| | コメント (0) | トラックバック (0)

シンプルさの原則

ここになかなか面白いことが書かれていました。

■■シンプルさの第2原則:「サイバラの原則」■■
1+1=2
123×456=たくさん
12÷34+56÷78=そんな問題を解かなければならない状況に自分を持っていかない

計算の複雑さを ソフト開発のバグの量と対比させると非常に共感できる意見です。

ソフトの開発してて、やっぱり一番大事なことは、
不具合に埋もれるような状況に自分を持っていかないことにつきます。
如何に不具合を発生させないか が大事で、どれだけ事前に危険を察知できて 事前に手を打てるかが重要です。

とは言うものの、「そんな問題を解かねばならない状況に自分がほうりこまれてしまった」場合はそんなことは言ってられません。

 残念ながら、この状況に落ちてしまった場合、とにかく嵐が過ぎ去るまでは 耐えざるを得ません。
 でもまぁ、ただ状況に流されていてもしかたがないので、せめて状況を整理して どの程度遅れているのかを明確にすることで、秩序を持った状態には持っていきたいところです。

 同じ遅れている状況でも、無秩序に遅れている遅れているよりは、秩序を持って遅れているほうがまだましですから…

| | コメント (0) | トラックバック (0)

不具合の隠蔽

 自分や自分のチームから不具合がでたときの話しなんですが、闇でこそっと改修したいとか、できるならオープンにしたくないとかそんな誘惑にかられることがあります。
 個人的に不具合を隠したことはありませんが、チームメンバの改修状況をヒアリングする限り 結構闇改修って行われていたようです。
 今の上長も、不具合は結構隠したいみたいですし。。。

 大掛かりな話しになると、私の所属した会社(もしくは私の所属するプロジェクト)では、客先に特定の不具合を隠したことが何度かあります。
 下手に大量の不具合を客先に公開すると、そうでなくても落としている信用をさらに落とすことになるために公開なんぞできない…という理屈からです。
 で、これが客先にバレるともう、とんでもないことになるわけなのですが…(ちなみに今のところはバレタことはありません。)

 ただ、ちょっと前の三菱自動車のリコール隠しや 雪印がつぶれた件なぞみていると、細かい隠蔽を繰り返していると そのうち取り返しがつかなくなるような気がします。

 不具合を隠蔽する
 →自分にとって都合の悪い情報が集まってこなくなる
  →過去の問題を分析して、同じ問題を繰り返さないための対策を立てられなくなる。
   →改善ができなくなる…

 えーと、なんで不具合を隠しちゃいかんのか自分なりにまとめてみましたがこんな感じでしょうか?

 なんで、こんな話しをまとめたかというと、
 最近新しい不具合がでると隠したくて隠したくて仕方がないもんでして…

 我ながら精神力が弱い…なさけなや。

| | コメント (2) | トラックバック (0)

センス・オブ・プログラミング!

プログラミング(コーディング)の入門書籍として良著だと思います。
コーディングにおける基本がわかりやすく記載されています。

入門書といいつつ、これは言語についての解説書ではありませんので、この手の本を読んだことがないかたは注意が必要です。
C言語は一通り理解した上で、
 どうゆうスタイルでコーディングすればよいのか?
 設計ってどうすりゃいいの?
という視点で書かれています。

良著だといいましたが、逆に中級者以上にとっては 肩透かしをくらうレベルだと思います。
(逆に言うと この本を読んで驚いているようではまだまだ初心者です…)
でも、自分のコーディングスキルを見直すのには ちょうどよいかもしれません。

| | コメント (0) | トラックバック (0)

見積もり方法

(前回の続き)

私の見積もりに対する基本的な考えは次のようなものです。
100%完璧な見積もり(誤差なしの見積もり)をだすのは不可能
 →但し、見積もり誤差を少し減らすことは可能。
  →どうすれば少しでも誤差を減らすことができるか考える。
   →小さい誤差を減らすことの積み重ねで大きな誤差をちいさくする。

これを踏まえたうえで、見積もりを正確にするためには2つのアプローチが必要だと考えています。

(1)今見えている作業に対する見積もり精度を高くする。

   これは日々の訓練で初めて身につくと考えています。
   
   ・自作業を分類できる限界まで 細分化して、各項目を見積もる。
   ・見積もった結果と実際にかかった時間を比べる。
   ・これをとにかく続ける。
   
   これを毎日やるのは最初は結構つらいです。
   ですが、慣れればそれほど苦になりませんし、それなりに見積もり精度は上がってきます。

(2)見えていない作業をできるだけ減らす。

 問題はこちらです。
 ちなみに、ここでの見えていない作業とは 不具合や作り直し・手戻り、無駄な作業によるロスコストを発生させるものです。

 少しでも見えていない(=見積もり対象に入っていない)項目を減らすために必要なことは、
 できるだけ自分作業を細分化して、「ざっくり見積もりはこれだけ」ではなく、
「Aはこれだけ、Bはこれだけ、Cはこれだけ」というように自作業を極力小さく、
 イメージできる単位まで小さくすることだと思います。

 とは言うものの、現実問題として見えてない作業はやっぱり見積もりようがありません。

 なんかよい方法ってないものかとよく考えてはみるものの、妙案は思い浮かびません。

 …どっかにいい方法転がってないもんでしょうか…?

| | コメント (0) | トラックバック (0)

見積もりってよく外れます…というかまず当りません

新規開発や追加開発をする場合 見積もりをだすのはいつも苦労します。
私自身 バッチリと正確な見積もりをだせたことはほとんどありません。

昔 上長や先輩等に見積もりのコツを聞いたときには、「少しずつ見につけて行くものだ」などと 言われたものです。しかし、未だに「これだ!」という見積もり方法は見つかっていません。
また、上長や先輩方の運営するプロジェクトはいつも苦労していましたし、私のまわりのプロジェクトを見渡しても見積もりは外れることがほとんどです。ということで、実際のところ、正確な見積もり方法は誰も習得していないのかもしれません。

そんなこんなで私のまわりでは外れまくっている見積もりですが、そのわりにいつも絶対視されます。
「とにかく、この納期は死守しなければならない!!!だから休日出勤よろしく~」ってな感じで…

正確な見積もりを出せたからといって、そのプロジェクトが成功するとは限りませんが、
見積もりを少ない方向へ外すと非常に苦労するのは確かです。

じゃぁ、どうすりゃ 少しでも正確な見積もりをだせるのかってところが重要なんですが、
次に私なりの見積もりに対するアプローチを書きたいと思います。

長くなってきたので、続きは明日…

| | コメント (0) | トラックバック (0)

コピペコーディング

コードレビューや、不具合調査で人のコードをみるたびに思うんですが、コピーペーストのコーディングが非常に多くて見苦しいです。なんで、同じような記述を何度も繰り返しているのにルーチン化(関数化)しないんでしょうか?

似たような処理だからコピペして変数の部分だけ 変更すればいいという安直なコーディングはデメリットのほうが大きいです。

具体的には、次のようなルーチン化のメリットが失われます。

<ルーチン化のメリット>

  • 複雑さを減らせる

  ルーチン化の最大の意義は、プログラムの複雑さを減らすことができる点です。

  話題がやや飛躍しますが、与えられた課題からいきなり具体的なことを考えるのは不可能に近いです。
  ですから、与えられた課題の範囲を限定して考えること(細分化)により、そのときに設計を行っている範囲に無関係なことを考慮せず済むようにする必要があります。

  具体的には、関連する処理をルーチン化することで範囲を限定していきます。
  これにより十分細分化ができれば、各ルーチン内では考えることを減らすことができ、余計なことを考えなくてすむようにできます。

  自分でコーディングする場合、ルーチン化しなくても 細分化は可能ですが、
  他人のコードを見る場合、ルーチン化による細分化が行われていないと解析が非常に困難になります。

  • 変更漏れ

  改修が発生した場合に、修正する箇所が一箇所ですみます。

  これについては逆にルーチン化した箇所を改修するのは、そこが複数箇所から呼び出されているため怖い  (だからルーチン化したくない)という人がいます。
  これは甚だしい勘違いです。
  改修を実施する場合 その改修がどの範囲まで影響を及ぼすのかを考えるのが当たり前で、改修が必要箇所はすべて改修する必要があります。
  仮にルーチン化していない場合、改修漏れに気がつけない可能性が高くなります。
  さらに、コピペコーディングした箇所が枝分かれした日にはお手上げ状態になります。

  • 変更の及ぶ範囲を限定する

  変更される可能性のある部分をルーチンの中に分離することで変更の及ぶ範囲を限定します。

コーディングする人にとって コピペコーディングが楽であることは認めますが、後々のメンテナンスのことをもう少し考えてほしいものです。

| | コメント (2) | トラックバック (0)

日本のソフトウェアエンジニアは不幸か ?

IT起業家日記さんの2005年06月13日のエントリです。

私の考えは残念ながらYESです。

・ 業務改善をしない

・ 待遇が悪い

・ スキルアップ努力を評価しない

色々問題点を指摘されていますが、特に上位3点には激しく同意します。

・業務改善をしない

前回失敗したにもかかわらず 次回も同じ方法で開発すれば 同じような失敗するのは当たり前です。
なんで過去を分析して、問題点を改善しようとしないのでしょうか?
精神論でどうにかしようという人が多いですが、気合や精神論ではどうにもできないことになんで気づけないんでしょう?

・待遇が悪い

最近の小学生の将来就職したい職業ランキングの上位にプログラマが入っているらしいです。
いったいこの業界の惨状をどの程度の子供が認識しているのでしょう?

新婚旅行から帰ってきて空港から実験室に呼び出された人や、念願のマイホームを購入したはいいけれど単身赴任中で引越にも参加できない人とか、子供に顔を忘れられた人とか 身近にいますが…

労働時間が長くても給料が高けりゃまだ報われますが、みどりのおばさんにすら遠く及びません…

・スキルアップ努力を評価しない

評価しづらいというのもあるかもしれませんが、まったく評価されませんね。
スキルに差があろうとも給料は横並びなので 頑張れば頑張るほどに損をします。

…なんか、自分で書いていて暗くなってしまいましたので、このへんで止めておきます。

| | コメント (2) | トラックバック (0)

« 2005年10月 | トップページ | 2005年12月 »