最小構成の組織について

景気の良くないニュースばかり聞こえてくるこの頃でございますが、皆様如何お過ごしでございましょうか。ご多分に漏れずそういうキーワードがあちらこちらから耳に入ってくるわけです。
不景気なキーワードと言えば思い出すのが、最初の職場で私を仕込んでくれた師匠のうちのお一方が吐いた台詞。

電気消すより役に立たんオヤジの一人でも消した方が、よっぽど効果あるわ。

誠にごもっとも。諸手を挙げて賛成です。
が、往々にして、そう言われる人々は「既得権」の安全圏に居るわけで、標的にされるのは現場の下々と相場は決まっています。
ここで腕に確かな覚えと、十分な預金残高があれば威勢の良い啖呵が切れると言うものです(備えあれば憂いなし!)
ですが、問題はその後-残される側の話。
F.Brooks の法則(というか呪い?)が指摘するとおり、人の教育にはリソースが必要で、その期間中は生産性がマイナス方向に変化する訳です。この事を頭に入れた上で、次の状況を考えてみます。
1)組織を「最小構成」にまでリストラする
  つまり、全員が100%近い稼働率でなんとか仕事を回せる状態にまで人を減らす。
2)「余計な出費」、特に残業代・外注費は罷り成らんというお達しが、「その筋」より発せられる。
3)この状態で、何かのプラス方向の変化、つまり仕事が増える方向の変化が発生する。
  例えば、営業部門が必死の努力で新ネタを拾ってきた。
さて、この状態。経験のある現場担当者なら背筋に冷たい物が走る-走って然るべき状況です。
既に稼働率は100%近く。外だしも要員補充も罷り成らんどころか、そのためのオーバーヘッドすら吸収する余地がない。つまり、要員構成としては「手詰まり」な状況です。
これでマネージャーに何をしろと??
ここで、現場マネージャーが打てる手は…
無償の残業(サービス残業、或いは「パケ放題」な管理職を残業させる)により、なんとか仕事をこなすぐらいです。
前者は士気を完膚無きまでに地に落とし(そして訴訟リスクを背負い)、後者は組織としての『学習』が無いままに-つまり組織としての未来を得ること無しに-それぞれ前に進むだけです。そして、彼らが燃え尽きて去っていった後には、ペンペン草一つ生えない、不毛の荒野が残るだけ。
確かに、明日のビフテキより今日の掛蕎麦。それは否定する気はありません。しかし、一所懸命働いているスタッフに夢の一つも見せられない、「今日のメシが食えるだけシアワセと思え」な職場。首切りが怖くて残っているヤツばかりの職場(=腕に覚えのあるヤツはさっさと自分の意志で去っていく)
それってどうなのよ、そんな組織で本当にいいの??と言いたくなる今日この頃だったりします。

悪魔の代理人としての現場管理者

部下に対しての話じゃなくて、上司に対しての話。
いつものように上司にお白州に呼び出されて、プロジェクトに現状を言上するわけです。
その時心がけていること。
耳障りの悪いことを敢えて言うこと
つまり
・耳障りの良いことばかり言うヤツは要らない
順風満帆万事順調、そんなオメデタイ仕事なんぞある訳がないので、どこかにリスク要因があり、どこかに問題があるはずです。
それを見つけ出してアラートをあげるのも、現場管理者の重要な仕事のはずです。
で、そういう情報は上層部としては耳障りが良かろうはずがなく、
従って、最後は「なんでおまえは物事に対してそう悲観的なんだ!」仕舞いには「要するにやる気がないんだろ!」とか、そういうコトを言われる場合もあるでしょう。
が、毎回「順調です」と報告しておいて、突然(いつものように)大炎上が始まるのと、どちらがあるべき姿かという議論はするまでもないでしょう。
なので、現場管理者は上司に対して悪魔の代理人のように、悪い報告の方を重点的にあげる必要があると思うわけです。
で、上司がそういう報告に耳を貸さない、する度に(上記の例のように)怒鳴りつけられるとあれば、それは履歴書をアップデートするべき時でしょう。
但し、『ものには言い方ってもんがある』ことを心がけておく必要はあります。

【小ネタ】優先度で知る他所の組織

同じ組織(例:同じお客さん)の違う担当者から
「最優先でやってください」
「ほかの作業止めてでもやってください」
が競合するとき、その組織は Out of control です-きっと。
そして、その「最優先」のために他のコトが遅れたことを責められるならば、その組織は相当にやばいでしょう-きっと。
理由:組織プレーにおいて「右手がやっていることを左手が知らない」という状況は、一番あってはいけないこと。むしろ、それは組織プレーではない。11人の烏合の衆が集まった玉蹴りゲームをサッカーとは呼ばない。

Shared のメンバ変数を公開しないこと

先日、こんなソースを見かけまして。

[VB.NET]
Public Class Hoge
 Public Shared fugafuga as String
 ’…以下略

思わず寒気を感じた訳です。Shared変数は「そのような変数を Shared で宣言した場合、すべてのインスタンスがストレージ内の同じ場所にアクセスするため、あるインスタンスが変数の値を変更すると、すべてのインスタンスが変更後の値にアクセスするようになります。」[出典:MSDN ライブラリ- Shared(Visual Basic)] なので、昔のグローバル変数なみに訳の判らないことになる恐れがあるのです。
例えばこんなコード(及び改善例)

[VB.NET]
Module Module1
  Sub Main()
    ‘—ダメな方のHogeの例
    
    Dim objHoge1 As New HorrorHoge
    objHoge1.mstrHoge = “Instance”‘—←コンパイラが警告を出します
    HorrorHoge.mstrHoge = “DirectHoge”
    Console.WriteLine(“Via Instance”)
    objHoge1.PrintHoge()‘—←コンパイラが警告を出します
    HorrorHoge.mstrHoge = “DirectHoge”
    Console.WriteLine(“DirectHoge”)
    HorrorHoge.PrintHoge()
    Console.WriteLine(“Hit any key…”)
    Console.ReadKey()
    ‘—マシなほうのHoge
    Dim objBetterHoge1 As New BetterHoge
    objBetterHoge1.Hoge = “hoge”
    Dim objBetterHoge2 As New BetterHoge
    objBetterHoge2.Hoge = “fuga”
    Console.WriteLine(“Better Hoge1″)
    objBetterHoge1.PrintHoge()
    Console.WriteLine(“Better Hog2″)
    objBetterHoge2.PrintHoge()
    Console.WriteLine(“Hit any key…”)
    Console.ReadKey()
  End Sub
End Module
‘ダメな方のHoge
Public Class HorrorHoge
  ‘Sharedなメンバ変数をPublicで公開します
  Public Shared mstrHoge As String
  Public Shared Sub PrintHoge()
    Console.WriteLine(“mstrHoge=” & mstrHoge)
  End Sub
End Class
‘マシな方のHoge
Public Class BetterHoge
  ‘とりあえずPropertyにしておきます
  Private mstrHoge As String
  Public Property Hoge() As String
    Set(ByVal value As String)
      mstrHoge = value
    End Set
    Get
      Return mstrHoge
    End Get
  End Property
  Public Sub PrintHoge()
    Console.WriteLine(mstrHoge)
  End Sub
End Class

で、実行結果は…

Via Instance
mstrHoge=DirectHoge
DirectHoge
mstrHoge=DirectHoge
Hit any key…
Better Hoge1
hoge
Better Hog2
fuga
Hit any key…

…ダメな方の
objHoge1.mstrHoge = “Instance”
は、ビット列の彼方に消え去っていきました。
そんな訳で、Sharedのメンバ変数には十分に気をつけましょうというお話でした。
で、問題のそのクラス、全てのメソッドがSharedで宣言されていたのですが、全てのメソッドがSharedなら、何故メンバ変数を公開する必要があるの??等など、疑問の尽きないコードでありました。

オフショアプロジェクトについての雑感

今更ながらオフショアネタです。数回オフショアプロジェクトとかかわりを持ったのですが、ソコからの雑感。
まず、なんでオフショアなの?という動機が不純(?)なモノは、必ず失敗するでしょう。
日本と同じ品質を、同じ期間で、しかも安い費用で、今すぐに。
そんな都合のいい話があれば、とっくに誰もが飛びついているでしょう。世の中そんなに甘くはありません。
費用が安い分だけ、品質や期間を我慢する、レスポンスの悪さを我慢する。そういう良い意味での割りきりが無いと、双方が不幸になるだけで終わってしまいます。
そして、オフショア側を「育てる」ことも必要になります。日本で国内の外注先を「育てる」のと比べて、何倍もの時間が必要になります。たとえオフショア側が日系企業であっても自社の子会社であっても同じこと。
また、(いつものように)プロジェクトが上手くいかない時、それは何故なのかというのを、キチンと冷静に判断して次に生かすという視点がないと、人は安易な結論に飛びつきたがるので、全ての原因が「オフショアに出したせい」になりかねません-日本でも普通に起きる事象に対してさえも-。
そうやって、上手く行きかけのモノさえも潰してしまったオフショアプロジェクト-そう言うのをよく見かける訳です。

商用でコレは無いだろう…

元ネタ:「ヘッダコメントを使おう
とある商用ライブラリをオシゴトで使っている訳です。
そのリファレンスがイマドキPDFというイケて無さを感じながら使ってみました。先ず不穏な雰囲気を感じたのはVisual Studio から参照設定を設定した時。
バージョン番号が”0.0.0″と表示されまして。
えぇっ!!なにそれ??
で、ガシガシと書いていく訳ですが、インテリセンスの表示を見て愕然…

なにこれっ!
このぞんざいなパラメータ名、ヘッダコメント皆無…
商用でこれは酷くね??
思わず担当営業を呼び出してクレーム入れようかと思うほどでした。
と、言う訳で、パラメータ名、ヘッダコメントはきちんと入れましょうというオハナシでした。

相手のことも考えよう

自分の都合だけじゃなくって、人様のご都合ってのも…
ってな説教をしたい訳ではありません。むしろネタ。
今日、某所(離れた所)から送られてきたメールで、リモート接続に関するオシラセがありました。

・テストサーバ(192.168.0.***) への接続には、Administratorを使用しないでください。
・テストクライアント(192.168.0.***~***) への接続はアカウント”***”を使用してください。それぞれ3接続しかありません。
以下略…

思わず噴いちゃいました。
どうやったらローカルアドレスで接続できるのかと。
VPNでもつながってれば解らなくはないですが、そんなゴタイソウなものはありません。
つまり、「自分から見たアドレス」と「ワタクシから見たアドレス」は違うんですが、メールを書く時に普段自分が使っているアドレスのことしか考えなかったんだろうなと。
ま、そうやって基本を忘れた結果としてこういう顛末にならないことを祈ります。

予備リソースを用意すること

スケジュールを組む時、もてるリソースを全て動員し、時にはマネージャー自身までそれに入れてスケジュールを組むのが普通です。余っているリソースがあれば、監査担当(たいていは顧客や上司)から「なんだこれは!」と激しい突っ込みを喰らうのも、これまた普通です。
しかし、あえて特定のモノにアサインしない「予備」を用意しておくべきです-それは決してマネージャー自身ではない「誰か」です。
実装であれば、最も経験のあるプログラマ-要するに、最も使える、頼りになる人を「予備」として脇によけておくのです。
例えば、実装で遅れが出た場合、タダでさえカツカツのスケジュールに対して遅れている訳なので、リカバリには通常の何倍もの生産性が必要な訳です。確かにスケジュールを引く時の「定石」としてバッファを取ってあるわけですが、ヤバイ時というのは、そのバッファすら食いつぶしているのが普通です。したがって、最も「仕事が早くて確かな(手戻りの少ない)」人を持ってリカバリに当たらなければいけません。そのリカバリに当たる人さえ、初手からイッパイイッパイだったら?打つ手がありません。
そう言うわけで、プロジェクトには「予備」-聞こえが悪ければ「遊撃」-を用意しておくべきなのです。普段は他のメンバーのサポートや調査その他モロモロ、一見すると「何もしてねぇんじゃね?」的な場所に下がっていながら、いざとなると力一杯火を消しに掛かる-そんなリソースを用意しておくべきなのです。
そして、それが「予備」であることを監査担当にわからせないように、突っ込ませないようにする-それもマネージャーの仕事のうちです。

なぜ私が非公式の進捗報告をしないようにしたのか

管理する側の人間が非公式に(つまり、公式ルート以外で)進捗なり何なりについて聞いてくるというのは、大体においてロクな兆候ではありません。例えば…

・公式ルート経由での報告が信用できない
・そのまた上司や顧客に聞かれたから、トコロテン方式で質問がまわってきた
・他の人間にも同じ質問を投げて、反応を見比べている

…とかとか
そして、悪いことに、この手の「非公式の」報告というヤツは、非公式なだけに「噂」レベルの流通となり、いつの間にやらあちらこちらに流出して尾びれ背びれが付くものと、相場が決まってます。
さらに、この手の噂が広まったが最後、それをどうこうするのには、大変な労力を必要とします。そういうややこしい事態にしないためには、初手からそんな情報を流さないに限ります。
ただし、非公式報告の全てが悪いという気はありません。
例えば隣の席の同僚と「どう?」なんて会話をする場合とか。
これすらためらわれるような状況であれば、そんな心配をしなくても、そのプロジェクトは既に死んでます。

喰えねぇなら出すんじゃねぇ

レストランとかの話をしている時に、「あそこの主人、自分で食べて無いらしいよ」なんて話を聞くと、いっぺんに評価が下がります。
自分で喰わないものを、金とって人様に出すのかい?
コッチの業界でも同じで、自分たちでも使わない・使いたくないようなシロモノを、金とって人様に収めるのかい?
そりゃ、我々が倉庫の在庫管理システムや学習塾の受講管理システムを使うことは無いでしょう(その方面に転職しなきゃね)
でも、少なくとも「使いたい」「人に勧めたい」ぐらいのシロモノでないと、如何なものかと思うわけです。
確かに、実装段階からプロジェクトに入ったとか、そういう「変更不能点」を越えた状態でなら仕方ないでしょう。また、人間誰しも食っていかなきゃならないという現実もあるわけです。
ただ、システムを設計するとか、或いはパッケージを作ってる(受託の一品モノじゃなくって)とか、そういう時には、忘れてはいけない心掛けだと思うわけです。