teruyastarはかく語りき

TVゲームを例に組織効率や人間関係を考える記事がメインのようだ。あと雑記。

サイボウズは50%ルール

http://www.atmarkit.co.jp/news/200803/07/tech.html
グーグルは「エンジニアは自分たちの属するコミュニティに対してよく働くという基本的な特徴」(森井氏)
を生かして、社内に多数のコミュニティを作り上げている。
現在のグーグルはオープンソースのコミュニティの集合体に近い。
エンジニアはそのコミュニティの中で評価されるために一生懸命に働き、アイデアを出す。
その結果がグーグルの競争力を向上させる。

さすが!
グループウェアNo1の企業だけあって
運営のしかたや、経営哲学がしっかりしてらっしゃるw


そりゃはてな転職組もいくわw



グーグルが検索を開発する会社だから
自然と自社内が検索文化そのものになって爆発成長したように、
サイボウズも、グループウェア開発する会社だからこそ
そこへいたったということか。


しかし。
1年前の何かの記事では、
グループウェア作ってるくせにもひとつわかってないなあ。
という印象の記事も見かけた。
グーグルと比べると運用効率が悪いと。


この記事は違うね。
はっきりわかってる。
グーグルの良さを真似てやっと真価を発揮し始めたのかもしれない。


、、サイボウズ、設立自体はグーグルとほぼ同い年なんだね。



逆に、任天堂や、未来工業は、年功序列の雇用形態だ。
「従業員は、ほとんど仕事を選べない。給与における誰もが納得する判断基準がない」
とかいうことで。


これはプロジェクトに対して柔軟なWebソフトウェア産業か、
ハードも手がける昔ながらの企業かの違いなのかもしれない。


関連:
http://finalf12.blog82.fc2.com/blog-entry-194.html
どんな企業でも Web2.0化して利益を倍増させるコロンブスの卵が発見された!!


http://finalf12.blog82.fc2.com/blog-entry-471.html
未来工業研究結果

ゆで蛙企業

http://www.atmarkit.co.jp/news/200712/26/it.html
つまり、オールドスタイルの経営に執心する企業は見限ってしまえということだ。
人がどんどんいなくなれば、IT業界の“重鎮”も現実に気付き、
考えざるを得なくなる。


なんという、実感メモw


変わらざるを得ない企業、
それでも変わらない企業。



会社は、みんなそこには気づいてる。
とっくの昔に気づいてる。


その後の分岐点、


「うちが、変わることのできない理由」をひたすら100個考え上げてるか、
「そんなうちでも、変わることができる方法」をひたすら100個考え上げてるか、


98%は前者だ。
今のやり方で、新しい責任をもたずやっていくほうが楽だから。


そして個人としても、会社としても目の前の仕事で手一杯で、
新しいリスクは避けたいだろう。
こうなると「変わることができる方法」を考えるのをやめてしまう。
考えても「それができない理由」でつぶしてしまう。
「それができない理由」を超えようとは誰も思わない。


孤独の中で自分の力だけで考えたり
責任回避で協力ができないとなると、
あきらめるほうがずっと楽なのだ。


コミュニケーションコストが気軽なツールがないと、
横のつながりが生み出せない。


そしてそこから飛び出すより、
ゆで蛙となって徐々に死んでしまうのは、
実はそういう人間の脳のシステム上の問題だったりする。
会社のつながりのシステムの問題だったりする。


なら、いっきに温度を上げてしまえw

プログラミングのスピードを上げる方法

http://q.hatena.ne.jp/1203667934
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか?

プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。
そのため いつもつらい思いをしています。

環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。

出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テストリファクタリングも当然行いますが、余計に開発速度が落ちています。

しかし開発速度は効率化とは無縁だとすら感じています。
仕事を減らすことが優先ではないか?と。

昔から創作活動は好きですが、人より時間がかかる方でした。
最近はプログラマーに向いていないとすら言われます。

どうか私にお力添えをください。

僕はプログラマじゃないのだけど、
門外漢の適当な考えでも何かヒントになればと思いつつ。


まず、

4HWW本の Tim Ferris が言っていたように、

タスクを細切れにするよりも、
不必要なタスクをそもそも消すことが大切なのではないか?と考えてきています。


なぜ、週4時間働くだけでお金持ちになれるのか?
なぜ、週4時間働くだけでお金持ちになれるのか?ティモシー・フェリス 田中 じゅん

おすすめ平均
stars不完全・不正確な抄訳本
stars一見の価値あり
starsたくさんのノウハウはあるが…
starsすばらしい!
stars頭の切り替えができそう。

詳しく見る


と、いうのが核心かと思います。


でも、一プログラマーがその権限を行使できる領域は少ないかもしれません。
コードの中は支配できてもそれより大きな枠となると、、、

下っ端が会社を自分のいいように変えていく方法
http://finalf12.blog82.fc2.com/blog-entry-396.html

これがヒントになるかな?
ただ、本筋と違うので今回は割愛。



もひとつ注目したのが、

いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、

そのようなものを人工的に、作ることができるとよいですね。


これに狙いを絞って、たぶん答えとなるページが

論理的思考の放棄
http://d.hatena.ne.jp/softether/20070324


僕は、1 日に少なくとも 3,000 行程度、
多く書くときで 10,000 行以上のプログラムを書くことができる。
その結果、多い月で 10 万行 / 月くらいである。
なお、言語は書くソフトウェアの性質上、大半が C 言語である。


また、プログラミングにはバグが付き物だが、
ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。


略、


自分の能力は、上記程度であるが、能力というのはこれくらいが標準的なのだろうと思っており、
自分の能力が特別高いということは思っていなかった。


しかし、どうやら、いろいろなソフトウェア開発者の話を聞いたり、記事を読んだりしてみたところ、
上記の程度にできる人はごく少数らしいということに、最近気付いた。


いろいろ調べたの結果によると、普通の開発者の作業能力は、1 ヶ月数百行程度、
多い人でも 1 ヶ月で 3,000 行程度らしい。


"1 日、数百行" ではなく、"1 ヶ月、数百行" である。
もちろん職業プログラマーの話で、
仕事の他に、毎日大学へ行ったり自分の会社を持っていたりしている訳ではなく、
プログラミングに専念していても、この程度だという。イメージしていた現状と全然違う。


そこで、ここ 4 年間くらい、
自分自身の能力の根源について探求を重ねると共に、いろいろなことを調べているうちに、
普通の人の考え方と、自分の考え方とが大きく乖離しているらしいという事がわかった。


このようなことだけを書くと、
「自分にはそういう能力には縁が無い」とか「少しできるからといって自慢するな」とか「偶然だ」
とか思う人がいるかも知れないから、
これから、誰でも少し考え方を変えるだけで、
上記のような能力・作業効率を獲得することができるのだということを伝えたいと思う。


そうすれば自分一人ではなく、みんなにとって有益だと思うからである。


でも!
登さんの話は哲学過ぎて誰も理解できないのであるw


なんで、ちょっと分解して別解釈やってみる。



ホントに生産性を上げるなら、4HWW本の考え方。
ここでは、プログラミングをスピードアップさせて、
没我的な、「フロー状態」でプログラミングそのものを「楽しむ」考え方。


神が降りてくるとは?


「フロー」とか「神が降りてくる」というのはわけがわからんので、
「ずっと途切れずにスピードに乗ってる」と解釈する。


どうすればスピードにのれるのか? 又はどうすればスピードが維持できるのか?


とんでもなく当たり前のことを言うけど、
石を投げないで欲しいw


自分の力だけでスピードに乗るにはまず慣性をつけることだ。
自転車のギアで考えてもらいたい。


いきなり5速ギヤを回そうとしてもこれはつらい。
まず1速。
パワーのある人は2速からはじめてもいい。
これでスピードにのったら、どんどんギヤを上げていく。
そうすれば5速も楽に回せる。


はじめから5速を回そうとしても、スピードにのる前にお昼休憩になったり
いろんな邪魔がところどころ入るので、これは難しい。


登さんの言う

1 努力しないこと


2 論理的に考えないこと


3 頭を使わないこと


を、天才の成せなる技とは思わずに、

1 努力しないでいいように


2 論理的に考えなくてもいいように


3 頭を使わないでもいいように


最初からそう組み上げていく。


では、スピードの邪魔をしてるものはなんだろう?


といったらいくらでも思いつくのでこれも割愛。


逆に、スピードの邪魔を排除するには?

とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、
プログラミングをするときでも、事前の設計が極めて重要となる。
設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、
パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。


ゲーム開発者で似たような考えの人がいます。

大乱闘スマッシュブラザーズX
大乱闘スマッシュブラザーズX
おすすめ平均
stars上達する気のある人は楽しめる
starsやはり最高!!
stars確かに面白いんだけど・・・
stars納得するまで時間かかった。
starsマンネリ化

詳しく見る


ソラ桜井氏、「スマブラX」におけるジャパンチューニングの神髄を披露
「Development - SUPER SMASH BROS. BRAWL」
http://www.watch.impress.co.jp/game/docs/20080224/gdc_sma.htm


桜井氏は締めとして、ゲームデザイナーは「最初にこそよく考えておくこと」が重要であることを協調した。
「ディレクターにとってはここが一番重要。
キャラクタ設定、グラフィックス、モーション、パラメータがばっちり決まっていればキャラクタも幸せ。
最短距離をまっすぐ進めば、チームの負担も減るし、その分作り込んだ良い作品に仕上がる可能性が高い」と持論を展開。


 また、「作ってみなければわからない」という日本におけるプリプロダクション重視の傾向については、
「よほど開発期間に余裕があるときにしたほうが良いのではないか」と、暗にこれを否定した。
開発期間に余裕のあるプロジェクトなど存在しないからだ。


 桜井氏は「頭の中で仕様を転がして、頭の中のゲームで遊んだ上で、しっかりスタッフに指示ができるように頑張って欲しい」
と桜井氏らしいアドバイスを投げかけ、
「ゲームを作っていると方向性に迷うことがあるが、ピンチの時こそ自分を信じて突き進んで欲しい」とまとめた。


確か↓このソフトの開発者上田文人氏、
最初に徹底したプロトタイプムービーを作り上げたのと
実際にできあがったソフトにほとんど違いがなかったという話でした。


ICO PlayStation 2 the Best
ICO PlayStation 2 the Best
おすすめ平均
stars謎解きとストーリー
starsこの価格なら味わう価値は絶大ですよ。
stars万人にオススメ出来るゲームソフト。
stars静寂の美
stars神ゲーの中の神ゲー

詳しく見る


いかに、スピードの邪魔を徹底して排除するか?


プログラムの分野では、かならずしも徹底した設計が用意されてないことも、
用意してないことも多々あるでしょう。


でも基本的には、そういった環境設定により
「努力しないでいいように」
「考えないでいいように」
「頭を使わなくてもいいように」
プログラミングできるんじゃないかと。


よく、プロの工場とか厨房でとんでもない達人技を高速に仕上げる人がいますが
プログラミングも、環境設定によってはそこまでいっちゃうんじゃないかと。
登さんのように。


しかし環境設定を工夫するほど、効率が落ちることも、、

環境を良くしようとHHKLite2を使い、
カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。

出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テストリファクタリングも当然行いますが、余計に開発速度が落ちています。


ちょっと、分からない単語もあるのですが、
HHK
ゲーミングマウス、
タブブラウザ拡張設定、
パワーマシン、
デュアルディスプレイ
など、これらは大いにギヤを上げやすくするので有効だと思います。


しかしここで突っ込むのは、
「本来の生産性を上げる」ではなく、
「いかにスピードにのったまま楽しくプログラムできるか?」です。


ちょとまて、考えないプログラミングが楽しいのか?


脳トレとかテトリスをハイスピードやってると思うのですが、
単純作業でも速ければ速いほど脳は楽しいドーパミンを出してくれます。
スピードがでるから楽しい、
楽しいからスピードがでる。


もちろん本来の「ひらめきの楽しさ」も
「スピード」から生まれることは多々あるので
それは心配しなくてもよいかと。


その環境設定は、作業を中断させない設定か?


拡張設定や、全体として長い目でみて効率的なクラス構築とか、
環境を整えれば整えるほど、ずっと全体の速度が上がるはずなのに
それを作るのに、毎度毎度ギヤを1速に落とし直してたら本末転倒。


もちろん、理論上はそういう仕組みのほうが全体効率としていいのかもしれません。
ただ「速く楽しくプログラムる」という基準からは離れるのかも。


ただひとつのワンクリック、
ソース的な美しさ、
コメント、
ウィンドウの切り替え、
コピペ、
検索、、、、


もし、こういうのがなくて
たった一つのウィンドウだけで、流れるようにコードを書けたら神も降りてきそうですよね。


プログラマじゃない僕が言ってもなんですが、
「とりあえず動く物を作る」
「できるところから作る」
という、スピード最優先で、あらがあってもそれがどんなに汚くても

「自分が気持ちいい」

という感覚が大事だと思います。



感覚を中断させないOS、
感覚を中断させないソフトウェア、
感覚を中断させないツール
感覚を中断させないデバイス、
感覚を中断させない設計書、
感覚を中断させないプログラミング、
感覚を中断させない言語
感覚を中断させない机、
感覚を中断させない椅子、
感覚を中断させないチーム、
感覚を中断させないメール、
大きいところから、小さいところまで、数十の減速があると思いますが
これをいかに設定するか?
が、フローに入り、それを維持する肝なんじゃないかと。
スピード最優先、自分の気持ちよさ最優先の環境設定です。



プログラムがtwitter並に、手軽に書き殴れるぐらいのスピード感があったら最強ですよね。
もしかして、登さんの境地はそんなところかも。


これは関係ないかもしれないし、ヒントかもしれない。

twitter を中心にした文章生成作法
http://medt00lz.s59.xrea.com/blog/archives/2007/12/twitter.html

新しい言語を覚えきれないから、流れるようにプログラムできない

英語がしゃべれないから、外人としゃべれないかというとそうでもないですよね。
「ソースが汚くてもいい」のであれば、
中学英語でも、発音がカタカナ英語でも通じるもんです。
完璧な英語をしゃべろうとすると、とたんにしゃべれなくなる。


もちろんきちんと単語や文法をマスターするのが先決でしょうが、
プログラムは、「if」「for」「switch」あたりが分かれば
なんでもでも応用できるという話も聞いたことあります。
ま、極論すぎますけど、
「とりあえず動く物を作る」
「できるところから作る」
というルールなら、いろんなショートカット、
いろんな学習のショートカットもあるかもしれません。


英語を覚えるのには、海外の彼女を作るのが一番とか、
自分の気持ちよさ最優先でいいんですよね。


まとめ


「考えないでいいよう設計段階でプログラム作業を細部まで並べる」
「スピード最優先。気持ちよさ最優先」
「ウィンドウの切り替え一つとってもいらない拡張は切り捨てる」
「便利さよりも、止まらない速さ」
「100のうちめんどうな20を切り捨てる開き直り」



もしかして、まったく検討違いかもしれませんが、
それは僕の開き直りw
僕が気持ちよければそれでいいんです
( ゚∀゚)o彡゜フウゥッ♪ フウゥッ♪




フロー状態については、もひとつ別の哲学があります。


「脳が予測する」


ちょっと長くなったんで、これは次のエントリーで。。



プログラミングのスピードを上げる方法2 - teruyastarはかく語りき


プログラミングのスピードを上げる方法3 - teruyastarはかく語りき


大事な話があるんだ - teruyastarはかく語りき


Doingリストの割り込み対応拡張版を紹介 - teruyastarはかく語りき