ソフトウェア

高校生のなりたい職業の第3位にプログラマ

約3ヶ月かけたプロジェクトがそろそろ終盤に差し掛かってきました。
納期が近づくにつれ 仕事の負荷も上がってきており、最近 忙しくなりつつあります。
プロジェクトの進捗がやや遅れていることもあり 当初 今週末は休日出勤を予定していました。

ですが、結局 私を含めてチーム全員を休みにしました。

最近 残業&休日出勤が続いていたということもありますし、あんまり無茶を強いると エース格の派遣の人がプロジェクトから離脱する恐れもでてきますし、まぁ無茶はよくありません。
何より私自身が疲れているんで 休みたかったというのが一番大きいです.

仕事が遅れたからといって、世界がひっくり返るわけじゃありませんしね(^^;)

さて、前職での私の上司は 典型的な体育会系型SEでして、残業や休日出勤当たり前の人でした。何より辛かったのは同様の労働を部下にも要求してきたことです。
そんな上司にうんざりしたのが転職した大きな理由のひとつだったりするんですが…
そういう経緯もあって 残業しまくり 休日出勤しまくりで工程遅れを挽回するという手段はなるべくとりたくありません。

現実はなかなか うまく行かなくて休日出勤や残業せざるを得ないのが辛いところです。

ここを見ると高校生のなりたい職業の第3位にプログラマが入っています。
果たして 現実を知っている高校生はどれだけいるんでしょう。
彼らが就職するころには少しは状況が改善されているといいんですけど、まぁ 変わらないんでしょうねぇ…

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

プロジェクト運営は難しい

これはいつものことなんですが、やっぱり プロジェクトの運営って難しいです。
当初の見積もりどおりに うまいこと進めることに成功したプロジェクトにめぐりあったことは一度もありません。

私のチームの場合 納期に間に合わせるという点では、一応どうにかしています。
しかし 残業しまくり、デフォルト土曜日出勤 でどうにか帳尻を合わせているのが実情です。

原因はいくつかあるんですが、大きいところでは
私の引く工程にはマージンがほとんど入っていないのがまずいです。
わかっちゃいるんですが、工程にマージンをあらかじめ入れるのはなかなかできません。

その分 事前に発生し得る作業は工程をできるだけ細分化して、見えている工数に対する漏れはほぼないようにしているんですが…
しかしながら やっぱり 想定外の作業は発生します。

想定外の作業が平均○○%発生するというのがわかれば、それを工程にも盛り込めばすむんですが、あいにくそんな数値はありません。だから 工程に マージンをとりこむことはなかなかできません。
「この工数がマージンです」ってことが 上司にバレてしまうと ほぼ確実にその工数は削られます。

冷静に考えると、納期をずらさずかつ機能も削らず、さらに 残業や休日出勤以外で 想定外の作業に対応するためには やっぱり工程にある程度のマージンは必要です。

マージンに対して上司を説得できる根拠があればいいんですが、何かいい方法はないもんでしょうかねぇ…

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

システム開発費を値切る理由

悪態のプログラマさん経由ThinkITからの引用です。

 予算の関係で、開発会社から出された見積もりに対して値引きを交渉することもあるでしょう。値引き交渉についてはそれぞれ事情もあるでしょうから、是非について一概にはなんとも言えませんが、よく聞く話であり、実際に私も多く経験しているのが、発注側の企業体質として「見積額からいくら値引きさせたか」が、発注担当者の社内評価になるというものです。

 その値引きへの根拠もなく、とりあえず値引きしたかどうかを上司は尋ねます。こうなると、開発会社も値引きされることを前提に見積額を算出するようになります。「値引きありき」のような考え方はなるべく避けたほうがいいでしょう。思い当たる企業の方も多いのではないでしょうか。

そこそこ大きい会社だとよくある話ではないでしょうか。

私の場合は お客さんから あらかじめ 数%高めの見積もりをもってくるようにと言われてました。
例えば、わざと10%高めの見積もりを提出して、それを対面のお客さんが10%値引きするという形をとるわけです。こうすれば お客さんは「見積り額から10%値引きさせた」という実績を作れるし、こちら側としては初めから値引き分を考慮した見積もりを提出しているので痛くも痒くもないというわけです。

こんな手続きに意味があるのかいわれると 無意味なんですが…
その当時の上司からは何年も続いている慣習だと教えられました。

なくても困らないけど 決まりだからとりあえずやっとけってなノリですから、
まぁ相撲の儀式的動作みたいなもんでしょうね。

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

最近ソースを書いてない

私はソフト開発で チームの取りまとめ役(いわゆるリーダー役)を行う場合 ソースコードは書かないようにしています。
そのために 工程を作成するときは 自分へプログラマーの仕事を割り振りません。

自分にコードを割り振らない理由は大きく2つあります。
 1つ目:取りまとめ役はコードを書きつつ片手間でできるような作業量ではない
 2つ目:取りまとめ役のコード作成に進捗遅れが発生したときに 取りまとめ不在の自体を招く

私の経験上、プロジェクトが頓挫する場合 プロジェクトの取りまとめ役に問題があることが多いです。
取りまとめ役がいないため プログラマが仕方なしに取りまとめを兼任するとか、逆に 人が足りないために取りまとめ役が プログラマとして担当ソースを持ってしまうとかいうパターンがやばいですね。

プログラマは普通 自担当箇所の進捗が遅れると 自分の進捗遅れ挽回に集中します。
1プログラマが進捗遅れ挽回のために自作業に集中するのは一向に構わないんですが、取りまとめ役が自作業のみに集中すると チームが動かなくなります。他のチーム員に進捗遅れが発生したような場合に 手を打てなくなりますし、進捗遅れで危機的な状況にあるという上長への状況報告も止まりがちになります。

そんなわけで 最近は ソースコードを書いてません。
どーせコーディングはしないだろうと考えて デバッガもアンインストールしてしまいました。

でも、取りまとめをやって 人を動かすよりは ソースコードを組んでるほうが楽しいんですよね。
ソースコード書くの好きですし。
仕事を効率よく進める(というか チームをうまく動かす)ためにソースコードを書かないように心がけているものの、できれば プログラマもやりたいという ジレンマを抱える今日この頃です。 

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

言い訳から信頼は生まれない

「Life is beautiful」の「リーダーシップについて思い出したこと」というエントリからです。

------------------
プロジェクトの責任者の仕事は、「プロジェクトの成功に必要な作業の手配をする」だけでは終わらず、それらの作業が確実に実行されるようにして結果を出してこそ初めて評価されるものだ、そしてうまく行かないことがあっても決して他人のせいにしてはいけない、という認識である。
------------------
人間、「何としてでも結果を残す、言い訳は絶対しない」という意気込みを持って仕事をすると、ものすごく強くなれる。
------------------

私は 仕事での言い訳は極力しないように心掛けています。
ですが、ソフトウェア開発で ミスや工程遅れ等 問題が発生したときに、「駄目だなー」って人ほど よく言い訳をします。当人は言い訳することで頑張って自分を正当化してるつもりなんでしょうが、ぶっちゃけ見苦しいです。

同じ失敗を繰り返さないために なぜミスしたのか、なぜ工程遅れが発生したのか その原因を突き詰めることは必要です。ですから 私は問題が発生した場合は必ず「何故?」と聞きます。でも私が聞きたいのはあくまでも問題点の原因です。しかし、「駄目」な人は 問題点の理由ではなく 自分が悪くない理由を必死に説明しようとします。

まぁ、言い訳が必要な場合があるのは認めますが、まず 言い訳ありき な人は信用できません。とにかく自己正当化して「自分は悪くないんだ」と言いたい気持ちはわからないでもないですが、その行動は何も生み出しませんし むしろ不信感を募らせます。

重要なことは 上記の引用にもあるように「言い訳をしない」ことを心がけることだと考えます。
「言い訳をしない」ことを心がけると、許してもらえなくなりますので 必然的に仕事をどうやってうまく進めるかを真剣に考えるようになります。するとそこで責任感が生まれてくるんではないでしょうか。

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

バグの水平展開

バグがでた場合 当然改修しなければいけませんが 作業フェーズによって その作業量は大きく変わります。

例えば コーディングフェーズでは 問題箇所を修正してデバッグするだけですので 短時間でOKです。
しかし 出荷した製品でバグが出た場合は もう大変です。
製品のパッケージングやらレビューやらデグレード試験等 様々な作業が発生します。

そんなこんなで製品にバグがでると色々としなければならない作業があるのですが、中でもプログラマにとって面倒作業の一つが「バグの水平展開」です。

「バグの水平展開」とは 似たようなバグが他に潜んでいないか探して対策することを指しますが、これが非常にやっかいな作業です。

例えば セマフォ開放漏れがバグの原因であった場合、セマフォの獲得/開放を行っている場所を全部チェックしなければいけませんし、メモリリークがあった場合、メモリの獲得/開放箇所を片っ端からチェックしなけりゃいけません。

しかし、セマフォの獲得/開放関数や、メモリの獲得/開放関数はバンバン使用しますので、検索してチェックすると言ってもその量が半端ではありません。ましてやプロジェクト全体に対するチェックをしますので とにかく時間がかかります。

そんなわけで できることなら避けたい作業なんですが 今回は私が対応せざるを得なくなっちゃいました。
というわけで 今日は一日中 セマフォの獲得・開放まわりをひたすらチェックしていたんですが…
単調作業なくせに量が多いし、限界です。

だれかに代わってほしいんですが、代わりになる人がいません。

もう 勘弁してください(TT)

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

コードレビューとプログラマのプライド

今日はベテランプログラマのコードレビューをやったんですが、プログラマをちょっと怒らせてしまいました。
1関数が長すぎるんで 分割してほしいと言ったんですが、これが彼のプライドを傷つけちゃったみたいです。

でも レビューしたソースは、1関数が300行ぐらいと長く、さらにifやらforやらのインデントが7、8段ぐらいまで深くなっており、かなり見辛くなっていました。ちなみに改修前は50行ぐらいで インデントも3段ぐらいです。(C言語です。)

わからない人にはさっぱりわからないと思いますが、私のコードに対する美的感覚からは耐えられませんでした。

そんなわけで、今回 彼は「仕様」がわけわからんと憤慨していたわけですが、
プログラマのプライドを傷つけないようにソースコードの修正依頼をだすのは難しいです。
今回の件に関すれば、私はソースコードの構造が見にくいといっただけで、仕様を変えろとは言ってないんですが…

プログラマって、どんな形であれ ソースコードを否定されると 自分を否定されたような錯覚を持ってしまいますので、細心の注意がいるなぁと改めて考えさせられました。

なんにせよ、コードレビューは難しいです。

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

フローチャートは嫌い

私はフローチャートが嫌いなんですが、その理由がなかなか人にうまく説明できません。というわけで WEB等を調べつつ、自分の考えも混ぜて フローチャートの問題点をまとめてみました。

まず、フローチャートは、アルゴリズムやプログラムを分かりやすくするための図です。
これがよく使われる理由は、とにかく「書きやすい」点につきます。
これがフローチャートの最大の長所ですね。

そして、プログラムやアルゴリズムが さらに見やすくなります。
まぁ、この長所は対象プログラム アルゴリズムが簡単な場合限定ですが。

…長所はこれだけです。

次に欠点を並べていきます。

欠点1:細分化が苦手

ソフトウェア設計で重要なことは、複雑なものを如何に簡単にわかりやすくできるかという点です。ここを重要視することで 設計フェーズで作りこむバグを減らすことができます。

簡単化を行ううえでの 基本的な作業が機能の細分化です。
巨大な処理や複雑な処理を一気に考えるのは難しいので 小さい単位に分割して 小さい単位ごとに検討するようにします。

たとえばC言語の場合、複雑な処理を簡単に表現するために、ある程度まとまりのある部分をまとめること(関数化)を行います。これを繰り返すこと、つまり「複雑→細分化」はプログラムを作成する上で基本です。

しかし、フローチャートはまとまりや関連のある処理群をまとめること すなわち細分化が苦手です。複雑なものを複雑なまま表現できてしまいますので、特に新人等プログラム初心者にフローを書かせるととんでもなくわけのわからないものを書いてしまったりします。

欠点2:読みにくい

フローチャートを読もうと思うと 先頭から順に追っていかなければいけません。
また、全体的に何をしているのか?というのが非常に把握しにくい性質も持っています。

長いフローチャートになるともうお手上げです。

欠点3:同じものを異なる書き方で書ける

これは自由度が高いための欠点なんですが 同じアルゴリズムでもぜんぜん異なる書き方ができてしまいます。人によって同じものが異なる表現になるということは 本来のフローチャートの目的がプログラムやアルゴリズムをわかりやすくすることであるにもかかわらず、かえって わかりにくくしてしまうということです。

フローチャートはこの性質のため、メイン処理や正常系処理 を把握するのが難しい という欠点を持ちます。(たとえば分岐を含んだフローの場合、どの処理が正常系で、どの処理が異常系なのか等)

欠点4:メンテナンス性が悪い

これは言うまでもありません。
ソースコードを修正した場合に、ドキュメントまで修正するのはたいへんです。
その結果、ドキュメントが修正されなくなり、いつの間にか実際のソースコードと乖離した役に立たないドキュメントが生まれてしまいます。

まとめ:

フローチャートを書く最大の目的は、プログラムやアルゴリズムを図にすることでわかりやすくすることです。複雑なものを簡単に表現したいというのが、フローチャートを表現する目的であるはずです。

であるにもかかわらず、複雑なものを複雑なまま表現してしまう、要するに 複雑なものがわかりにくいという短所をフローチャートは持っています。

つまり、複雑なものを簡単にするのがフローチャートの目的であるにもかかわらず、複雑になればなるほどわかりにくくなるというフローチャートの性質は 本来の目的とは逆の性質を持っています。

そんなわけで、私はフローチャートが嫌いです。

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

プログラマではなくテスターとして現場デビューする

プログラマではなくテスターとして現場デビューさせるのは、私のまわりではよくやる新人の立ち上げ手法です。

「設計者の発言」さんにも書かれていますが、メリットは 色々あります。
まず 自分の開発する装置についてよく知ることができます。
さらには単体試験せずに総合試験(組み合わせ試験)にプログラムをまわしてしまうととんでもないことになるということを身をもって知ることができます。まぁ、これは試験対象プログラムの品質がひどい場合限定の話ですが…
また 新人の教育担当の立場では 新人の教育に割く時間を(コーディング等開発側にまわすのに比べると)小さくできます。

ということで、新人をまずテスターにすることは いい考えだと思いますし 否定する気はさらさらありません。

ただ、注意しないといけない点があります。
いつまでもテスターをさせっぱなしにしてはいけないということです。

実際にあった話なんですが、数年テスターばっかりやって、一度も開発をせずに管理職にまわされた後輩がいました。その後輩は少しは開発をさせてほしいと上司に訴えたみたいなんですが「自分で勉強するもんだ」と突き放されてしまったみたいです。ちなみにその子は管理職にまわって2年後ぐらいノイローゼ気味になり 会社を辞めてしまいました。

さらに これは人から聞いた話なんですが、新人にはまず3~4年程テスターをさせるのが伝統ってな会社があったそうです。
んで、その会社は数年前に20台中盤の若い世代が大量に退職しちゃってえらいことになったらしいです。
その会社では そんな事態になってようやく 自分たちの伝統が如何にアホであるか に気づけたそうな…

というわけで、新人をプログラマではなくテスターとして現場デビューさせるのは大いに結構です。でも、期限は最長でも1年ぐらいにして、そのあとちゃんと「プログラミング」側に移してあげることを忘れてはいけません。

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

見積もり手法「KKD法」

これまでの見積もり手法 紹介の続きです。('08/3/4修正)

・見積もり手法「KKD法」

もっとも広く(?)普及している見積もり手法です。というか、こんなもの手法ではありません。「エンジニアの経験と勘に頼った見積もりのことを KKDと呼ぶ」というのが正しいです。

KKDとは、K(勘)、K(経験)、D(度胸)のそれぞれの頭文字をとっています。根性(K)根性(K)ど根性(D)の略でもないし、火事場(K)のくそ(K)力(D)の略でもありませんのであしからず。

KKDの長所は 短時間で算出できること。いわゆる「エイヤー」でだす見積もりですので そりゃまぁ算出は早いです。
また、熟練した技術者のだした見積もりはKKDであっても、説得力があるというのも長所です。(これが実際に当たるかどうかは また別問題ですが...)

欠点は 見積もり結果そのものが 見積もり担当者の主観とスキルに依存するため、精度が人によってまちまちになることです。ようするに 信頼性が低く、よく外れます。

また、主観に依存した見積もりなので、「いったい何に基づいて算出されたのか」という 見積もりの根拠が非常に薄いことも欠点です。見積もりが外れた場合に、その失敗を 次回に生かしたくても、そもそもの見積もり根拠が薄いため 生かしようがありません。このため、失敗を次回に生かすという、改善を行いにくいという欠点も持っています。

ということで、個人的には 非常にまずい手法だと思うんですが、残念ながら世間では 一番信頼されている見積もり手法です。

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