大連立？

久々の投稿です。
３月中旬にはこのネタがあったのですが、地震で情勢が一変しましたので書き込みを控えていました。
４月になって落ち着いてきた頃に会社の研修会での発表があり、書き込みどころではなく・・・

発表内容（ＨＴＭＬ５）ネタは折を見て少しずつ書き込む予定です。



さて、本日のお題　「大連立」　ですが、一応言葉の定義から。

大連立（だいれんりつ）とは、議院内閣制の国家における連立政権（2つ以上の政党が連立して内閣を構成する政権）の特殊な一形態。政権を安定させることを主な目的に、議会の第1党と第2党による連立政権を指す。


相変わらずwikipediaよりの引用です。
大連立、と言っても連立政権の一種に過ぎないというわけです。
しかしながら、今の日本の政党勢力を考えると大連立は実に危険な手段だといえます。
いつの頃からか、「二大政党制」を志向してきたことにより、議会の第１党と第２党で勢力を二分する形が常になっています。
この状態で大連立を行うと、独裁を行うことも可能です。
（参考までに、ナチスドイツの下地の一つに、ＷＷⅠ敗戦後の極限状態と連立の常態化、大統領権限の強さが上げられます）

そこまでする度胸は民主党にないと思いますが（小沢一郎は例外）、「健全な野党」としての立場を保っている現在の自民党は良い選択をしていると思います。



ぐっと程度を下げまして、政争がらみの話です。
震災後の大連立の話は、国家の危機という一点では正しいのですが、民主党の姿勢が最大の問題だったと考えられます。
子供手当てに代表される「急を要さない重要法案」を取り下げなかったのです。
震災直前の問題（政治資金関連）もありましたので、これでは菅内閣延命の為の大連立と取られるのは必至です。
マスコミはひっそりと民主贔屓をしているようですが・・・　利の面からも、筋からも、大連立をやったら自民党がつぶれます。

また、民主党には悪い前例があります。
宮崎の狂牛病についてまとめたサイトを見るとわかりますが、狂牛病発生当初から自民党は具体的な対策を複数回にわたって提案していたそうです。
この対策は昔（１０年くらい前）の狂牛病の際の経験を元にしたものと言われています。
提案を受けた民主党は・・・　これを取り上げなかったそうです。
結果はご存知の通り、宮崎の畜産が消滅するかというレベルの被害だったわけで。
これと同じことを今回の震災でも・・・　すでにやっているような気がしますが○|￣|＿

そして、指揮命令系統がグダグダであること。
やたらと対策本部なりなんなりが乱立状態で、誰が責任を持って対応しているのかが見えない状態です。
システム開発でもＴｏｐが見えない状態では現場が締まらないことがありますが、炎上してるプロジェクトがそんな状態だったらどうなるかは火を見るより明らかです。


現状で有効な対策としては・・・

• マニフェストの停止と必要最低限を除く震災関連以外の立法の停止　
• 内閣総理大臣が方針を明示し、各大臣が行政機関に具体的な指示を行うことで震災対策を行う
• 意見を聞くだけの機関は設置しない
• 特命大臣は不要。人手が必要なら政務官の増員で実務をまわす
• 復興にかかる費用の概算を算出し、補正予算算出の基礎資料を作成する

といったところでしょう。
立法の停止とか随分と過激なことを書いていますが、そんな暇があったら震災対策をやれよ、ということですね。
「去年と同じで」というのは手抜きもいいところですが、それくらいのことをしないと震災対策を行うリソースがないと思います。


あまり纏まっていませんが、この先どうなるのかと悶々としているより良いかと思って書いてみました。

議論って何？

暑いですねぇ。

本日の予想最高気温は３３度だとか。

W杯の誤審やら、菅総理が消費税上げ（１０％）について公約ではないとか良く分からない事が新聞などを賑わせておりますが今回は良く分からないことをわかるようにする為の工夫に通じるかもしれません。

議論という言葉について調べようと思い、Google先生に質問をしてみると・・・

今回の質問に対する的確な回答は頂けませんでした＾＾；

そのかわりコレが出てきましたので、お時間のある方は見てみてください。「議論のしかた」だとか・・・　ちょっと堅いかなと思いましたが悪くはないですね。

まず、議論は何のためにするのか？

特に企業においては課題の解決策を決定する為、というのが第一義になるでしょう。

この場合の「課題」とは、顕在化しているものだけでなく潜在的なものも対象になります。

当然、潜在的な課題を顕在化させること自体が課題となることもあるわけですが、その辺は余裕で別に話が書けてしまうので保留します。

課題の解決の為、となると、議論のやり方は決まってきます。

1. 課題を参加者で共有する
2. 課題の解決策を用意／提案する
3. 解決策の長所／短所を参加者が理解できるように説明する
4. ここの解決策について参加者がそれぞれ考え、最善または次善の策を選び、実行に移す

というステップで議論⇒実行へと進むわけです。

このとき重要なのは

• 他の参加者の話を聞く
• 他の参加者が理解できる話をする
• 課題を忘れない
• 実行できる案を提案する

といったあたりです。

実に当然のことばかりですね。

しかしながら・・・・・・

意外と人の話を聞けない社会人は多いもので、

理解しているかどうか窺いながら話をする人も少数派なわけで・・・

話しているうちに、課題の解決ではなく論敵の撃破に力を入れてしまったり、

実現不可能な絵空事を提案してみたり・・・

心当たり（自分でも他人でも可）がない方は居ないと思います。

議論ではありませんが、筆者自身Chromeの速度を社内で伝えようとして説明への理解度を見ずに話をしてしまったのであまり偉そうなことは言えません＾＾；

相手を知り、自分を知ってもらうことで議論は進むのではないかな？　と思うので、自説を押し通そうとする人とは議論できないなぁ、と思う今日この頃です。

自説を押し通すだけなら議論じゃなく指示／命令で良いわけですから。

明日教える為に、今日聴く

参議院選挙が始まりました。
８時～２０時までは騒音に悩まされる日々が２週間ほど続くことになります。
あまりにもうるさく、日常生活に支障がある場合にはお近くの選管まで＾＾；


時事ネタでつかみはオッケー（？）　ということにして、本題。

筆者は中途入社で今の会社に入った為、社歴的には先輩ばかりの状態です。
しかし、年齢的には２０代の社員が多いので教える立場になることもあります。
当然、教わる立場でもあります。
教わるのはよいとして、教える為の元ネタってどうやって仕入れているのか？
「そんなの経験だよ」
と割り切れる方にはつまらない話だと思いますが、書いてみようと思います。

人に物事を教える（若しくは伝える、でも可）というのは存外大変な作業です。
相手の持っているであろう知識や概念と、教える物事の溝を埋めたり橋をかけたりする作業と言ってよいでしょう。
（脱線ですが、企業の採用において高学歴者（それも難関校）を優先する背景の一つは、知識や概念の量の多さと質の高さを期待するがゆえと考えることが出来ます）
ということは、少なくとも教える物事を相手に認知させるのに必要な知識や概念を理解していないと、この作業を行うのは困難ということになります。

では、教える為に必要な知識や概念はどうやって仕入れるのでしょう？

一つのアプローチは、
「自分が理解した時のことを覚えておく」
です。
どのような知識や概念からその物事を理解したのか？
これと同じ道筋をたどれば他の人も理解できるはず。という考え方です。
汎用性は低いですが、比較的容易に実践可能です。
何故汎用性が低いかと言うと、自分自身と同じような知識や概念を持っている人でないとうまく教えることが出来ない為…　同じような背景の持ち主同士ならば有効ということですね。

もうひとつのアプローチは、
「物事を他の物事と結び付けて理解する」
です。
筆者はこちらのアプローチを好んで行います。
AとBは～～が同じで＊＊が異なる、という感じに理解しようとすると、何らかの基準が必要になります。

例）
「ご飯とパンは炭水化物の塊という点で同じだけど、形状（粒食と粉食）が異なる。」

ここでは、「炭水化物（成分）」と「形状（見た目）」が基準として出てきます。
どちらも大体の人が理解できる一般的と言ってよい基準です。
このような基準を使うことで自身の理解も他者への説明も円滑にできないかなぁ、と考えていたりします。

知識や概念の仕入れ方はどのアプローチを選ぶにしても、「聴く（または読む）」という作業なしには成り立ちません。
身近に多くの知識などの持ち主がいるのであれば、進んでその言葉を聞き、理解しようと脳をフル回転し、自分なりの解釈を質問として投げかけてみるのが一番ですね。
「門前の小僧、習わぬ経を読む」　ではありませんが、お経に接する日常を送ればお経を読めるようになってしまうわけで。

今日聴いたことを、明日誰かに教えるくらいの意気込みでいると、自分自身の力になるのではないかなぁ、と思います。

やまなしおちなしいみなしですね＾＾；

マイスタージンガー？

タイトルに疑問形が増えている気がしますが気にしない方向で。
筆者は歌よりも曲の方が好きで、オーケストラによる演奏・ピアノ独奏などを聴く傾向にあります。
ゲーム好きなのでゲーム音楽も良く聴くのですが…　今回のタイトルは当然ながらワーグナー（ニュルンベルクのマイスタージンガー）からです。
ちなみに、マイスタージンガーって何？　と思って調べたら　"Meistersinger"というスペルでした。
後は簡単。　"Meister"な"singer"　の意味ですので、直訳だと「職人の親方な歌手」という程度の意味ですね。
何故親方歌手なのかについては歌劇の内容やニュルンベルクの歴史に踏み込むので省略。
詳しく知りたい方はwikiなりなんなりで調べてみてください。

 今回の本題は「マイスター」です。
「職人の親方」とか「匠」とか翻訳できますが、その意味通りのエキスパートのことを指します。
現在でも、ドイツでは大学に行く進路と職人としての進路が等価なものとして存在するとのこと。
昔から職人の地位が高かった様子ですが、マイスターの社会的地位があるからかな？　と想像しています。

システム業界において、いろいろな歪みが存在するのはご存知かと思いますが、その最たるものが人材に対する考え方と言えます。
３５歳定年説、なんて有名過ぎる言葉です。
これは３５歳くらいになると単純作業をさせるには賃金が高い。しかし、他の作業が出来るわけでもない（そのように育成したり、自己研鑚を仕向けていない為）ことから使えない人材となってしまう。
この流れを指すわけですが、何故単純作業以外に進めない人が多発するのか？　ここがシステム業界の歪みの一つです。
これを考える場合、「単純作業の次って何？」ということを考える必要があります。
誤解と偏見がありますが、政治家で言えば「秘書」⇒「地方議会の議員」⇒（地方の首長）⇒「国会議員」という「レール」が存在します。
大企業で言えば、出世＝仕事のレールと言えるでしょう。
システム業界にも一応それがあります。
「コーダ（プログラマ）」⇒「ＳＥ（設計・製造・試験担当）」⇒「プロジェクトリーダー（マネージャー）」
というのが大まかな「レール」です。
この「レール」に乗れるのは、実はごく一部の人だけになります。
ちょっと考えればわかりますが、プロジェクトリーダーの配下には複数名のＳＥやコーダが付きます。今、ＳＥをやっている人たちがそのまま５年後にプロジェクトリーダーになったら…　ネズミ算式に配下が必要になりますね。
それ以前にそれだけの仕事を確保できるのか？　という話もありますが…

一方で、技術力の向上とか品質の向上という課題に対しては現場のＳＥなどの自助努力に依るところが大きいです。
結果、何でもできる人だけが上に行き、何でもできる為に忙しい思いをし、最悪の場合出来る人から潰れていくなんてことになります。
しかし、一芸に秀でた人がそれをサポートするとどうなるか？
この考えが「マイスター制度」の基本です。

新たなプログラミングのできる（言語を使いこなしている）人
ハードウェア構築に秀でた人
ネットワーク構成に詳しい人
ＤＢ全般のエキスパート
……
こういう人たちをプロジェクトリーダーと等価と見なす制度が業界の歪みの解消とデスマーチの緩和に役に立つのではないかな？　と考えています。

微妙なたとえですが、シミュレーションゲームでは万能キャラがもてはやされますが、それ以上に特化キャラを使いこなすことが勝利のカギだったりします。
一芸に特化した匠を重用する姿勢を企業側が見せた時、どのように業界が変わるのか興味があります。

勝兵は先ず勝ちてしかる後に戦いを求む

気が向いたので孫子の一節を。

古の所謂善く戦う者は、勝ち易きに勝つ者なり。故に、善く戦う者の勝つや、知名なく勇功なし。

故に、その戦い勝ちてたがわず。たがわざるは、その措く所、必ず勝つ。
すでに敗るる者に勝てばなり。
この故に、勝兵は先ず勝ちてしかる後に戦いを求め、敗兵は先ず戦いてしかる後に勝ちを求む。
（軍形篇）

 
非常に簡単に言うと
『上手に戦いをする人は勝ちやすい状況を作り、勝ちやすい相手と戦う。だから、立派な働きをしているように見えないのに戦えば勝つ。それは既に負けが決まったような相手と戦うからだ』
という程度の意味です。
 
孫子は格調高い、まとまった文章が特徴であることが知られているので、状況を置き換えた文章を並べた本がずいぶんと出回っています。
なので、単純な置き換えではなく、実際の現場に即した書き方を試してみたいと思います。
 
『デスマーチと無縁に見えるプロジェクトリーダーは、要件と期間から”自分たちが”出来るかどうかを判断して出来る案件を優先的に請けるし、難しい案件でも条件を交渉して出来るように持っていく。
そのうえで予定通りに作業を進められるように準備・管理を行うので、大して仕事をしていないように見えるのに予定の期間と費用で仕事が終わっている。』
 
実際にはそんな案件ばかり請けることは難しいのですが、以下の循環に入る企業が多く見られます。
 
　案件（仕事の受注）や単価（売り上げ）が減って経営が厳しい
　　↓
　少しでも売り上げがほしいのでどんな案件でも請ける気持ちになってしまう
　　↓
　明らかに厳しい案件だが請けてしまう
　　↓
　プロジェクト炎上＆デスマーチ発生
　　↓
　若手や中堅から戦線離脱＆熟練者を含めたメンバーの退職を誘発
　　↓
　作業効率の低下
　　↓
　顧客からの評価が低下して案件や単価が減る
　　↓
　以下、エンドレス
 
この悪循環に近いことをしている企業を見たことがありますが、そこでは中途採用を積極的に行ってカバーしている様子でした。（４月に入社した新人十数名全員が翌年２月までに退職したと聞きましたが＾＾；）
明らかに「敗兵は先ず戦いてしかる後に勝ちを求む」状態ですね。
 
悪循環からの脱出方法は正直書くことができません。しかし、悪循環に陥らないようにとは言えますので、自分たちに出来そうにもない（作業量的に、です。技術や知識は補えることが多いので）仕事は請けないようにしましょう、としか言えないのです。孫子が生きていたとしても同様でしょう。
 

プロジェクト管理に欠けたるもの

プロジェクト管理、と一言にいってもいろいろな意味がありますが、筆者のようなＳＥにとっては数名～十数名程度のチームの管理がまず連想されます。
予定と実績の管理と乖離した際の対応・メンバーの配置や士気、勤怠への配慮・チームの作業をいかにスムースに進めるか…　と言った話はいくらでも雑誌などで取り上げていますが、今回はそれらで取り上げていないものについて書いてみます。

　取り上げられていないもの：管理者（リーダー）不在時の対処方法
リーダーだから、というだけでへろへろになりながらも出勤してくる人がいます。
しかし、リーダーだからそこまでしなくてはいけないというのはチームで仕事をする意味がないともいえます。
リーダーの役割は意外と単純で
　・方針決定を行う
　・チームの全体最適を指向する
　・進捗の調整（特に遅れの取り戻し）を行う
　・雑用その他諸々の事柄を処理する
という程度です。
コーディングはＡさんに、ＤＢのことはＢさんに、会議の連絡調整はＣさんに、といった具合にチームに必要な機能単位で実質的な担当分けを行っておけば、リーダーは機能不全に陥らないように状況を把握するだけでうまくいきます。
この方法の良い点は、リーダーでなければできないこと（発注者との折衝など）を除けば、担当分けを行ったＡ～Ｃさんに”いつもどおりに”確認して、仕事を進めることができる点です。長期の大まかな予定と、直近１ヶ月くらいの作業分担ができていればリーダーがやることは大してありません。

権限委譲の話に近いですが、普段から機能単位の担当分けを意識していれば「リーダー個人」ではなく「チーム」が仕事を回してくれます。
この状態を作り出すことこそ重要なのではないかな？　と思います。