God is in the details

建築家ミース・ファン・デル・ローエの言葉(らしい)。

ミース・ファン・デル・ローエは、接合部のデザインとか部材の見え方とか、細かいところ如何にシンプル且つ綺麗に見せるかにこだわった人。

ソフトウェアで細部って何だろう？って考えると、手触りなんじゃないだろうかとふと思う。手触りは定量的なもので表すと、性能だったり、UIの配置だったり、ある操作をした時の振る舞いとかで規定はできるんだろうけど、多分それじゃ肝心なのが抜け落ちてしまって、そういったものを使う人が心地よく(定性的!)使うことが出来る仕掛け・構造になっている状態の事なんだろうと。

ソフトウェアは見えないから、定量的に定量的にという方向に突き進んでいる。勿論、それが良い事だし、推し進めていくべきものではあるが、多分そこを突き進めても本当にいい商品は出来ない。

ドッグフーディング(自社開発製品を自分で使う）開発があるが、それは自分自身で使い心地というのを確かめつつ開発する、カタログにも現れず、そんなところを気にする人は少数かもしれない箇所だが、誰かが気になったらそこを良くする、そういうことを通じて、手触りの良い商品というものができるのだろう。

会議ができないのが問題か？

ググってみた。太字は引用者による。

さらばフレックスタイム[Life-Design Labo]

社員が顔をそろえる時間がとりにくいなどの問題に対しては、電子メールなどでの情報伝達を期待したが、実際には用件を伝達するスピードが落ちるなどの非効率な面が目立ったという。

特に、2000年から開発部門を中心に、技術者が自分の専門分野の情報やノウハウを他の技術者と共有して開発効率を高める運動を始めたところ、作業の遅れが深刻化。

フレックスタイムが顧客満足度を下げているのか？[IT Pro]

顧客満足度が上がらないのは，フレックスタイム制が原因ではないのではないか。もっと根本的な問題があるのに，どこかで問題のすり替えが行われたような気がしてならない。根本的な問題というのは例えば，(1)フレックスタイム制の下で成果を正当に評価するシステムが機能していない，(2)そもそも製品やサービス，技術力などの競争力が衰えているために顧客満足度が上がらない，(3)トップの経営方針が社内にちゃんと伝わっていない――というようなことである。

社内の関連部署などとの「意思疎通や協力作業にマイナスになる」というのもうなずけない。ITベンダーがコミュニケーション・ツールの生かし方を工夫できないのでは，顧客に何も提案できないではないか。例えば，時給単価の高いエンジニアが1時間の会議のために片道1時間かけて集まってくる，といったことの非効率性をもっとよく考えるべきであろう。

フレックス廃止［koujinz blog]

「フレックス休止」がなぜ固定費（人件費）の圧縮につながるのか。
まず、「フレックス休止」は「残業ゼロ」と必ずセットになっている。
やむを得ない場合に限り残業する事になるが、
残業を行うためのハードルを上げる事で会社側の支出を抑える事ができる。
今まで残業代目当てでダラダラ仕事をしていた従業員を締め出す事ができる。

<<中略>>

無駄なものはいっぱいあります。
・無駄な会議
・無駄な資料作成
・日和見の製品展開
・(言いたくないですが)無駄な人間
そういった『経営改革』の声が聞こえてこないで『締め付け』ばかりが目に付く
会社であれば、すでに終わっているのかもしれません。

フレックスタイム制度の廃止 賛否両論[35歳 転職限界説を乗り越えるブログ]

フレックスタイム制度を廃止する理由として、仕事の効率を上げるため、社員の意向を一つにまとめるため、会議の時間を設定しやすくするため
などなどありますが、大企業では、光熱費の問題も大きいと思います。
社員が同じ時間に来て、同じ時間に退社してくれれば、光熱費は最低限で澄みます。

フレックス廃止とユニクロ減益[マーケティング的コラム]

そもそも「フレックスタイム」を導入するなら、「残業時間」という発想も捨てなくてはいけないはず。
シャープのようなメーカーであれば、ホワイトカラーもいれば、ブルーカラーもいるはず。
こういう会社では、「残業時間」という発想は捨てられない。
工場では、交代勤務制だろうから、稼働率が上がってくると、やっぱり「残業」という発想があって当然だと思います。
事務所で一日考え事をするような人と、ラインの管理をする人は、やっぱり同じ管理制度ではいけないでしょう。

フレックス制度廃止 コスト削減[教えて!goo]

Q:某大手企業がフレックス制度を廃止したため、通勤時間に門の前に人が多くて最近困っていますが、不況なのでフレックス制度廃止なのでしょうか。ちなみに、フレックス制度は残業代を払わなくてもよい、賃金を抑える制度聞いているのですが。

A:ある意味、総労働時間を減らすことが目的だと思われます。
A:うちでも大分前にフレックス廃止しました。
フレックスにすると、会議が出来る時間が限られてしまい、遅く出社する人に合わせると残業が増えてしまいます。
A:意志の疎通、コニュニケーションの円滑化ができにくくなること

フレックスタイム制廃止の背景[あなたはすでにコケている。]

あと、フレックスタイム制は会議に支障が出るとか、時間の管理が難しいとか。これもおかしい話です。

会議なんて皆がそろっている時間にやればいいだけです。
そろわない時間にやらなければならない会議はないはずです。

管理が難しい？
さて何の管理をしているのでしょう。

上司がするべきなのは時間の管理ではありません。
仕事の管理です。

フレックス(働き方)とコスト(残業)とコミュニケーションの問題を一括りにして上が語るから、意味分からない施策になるんだよ。

ソフトウェア、人がなければ只の文字

最近、redmineの布教をしている。幾人かの人は乗ってくれたので、そこから順に広げていこうと思う。

つくづく思い知らされるのが、人を用意するのがとても難しいということ。仕組みを用意しました、とか、○○が簡単にできるようになりました、なんて対して意味がない。WindowsAPIがこっそり増えてるのと同じくらい無視される。

その仕組みを使って一緒にその作業をやり、伝道者を増やしていかないと、一向に利用者は増えないし、狙いも理解されない。

仕組みとかフレームワークを作るというのは、ソフトウェアそのものを作るよりエコシステムというか皆がそれに乗るべきだという環境を作り出す方がよっぽど大変だと思う。

プロジェクトは人の問題が多い

という事が、最近少しずつ分かってきた気がする、

プロダクト(not プログラム)を作るうえで、一番解決が厄介なのが人の問題。

設計が悪い場合は、他の人が(強制的指導だったりするけど)サポートしてくれて修正される。仕様書がおかしい場合、気付いた人が直してくれる(or指摘が飛んでくる)。
つまり問題が、共有され、レビューされ、変更が皆に知らされ、とプロアクティブに行動できる人が多い。

でも、Aという機能を作るのに人がアサインされていない(アサインがグレーにされている)場合、誰もが問題だと言うのに動く人はごく少数だ。

設計などが上手くいくのは、成果物が見えるからだろうか？
人の管理はマネージャー以外やらないと思ってるからだろうか？（まぁ、そうなんだけど）
それとも、人の問題は面倒なだけ？

生産性と期間

よく上司とプロジェクトに必要な人数と期間について話している。最近は、このご時世なのか昔からなのか知らないが、無茶な計画が多い。当然のごとく溢れる、と。

そこを何とかしなきゃねーという話し。 結論はサッパリ出てないんだけど。

ソフトウェア開発で1本10万円のワインを造る方法 [ITmedia]

1つ話しの焦点だったのが、プロジェクトに関わらせるべき人数。

会社なので、フェーズ毎に生産性の高さが違う人間がいる。設計やプログラムを沢山書ける人間や、テストでバグを発見する確立が高い人間だったり、政治に長けている人間もいる。

まず、その生産性の高い低い(スキルになるのか？)が手持ちの人員にどれだけいるか、プロマネ側が分かっていないよね、と。だから、誰を投入するとどんな結果になるか、理論だった予測ができていない。

も一つは、適正な人数が分かっていない。プロジェクトは参加する人間が増えれば増えるほど、生産性は下がる。コミュニケーションコストは、Nの二乗で増えていくし、ヒューマンエラーも人が増えれば増えるほど発生する確率は増えていく。

かといって、少数精鋭でプロジェクトまわしても、開発のアウトプット「量」には限界がある。生産性はどちらかと言えば開発効率の話しだから、短期間で沢山のアウトプットを出すという話しになると、どうしても人を沢山投入しなくてはならない。

より良くプロジェクトを見積り管理するには、以下のデータを採取して、部署としてのスペックを把握しないと駄目かなーと思っている。

1. プロジェクト成果物のアウトプット量
2. プロジェクト参加人数と開発期間
3. プロジェクト参加人数とアウトプット量の関係
4. 個々人の生産性

4つ目は個人の評価と関わりそうなのでちょっと難しそうだが、上の3つはそんなに難しくないと思う。

大体、参加人数を把握していないっていうのは、管理以前の問題だと思うんだけどナー。

	人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3)) 販売元 : Amazon.co.jp 本 価格 : ￥
[タイトル] 人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3)) [著者] Jr.,フレデリック・P. ブルックス >>Seesaa ショッピングで買う

すれ違い

何だかクリスマスにふさわしくないタイトルですが・・・。

最近、リソース管理というかタスク管理というかそういうものにも関わっている。
まぁ、一番は仕事が溢れたときに「溢れたー」と騒いでいるだけでなく、具体的な数値をもって上に報告と折衝ができるように、きちんとPDCAをまわしつつデータ(実績)を採取する土台を作る狙いだ。本当は切羽詰っているんだけど。

しかし、これが非常に難しい。なんせ個人レベルはさておき、複数人で関わる仕事に対して真面目にやるのは初めてだ。とりあえず、各自のタスクを集約し、計画を積み上げ何とかガントチャートを作ってみた(ガントチャートで計画立ててもソフトウェアで役立つのかは、イマイチ自信がもてないが）。しかし今日、上と話していてふと気付いたのだ。そもそも求めているものが違うことに。

今日、タスクの妥当性について話した。その際に感じた差は、以下の感じである。

作業者：己がタスクを進められるの粒度で書いている
↑
差
↓
管理者：これ以上分割不能な粒度、且つ可能な限り正確な数値で書いて欲しい

管理者が言っていることは基本的に正しいと思う。「己が作業を進められる粒度」で分割されても、他人が作業や進捗を正確に把握できるものでなければ、わざわざ他人にタスクを公開する必要が無い。

例えば、作業者は開発上不明な事を調べる時間を調査として工数として積み上げる。「分からないこと」なので、作業者としては高い精度で工数を積めないので、どんぶり勘定になる。「調査」のようなタスクで何日もとる、と。

管理者としてはそんな訳の分からない項目や数値では困るので、きちんと何を調査するか分けて、目標期日を明確にしろと言う。ごもっともだ。
目標があれば、作業を進めていき目標に対してフィードバックを行っていく事で、どんどん精度が良くなっていくと。ごもっともだ。

つまり、今までろくすっぽ複数人の管理をやってこなかった組織から、いきなりタスクのPDCAがまわっている状態になれという話だ。

これに、非常に困っている。もともとマネジメントに関心が高い人はそれでもいい。そうではなく、現状リソースが溢れていて仕事がまわらなくなってきているので参加している人が、要求レベルが高すぎて(一個人としては高くないと思っているが)、関心を失ってきているのだ。リソースの融通等の果実を得るには、代償が高すぎると。

勿論、上は更に上と話すためにも武器（データ）が必要なので求める背景は分かるし、言っている事も間違ってはいないと思う。ただ、果実が遠くにあると思わせてしまうと、正しい事だとしても前進する力が出てこないように思う。

 

改善をする上でのポイント

7割の企業が陥る現代病、BPMによる解決策は[@IT]

最近、上から改善策を考えるように言われる事が多い。
それだけなら別にいいのだが、上から押し付けのように施策が降ってくるのが、非常に面倒。

リンク先にも出ているが、改善するには以下の3点をそれぞれ考えてから物事を進めていきたいものだ。

1. 日常業務、業務改善、業務改革に取り組む社員のマインド(環境)
2. 日常業務の活動履歴(データ)
3. ITシステム(ツール)

徒然草を読む

自分が寝坊してしまったせいで、一日空いてしまったので、徒然草を読んでみた。
さすがに古典なので、ネットで読める。

個人的に興味が惹かれたものを抜粋。

第131段

貧しき者は、財（たから）をもッて礼とし、老いたる者は、力をもッて礼とす。 己が分を知りて、及ばざる時は速かに止（や）むを、智といふべし。
許さざらんは、人の誤りなり。分を知らずして強ひて励むは、己れが誤りなり。貧しくて分を知らざれば盗み、力衰へて分を知らざれば病を受く。

意訳:
貧しい人ほど金銭を礼とし、老人ほど力をつかって礼儀を守ろうとする。
身の程をわきまえて、自分の力量が及ばない時は、さっさと止めるのが知恵だ。
身の程をわきまえて生きようとしているのを、許さない奴らは馬鹿だ。
身の程を知らないと、貧しい人は盗みを働いて金銭を稼ぎ、老人は体力が無くなっているのに力を頑張って使えば病気になるでしょうに。

 

仕事とか(に限らんが)で人と話すときに、ついつい自分が置かれている境遇ややってきた事、嗜好などを前提に話してしまう。自分にとっては、大した事無くてもその人にとっては大事という事がままある（逆も然り）。
本当に、その人を見て分かった上で発言しないと、単に自分の価値観を押し付ける周囲の「許さない奴ら」と同等になってしまうなー、と。

第150段

能をつかんとする人、「よくせざらんほどは、なまじひに人に知られじ。
うちうちよく習ひ得て、さし出でたらんこそ、いと心にくからめ」と常に言ふめれど、かく言ふ人、一芸も習ひ得ることなし。
未だ堅固かたほなるより、上手の中に交りて、毀（そし）り笑はるるにも恥ぢず、つれなく過ぎて嗜（たしな）む人、天性、その骨なけれども、道になづまず、濫（みだ）りにせずして、年を送れば、堪能（かんのう）の嗜まざらんよりは、終に上手の位に至り、徳たけ、人に許されて、双（ならび）なき名を得る事なり。
天下のものの上手といへども、始めは、不堪（ふかん）の聞えもあり、無下の瑕瑾（かきん）もありき。
されども、その人、道の掟正しく、これを重くして、放埓（はうらつ）せざれば、世の博士にて、万人の師となる事、諸道変るべからず。

意訳:
能を習う人が、人前での失敗を恐れて、こっそり練習して上手く出来るようになったら発表しようと考えても、そんな奴は一芸を習い得る事はできない。
未熟なうちから、その道の名人に交わり、けなされ、嘲笑されても挫けずに練習していけば、才能があるが練習しない奴より、品格も備わり、やがて世間から一流と評価されるだろう。
今でこそ名人と言われる人達だって、最初は下手で恥をかいたこともある。そんな人が、その道の決まり事を守り、我流に流されず名人になり、多くの人たちを教える立場についているのだ。
これは、どんな芸事でも同じことだ。

 

今年から、去年までの仕事とはうってかわって別の領域の仕事をしている。
少々の知識は持っているとはいえ、何分始めてやる事。
失敗は勿論のこと、毎週上司から何かしらの指摘(お叱り?)のメールが飛んでくる事も多い。それでも、自意識を捨てどんどん人前に出て、恥をかき、学んでいく事が、より良いエンジニアになるための唯一の道なんだろう。

第189段

今日はその事をなさんと思へど、あらぬ急ぎ先づ出で来て紛れ暮し、待つ人は障りありて、頼めぬ人は来たり。
頼みたる方の事は違ひて、思ひ寄らぬ道ばかりは叶ひぬ。
煩はしかりつる事はことなくて、易かるべき事はいと心苦し。
日々に過ぎ行くさま、予（かね）て思ひつるには似ず。一年（ひととせ）の中もかくの如し。 一生の間もしかなり。
予てのあらまし、皆違ひ行くかと思ふに、おのづから、違はぬ事もあれば、いよいよ、物は定め難し。
不定（ふぢやう）と心得ぬるのみ、実（まこと）にて違はず。

意訳:
あれをやろうと思ってたら、他の急な用事ができて一日が過ぎ、待っている人は来れなくなるのに、来ないと思っていた人が来た。
期待することは上手くいかず、思いがけない事だけ上手くいく。
かといって、前もって予定していた事が、全て上手くいかないかと言うと、時には上手くいく事もあるので、ますます予定通りにいかせることは難しい。
予定通りにいくこともあれば、いかないこともあることだけが、確かな事であるのは間違いない。

 

世の中、なかなか予定通りにはいかないよっと。
寝坊しちゃうかもしれないしね・・・(ToT;

私的メモ

今、何故俺がこれを書いているか世の中で二人しか分からないけど。

• BD PLAYER BD8002[Marants]
• PM7003[Marants]
• VP-15S1[Marants]
• スピーカーの型番忘れた[Bowers&Wilkins]
• OS SCREEN(型番控えてくるの忘れた)[オーエス]

BDが対応していたのは良かった。

同質化？硬直化？

• 組織の同質化[ファンドレイジング道場]
• No.18 『同質化』と『一体感』の違い[The Servant]
• 「同質化の罠」を打ち破る！[ココロ・マーケティング3号]

なんかこの辺りの記事を読んでたら、
最近自分の考え方が何か一方向に傾きすぎていないかな〜、
と思ってきた。

今年の春まで4年位同系列のプロダクトを作ってきて、
今の仕事もその成果物を使って派生開発という、
今まで携わってきたものの延長線上で仕事している。

幸いな事に、4年間の仕事とは担当するアクティビティや、
フェーズ(立ち上げ100%の仕事だったのが、立ち上げ30%・展開70%位)、一緒に仕事をする人が違うので、考えが完全に硬直することにはならないだろうが。

上手く頭の中がまとまっていないけれど、今までやってきたことの延長だけで作り出すのではなく、もう少し違った視点で検証しながら成果物を積み上げていくのが、必要な頃合なのかなと思う。

小回りのきく大きな組織

来月から新しい仕事。
といっても、方向性が違うだけで関わるテーマは似たような事だけど。

その中で今やってる事に新しいプロダクトが追加される。
今までは要求の口が1つ(+α)だったけど、今後は2つ、3つと増えるわけだ。

そこで問題となるのは、矛盾する要求やうんざりする要求がでてくるのは勿論だが、それ以上に関わる人が増えていく事。

今までは1つの要求口で1つの設計を考えていたわけだからチーム内で素早く方向を修正できてたけど、今後は複数の要求をまとめる人や周辺のコンポーネントを作る人との連携、全体のアーキテクチャを考える人など、多様なバリエーションに対応できるように関わる人が増えるので、3分後に方向を修正とかがなかなか難しくなる。(対応できない人が出てくる)

関わる人が増えるという事は、コミュニケーションパスがn乗に比例して大変になっていくので、1つの物事決めるのにも今以上に時間がかかることが想定される。

これを如何に今と遜色ないスピードに保てるかが、来月からの仕事の一つなのかな〜とか妄想している。
一応、新しい仕事の使命はプロダクトを世に送り出すという事だけど、こういった以下に上手くプロダクトを出し続けられる環境を作るかという事を前にすると、プロダクトを出すことなんて大事の前の小事だよな〜とか思ってしまう。（いや凄い重要なんだけど）

はぁ、面倒。

文章を書くのが嫌な理由を考えてみる(1)

仕様書なりプロセス定義書(?)なりエンジニア(プログラマ)が作成するのに敬遠する文書がある。
こんな事[ 記事]を以前書いているが、やっぱり書くのは面倒くさいし、なかなか書く気に気持ちがならない。

なんでかな？と思うと文書書くのが自分のためじゃないからじゃなかろうか？ と思っている。
後で自分で見返すときあるじゃーん!と突っ込まれるかもしれないが、少なくともコード書いているときや仕事をまわしている時点では文書が必要ない。コードだったら頭や紙片で考えをまとめてコードにおとせば良いし、プロセスだったら実際動く人に直接教えればよいだけだ。その方が今起きている課題には速攻で取り組めるから。

その方が今起きている課題には速攻で取り組めるから。

↑コレ。この考え方が駄目なんじゃなかろうか。文書が必要になるのはこの後だ。誰かに引き継いだり、仕様説明したり、プロセスだったら想定していなかった問題が勃発した時などだ。この時の被害者は大体において自分ではない。(そもそも自分で何故こうしたんだ？とか悩む分には自業自得だし）

そして、上記の事件が起きた後に文書化しようとするとスゲー苦痛。一度、仕様書書きながらコード書くのと、コード書いた後に仕様書を書いた2ケースを自分で比較した事あるけど、後者の方が圧倒的に面倒。思い出すのも苦痛だし、既に現存しているもの(=コード)を何でまた違う形とはいえ書かなきゃならんのだ、という気持ちになってくる。

つまり、

『コードだったら頭や紙片で考えをまとめて』コードにおとせば良いし、『プロセスだったら実際動く人に直接教えればよい』だけだ。

『』を行っている時点で、文書と言う成果物に落とし込まないと後で苦痛になるわけだ。だが、そう簡単に文書を書ければ苦労はしない。

というところで、眠くなってきたので次回へ続く。

力の配分

去年一杯色々と(望む望まず関わらずに)幅広い仕事が出来たのは、自分なりには良かったと思う。

商品そのものが複雑化し設計に多様な知識・経験が求められるのは勿論だが、面倒だが避けて通れないのが調停(ちと言葉に御幣があるな)。部署の内外問わず人を動かすことも少しずつ覚えていかなきゃならんし(じゃないと降ってくる仕事が捌ききれん)、今年も色々と手を出していこうと思う。

と同時に確固たるものを持たずに色々と手をだすと、全てが中途半端で何を学んだと言う事にもなりかねないし、去年以上に上手く立ち回らないといけない。
しかも、去年は当初の予定よりバランスを欠いた仕事の比率で、自分の未開拓の分野を埋める事は出来なかったから、そのリカバリーも考えなきゃならんし。

やっぱ今年も大変だな。

と思った冬休み終わりまで残りあと2日の夜。

Wikiの功罪

DivXやwmvが再生できるようになってPS3オモスレー。

ま、それはさておき今日後輩と話していてふと思ったWikiと設計仕様書の話。

仕事上、情報共有にWIkiとかを使ってるのだが、それにガンガン設計についての情報や調べた事を書いているらしい。 共有すべき情報のメモとして書くのは全然問題ないと思う。むしろその為にサーバー立ててるのだし、書くことに対して心理的ハードルを下げたのは大成功だと思う。
ここで問題なのは、そこで満足してしまうようで仕様書には一切その情報は反映されないことだ。 [*1]

当人達がやっている間はいいのだが、引継いで引き継いでと続いていくとその書かなかった情報は無かった事になってしまう。何故なら書いたWikiにいつでも参照できるような設計者に最後は引き継がれないから。

するとコードが仕様というプログラマの寝言(少なくとも会社勤めでコード書いている人間が言う事じゃない)という状態になってしまう。

これは辿った道は違えど忌み嫌っている前身のプロダクトと同じ状況になるんじゃなかろうか？Wikiとは言えせっかく書いているのに残していないとの評価(結果)になるのは勿体無いと思えてきた。なまじWikiが書き始めるコストが少ないから正式な文書(仕様書)を書くハードルが上がってしまったのだろうか？Wikiは代替物には成り得ないのに。

10年後に今自分達が抱いている前身プロダクトへの評価と同じだったら嫌だな〜。

---

*1:何で書かないんだろう？訳ワカンネーとかグチグチ言われながらコード解析されて何度も聞かれるより、書いたほうがよっぽど身体的にも精神的にも楽だと思うのだが。

体制やプロセスを変化させるタイミング

どれくらい成功しているのか？

ソフトウェアプロジェクトの約7割は失敗だそうだ。失敗と言っても、期間や予算の超過だったり、要求を満たしていなかったりと理由は様々。
ここで疑問。
んじゃ約3割は成功したとして、その後の保守とか機能拡張ってどの程度成功してるんだろ？

チーム体制の変化

って何でこんな事思うかというと、最近のお仕事状況。
当初作った面々が徐々に抜けて、段々と第二世代、第三世代の人に権限・責任が移っていく。それとは別に、今まで同じ場所で働いていた人が離れた地に移っていく(=分散開発になる)。また、ルーチンワーク(だけって訳でも無いが・・・)やってくれる人として派遣さんを雇ういう話もでてる。
つまり、今までコードとノリと文化を理解し、後ろを向けば3分で話が決まる状況から段々とそう簡単にはいかないチーム状況に移り変わりつつある。

チームを取り巻く状況の変化

また環境においても、製品のバリエーションが増えステークホルダーも今以上に増大して、それを捌くのにもマンパワーが割かれるとか、方々から要求が降ってくるとかが考えられる。

そんな状況に変化すると言う事は、徒手空拳でやってきたものから、システマティックなプロセスやマネジメントに移行し始める時期なのかな〜と思う。

どう移行していけば良いか？

んで、最初の話に戻る。最高のメンバ集めました!最高の環境を整えました!プロジェクト成功して納期どおりに作成しました!、んでその後の体制ってどうなんだろう？
会社的にそんな状況をずっと維持してくれるわけでもなく、少しずつ最高のメンバを別のプロジェクトにあてがうわけで、残った人達・後を引き継いだ人達の保守や機能拡張ってどれほど上手くいっているのか、と。

技術職やってるとそんな事考えるの('A`)マンドクセと思うが、プロジェクトの設計・実装なんて3割位の時間で[*1]、例えばテストの方が断然工数が上だ。じゃあ、テストを外部の人に任せるとかすると、3分で話し合って決めて実行していた内容をもっと形式的に仕様書にするとかテスト戦略とかテストに対応する仕様を今まで以上に厳密に書くとか、設計仕様書書いてからいなくなろうよ(愚痴)、とか何だか考える事が膨大になってしまう。

また、BTSやWikiやタスクカード等、様々な角度から検討できるだけの情報がリポジトリにあるのに、それが分析できる状況に無いのも辛い。バグの原因を見て、コミュニケーションエラーなのか実装のミス(=スキルが低い)のか仕様書がタコなのかとかが分かると、チームのパフォーマンスを上げる事も出来るんじゃないかな〜とか思ったりしてるのだが、手が回らない・・・。

と、なんか上手い方法無いかな〜と思案中なのです。

蛇足

な〜んて、最近危機感持ったりする事がしばしば。
「俺、知らね」と逃げられればいいが、今期抜けてった人達が昔自分達が作ったものに引き戻されるのを見てると、その言葉も通用しなさそうだし、何よりそんな言葉を吐いてしまう低級に成り果てるのは嫌だしな〜。

んで、何でこんな事書いたかというと、最近課せられる(チームリーダーをすっ飛ばして上から直接自分に飛んできていると思われる)役割を考えると、隣の部署と交流だって言われて、突然異動させられるんじゃないかと思ったりしてきたので、人が変わっても磐石な体制って何かな〜とか思いを適当に馳せてみた。自分のペアリーダーがその被害にあったし・・・。

---

*1:設計・実装を軽く見ている訳ではないです、念のため。

ソフトウェア技術者の衰退

ちょっと前に東洋経済5/19号 [東洋経済] でプログラマーの未来時給が651円とか出てて、ちょこっと騒いでた(?)けど、何となく日本のソフトウエア産業、衰退の真因 [IT Pro] を読んで納得。

プログラマを単価で測る習慣にするとか、プログラムを知らない新人を投入する習慣(?)とか、自分で自分の価値を貶めている事こそが651円の道なのじゃないかな。

お酢とエンターテイメントとロボットの関係

世界一お酢に詳しいお酢専用ロボットを開発 [ASCII]

↓のようにスターウォーズと合成させても全く違和感無いくらい格好いいお酢の知識が世界一のロボットを開発したようです。

※クリックで大きい画像になります。

何がしたいんだ？

働きがいのある会社

グーグルが語る「働きがいのある会社の作り方」 [IT Pro]

仕事をする上で働きやすい職場の方がいいのは当たり前。
が、意外と(?)日本企業は「信用」「尊敬」といったところで他国より低い点です。 [IT Pro]
リストラやら何やらで人的資本を削ってきたせいか、経営側に対して不信感が高いようです。

逆に米国の優れた会社は「働きがい」に対する認識が高く，働きがいのある会社を実現するために努力をしている会社が多いとな。
日本もこれに続いてくれるようにならんとな〜。

参考:
GPTW(Great Place to Workモデル)
「信用」「尊敬」「公正」「誇り」「連帯感」の5つに分類して点数かする働きがいのある職場の指標。

---

G.W中、友人がこっちに帰ってくると言うので集まって飲んできた。

しかし、その友人は当日に風邪とかいって来なかった・・・。

カスラックよ、それは著作権法の趣旨に反してないかい？

「著作物の利用許諾、ネットで簡易に」　著作権保護期間延長派が計画 [ITmedia]

ITmediaの上記記事を読んでたら、久々に腹が立ってきた。
別にJASRAC本部での会見でJASRACがこういう見解と言うわけではいが。

「パブリックドメインになると、作詞した歌をパロディされるとか、安易な使われ方、不快な使われれ方をすることも十分考えられる。自分の歌をパロディにはしてほしくないと思うから未来永劫に守ってほしい。それが無理ならできるだけ長くして欲しい」と語った。

元々著作権って「著作者等の権利の保護を図り、もつて文化の発展に寄与することを目的とする。」(著作権法第1条より)なのに、 どうして未来永劫守れなんて発想がでてくるのだろう？
元々パブリックドメインで良いんだけど、それじゃ生活とかできないから特例として独占権があるのに、それが逆転してまず著作者の保護ありきでは文化が広がりようが無いではないか？
頒布した最初の頃は少なくとも著作物へのコントロールも必要だが、死んだ後の独占権は本当に必要だろうか？

他にもこんなの。

「人から『お前は（著作権料の支払いが死後も続くため）孫まで金がいくんだからいいじゃないか』と言われることもあるが、ぼくらはそんなに簡単に曲を書いている訳じゃない。それを盗作とは言わないまでも簡単に真似されたり……」と不快感をあらわにし、＜略＞

この人は、曲を作っていない人は簡単に仕事をこなしていると思ってるのだろうか？
世の中で仕事をしている人は、曲を作るより下なのかと。
盗作で騒いでいるが、そんなの曲だけでなくデザインだってソフトウェアだって一緒だろう。
そういうのは淡々と法(裁判)で処理していくだけだ。
この人と一体何が違うというのだ？著作権法で50年も保護されているだけでどれだけ他の権利より優遇されてると思っているのだ。

著作権法が悪者だとは思わないが、著作物を消費財として経済に組み込み売っているのはJASRACなどだ。そうしたら、単なる芸術という側面だけでなく消費財としての消費者の期待(利便性や経済合理性）が出てくるのは当然ではないか？

私は世の中に音楽があふれてほしいし、そのために音楽著作権がしっかりする必要がある

これには同感だが、だからといってデジタル放送のコピーワンスのように使い勝手が悪くなることを消費する側は望んでいるわけではないはずだ。
そういった視点がすっぽり抜け落ちているから、彼らが気にする悪者説が出てきてしまうのではないだろうか？

関連するエントリー

• カスラック・・・もといJASRACがまた寝言を・・・ [記事]
• 速やかにiPodから金を取れ!!! [記事]
• iPodからHDDからPCからも金を取れ [記事]
• JASRACがよく分かるFLASH [記事]

プロジェクトマネジメントの限界と別の軸

今日は上の人達が仕事でどっか行っちゃったので、
俺の天下だー!!!という状況がどおこい四苦八苦状態でした。
つーわけで(?)、マネジメントの話。

バグが沢山出てますよ

上記の通り、お偉方が片っ端からいなかったので自分がリリースに向けての陣頭指揮をとってたのですよ。
「予定より遅れます」とか「想定の範囲外です」とかの言葉がメンバから出るのは、想定の範囲内だったので（それでも自分の予想の3時間オーバーしたが)いいんですけど、それ以上に出てきたのがバグの数。

普段からテストして無いからバグがあれよあれよと膨れ上がるという典型的な例なんですが、これを見てると今のやり方も限界なんじゃないかなと。

マネジメントで影響を及ぼせる範囲

組織的な長としてプロジェクトマネジメントの役割の人がいるけど、今日その立場を擬似的に体験してみて感じた事は、工程の消化具合、進捗の確認、政治的なところは幾らでもマネジメントする人の頑張りでカバーできるのだが、品質そのものにはまるで無力。

音楽で言うところのステージマネージャーが幾ら本番の進行を完璧にこなそうと、指揮者であったりコンサートマスター・奏者が下手な演奏をすると何の意味も無いって所かな。

プロジェクトマネージャー=ステージマネージャーと捉えると、商品(音楽)全体の品質そのものの責任を預かる指揮者であり、コンサートマスターたる存在がいないことにはプロジェクトって成功しないんじゃないだろうか？

分割するのはいいけど、全体は誰が見る？

昨今は、ドメイン分割だのサブシステム分割だのと分割して統治せよが常識なわけで、大きすぎるものは管理できないから小さくして管理するのが主流です。
が、結局最終的に作るものは大きいわけで、そいつを誰がどう管理するのかって問題じゃなかろうか？
XPの共同所有にせよ、RUPの4+1(5+1)ビューにせよ、本当にアーキテクチャレベルのアクティビティを担当している人間が品質までトータルして制御できているのだろうか？
何だか分割した結果、自分の領域に閉じこもっちゃった人が増えた気がしてるのは、じぶんだけだろうか。

まとめ

機能の達成率や納期、モチベーションという軸を管理するマネージャーと、横断的に品質を管理するマネージャーの2軸が今後は必要なんじゃない？と思う1日でした。

ちなみに、この2軸を一人で兼務するのは無理だろうな〜死ぬよ。