で、いままでは割りと影響が少ないチームで仕事していたのですが
4月から状況が変化して政治を意識しないといけなくなったので最近モヤモヤ中。

何かアクションを起こすとネゴや承認が必要になるのでいままでのスピード感と違う。
そうするとチーム内に手空きの時間や人ができてしまうので今月はいまいちでした。

こいったモノ（ネゴや承認）って儀式的なものもあるのだけれど信頼感の部分も割りとあるので
チーム外とのコミュニケーション増やして早めに信頼を得ないといつまでも抜け出せなくなってしまう。

まあなんとかなるだろうと思っている今日この頃。近況報告でした。

ここ１ヶ月、打ち合わせだとか打ち合わせだとか打ち合わせだとかでコーディングの時間があまりなかったのだけれどここまでひどいとはショックorz…

全くプログラミングをしていなかった訳では無いしレビュアーとしてコードレビューもそれなりにしてたんだけどなー。

月に何本かはまとまった量のコーディングをしないと腕が鈍りますね。
※普段もそこまで綺麗なソースではないですけど^^;

皆さんも気をつけましょう。

• Spreadsheet_Excel_Reader
• Excel_Peruser

どちらも使い方は簡単だったのですが、Excelファイルによっては読み込めない場合があり安定性がいまひとつでした。

他に方法はないかと考えたらサーバにPerl入ってるしPerlで組んでも問題ないだろうと判断。
探してみたらあっさりCPANにありました。
Spreadsheet::ParseExcel

こっちも利用はいたって簡単。更に読み込みたいファイルも無事に読み込めました。

■Excelファイル(Excel 2002)

■結果

0  0:a 1:b
1  0:123 1:456
2  0:感じ 1:カタカナ
3  0: 1:ﾊﾝｶｸ

■ソース

#!/usr/bin/perl

use strict;
use warnings;

use Spreadsheet::ParseExcel;
use Spreadsheet::ParseExcel::FmtJapan;

my $format = new Spreadsheet::ParseExcel::FmtJapan->new(Code => 'sjis');
my $excel = new Spreadsheet::ParseExcel;
my $book = $excel->Parse("test.xls", $format);

my $sheet = $book->{"Worksheet"}[0];

my $maxRow = $sheet->{"MaxRow"};
my $maxCol = $sheet->{"MaxCol"};

for(my $row=0; $row<=$maxRow; $row++) {
    print $row."  ";
    for(my $col=0; $col<=$maxCol; $col++) {
        my $cell = $sheet->{"Cells"}[$row][$col];
        my $val = "";
        if ($cell) {
            $val = $cell->Value;
        }
        print "$col:$val ";
    }
    print "\n";
}

※CPANからのインストールは割愛

これができるとExcelファイルを設定ファイルの変わりにできたり、設定ファイルを自動生成できるので便利です。
設定ファイルと設計書を２重持ちしている現場で楽になったりします。

ブレストで大事なのは意見の量なのだけれども、なかなか発言してくれない。
これはおかしな発言をする事に対する恐れがあるのだと思う。
別で担当しているチームでは発言の量が増えて来ているのでやっぱり慣れてきな部分があるのだと思う。

打合せの場をもっと発言し易い様にする工夫と各メンバーが慣れることによって解決可っぽい。

そして次の問題が結構大きい。それは自分。
いまのところファシリテーターは自分がしているのだけれど、いけていない部分が多々ある。

1. 自分の思っているところへ扇動してしまっている
2. チームリーダなので発言が影響してしまう
3. 非現実的な意見に対して否定的（口には出さないけど顔にでる）

どれもこれもブレストの天敵！

ファシリテーター役を誰かに譲りたいなー。適任者がなー。心配性すぎるのかなー。

やっぱりアイディアを広げるところは他の人に任せて収束させる部分を担当する事にしよう。
上手くいくか心配だけどとりあえずやってみよう。

下記はブレストをよく知らない人向け

ブレインストーミング – Wikipedia

ブレインストーミングとは、自由に意見を出し合い、あるテーマに関する多様な意見を抽出する技法のことである。質より量を重視し、お互いの意見に批判をせず、自由に意見を出し合うことで、周辺知識を列挙することができる。

ブレストと言えばIDEO！
発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法

これは中小企業のソフトハウスが前提なのだけれどソフト会社といっても実態はほぼ人材派遣である。

私が勤めている会社もほとんど派遣で一部社内で一括請負をしている。
そんな中で派遣されている社員が組織の為に利益を求めるのはとんでもなくしんどい。

まず派遣で行く場合、１ヶ月いくらの世界でありその時の交渉で金額が決まる。
派遣先でスキルを見せても単価が上がることはあまりない。
上がったとしてもわずか１人月の10%程度の話でありそれは組織全体から見てもほんのわずかである。

結局は人月単価で作業している限りSEやPGの利益は一人分に毛が生えた程度である。

一括請負の場合でもソフトハウスで請負える範囲であればそれほど差が無い。
例えば30人月の仕事を5人で6ヶ月行えば派遣と差はない。
これを4人で6ヶ月行ったと想定する。

１人月、70万と仮に設定すると顧客から支払われる金額は30人月×70万＝2100万
１人あたりのコストを60万で計算すると4人×6ヶ月×60万＝1440万。
利益は2100万－1440万＝660万である。
これを一人当たりの利益にすると660万÷（4人×6ヶ月）＝27.5万である。
１人月の費用が60万かどうかは考えるところであるがこの金額は少なすぎる。

更に一括請負はリスクが高くこの利益では受ける事はできないだろう。

これを考えるとソフトハウスが30代以上にマネージメントを勧める理由が分かる。
マネージメントであれば自社の人間ではない費用が安い人員を使う事ができる。

一人当たりの費用が下がれば当然利益は上がる。
なのでソフトハウスの経営陣はマネージメントできる人材を求めるのであろう。

また別に利益を求める方法として、SEやPGをプロジェクトに入れ次のシステム開発にお呼びがかかる事を期待する方法もある。

今まで勤めてきたソフトハウスは大体こんな感じだ。

マネージメントで差額から利益を求めたり、次の発注を見込んでプロジェクトに参画するなどして利益を得る（若しくは見込む）のは分かるのだけれど
それってソフトウェアを作るって部分には関係が無い。

そこで問題なのだけれど顧客の問題を解決したり素晴らしいプログラムを作ってもソフトハウスの利益には直結しない。
利益がでる仕組みはそれとは無縁の部分なのだ。

悲観的な部分や数値に根拠が無い部分もあるけれど、SEやPGが利益を求めるのが難しいと考えさせられる。

タイトルには方法と書いているが全くその方法は分からない。
「ソフトハウスがソフトを作って利益を得る」って当たり前に聞こえるがどれだけの会社が実践できているのだろうか？
SEやPGがソフトを作ることで利益を得る方法を知っている方は教えて下さい。

マナーを欠いた社員は少数でほとんどの社員は守っていたのに。
マナーを欠いた社員に厳しく注意を行えば済む事なのに守っている社員にまで規則を強いる。

規則になると監視されているみたいでモチベーションが下がる。
規則を設けないとダメな社員が多いみたいで悲しい。

ほんとにその規則作って会社の価値はあがるのですか？
できるだけマナーのレベルで抑えれるとみんな嬉しいと思うのに。

ちょっと考えたんですけど一般的にはソフトハウスってどのような点で社員を評価しているのでしょう？

うちの会社では目標立てて達成率と過程で評価しています。でもそれって会社として嬉しいのでしょうか？
立てられた目標は会社の目標と一致しているのでしょうか？

まあソフトハウスで目標が社員に認知されてるケースってほとんどない気はしますが^^;

個人の為の目標って、個人の為であって会社の為ではありませんよね。
その目標を達成したら会社（組織）の価値は上がるのでしょうか？
個人の価値が上がれば会社の価値も上がるのかもしれませんが、それはその人が辞めた場合にそのまま価値が減ることになるのでリスクまで上がっています。

実績、過程のどちらで評価しても良いと思いますが、まずは目標の明確化・認知から先にした方が良いと思います。
で、うちの会社（組織）の目標ってなんだろう^^;？

■レビュアーが気をつける事

１．解決方法は１つだけではない
レビューする前に仕様が判っている事がほとんど。
そうするとレビュアーはコード見る前に自分の中で勝手にコードを予想してしまう。
これがあまり良くない。自分の予想と違うとついつい誘導したくなる。そこはぐっと我慢。
レビュアーの予想が正しいとは限らない。

２．断定せずに質問を投げかけるようにする
なぜその様にコードを書いたのか理由を聞く様にする。
その際「なぜ？」の使い方を気をつける。レビューを受ける人は責められている様に感じてしまう。

３．褒める
褒めなれてないと難しい。慣れてないと照れくさい。
でもこれができないと良い点がシェアできないのでがんばる。

４．議論の対象はあくまでもコード
これは耳タコ。でも難しい。
問題はコードにあり開発者ではない。わかってるんだけどね。
最近は上手くいっているかも。

５．間違い探し
スペルミスやコーディング規約に沿っていない（軽い逸脱）ぐらいなら許す。
そんなことをコードレビューで指摘するのは勿体無い。もっと見るべき点がある。

６．誰が優れたプログラマーかコンテスト
気をつけないとほんとに陥り易い。自分の自慢は呑み会にでもとっておく。
コードレビューには必要ではない。

途中まで優先度順に書いてみたんだけど見直したら順番付けられなくなった。
どれも重要でどれも難しい。

これが３分の１でもできるとチーム内でのコードレビューに対する評価が変わってきます。
進んでコードレビューを依頼してきたり、メンドクサイって空気が薄れます。（まだちょっと思ってしまうけど:p）
どれも充分では無いので改善してがんばる！

今でこの効果なのできちんとできたときの効果は計り知れないね。きっと！

確かに今やっているシステムはそんなに大きな
システムではありません。

でもちゃんとデグレしてるよ。orz

Subversion使いたいってわがまま言いません。
CVSでもいいです。なんならVSSでもかまいません。

おねがいだからソース管理ツール入れさせて下さい！
共通のソース触るたんびにIM使ってメッセージ送るの嫌だ！

チェックアウトめんどくさかったらTortoiseSVN使えばいいじゃん。
でも、コミットはしてね。

誰か古参の開発者を説得する術を教えて下さい。

コーディング規約に違反している訳ではないのだがどうも気持ち悪い。
何かと言うとやたらgetXXXXって関数（メソッド）が多い。

作成者に尋ねたら「だって値取得するじゃないですか」って答える。
うーん。それだと値を返却する関数は全部getってついちゃうじゃん。

で、全体のソースを眺めると概ね次のようにわかれる。
・getHogeHoge()
・makeHogeHoge()
・buildHogeHoge()

うーん、一般的にありそうな関数（メソッド）名だ。
一見すると問題ないが、それぞれどんな処理内容の時に
「get」「make」「build」を使うかはっきりしていない。

プログラムを組んでいる人に依存しているし、
それぞれに聞いてみたら明確な判断基準はなくて感覚論の様だ。

そして私もはっきり説明できなので、感覚論^^;。

オブジェクト指向でクラスなどなら、getについてプロパティから取得する時、
などと説明できるかもしれないが、構造化プログラムではどうだろう？
更にどちらでもかまわないが、idに対して名称を取得する場合など、
「getHogeHogeName(id)」としても違和感は感じない。

それぞれ辞書(goo.ne.jp)で引くと

get

得る, 取る, 手に入れる

make

作る, 製造する, 建設する

build

建てる, 造る

getは、はっきり違うのがわかる。
makeとbuildは微妙～

ますます区別が付かなくなった。これは個人個人で認識違うのも仕方がない気がしてきた。

皆様はどのようにget、make、buildを使い分けていますか。

引数があったらなかったらとか、中で加工するとかしないとか、
引数だけで値を生成できるとかできないとか、なんでもよいので教えて下さい。

たぶんメソッド名（オブジェクト指向）と関数名（構造化プログラム）でも
違ってきそう。