2007-05

mkawanoの日記 - FireBugでデザインにもあるけど、FirebugでHTMLやCSSの修正をちょこちょこやって確認できるのはすごい楽。

そして、右クリック→「Inspect Element」で、すぐに目的のDOMへジャンプできるのが激しく便利。

普通にFirebugを使っているのに、右クリックメニューからInspect ElementでDOMにジャンプできるのを知らなかった人がいたので書いてみる。

Google Analyticsのリニューアルされた画面を見た。

これはいいかも。
少し使いやすくなったし、なんといってもサマリーデータが見やすくなった。

ただ期間がデフォルト1ヶ月なのは良いけど、表示期間を変更してもグラフは一ヶ月のままっていうのは仕様なの？

おかげで一日単位のPVの推移とか見られなくなっちゃったんだけど。
もしかして使い方が分かっていないだけ？

この記事を見た。
IT業界の「3K問題」 NTTデータ社長の考えは？ － ＠IT

強固な要件定義を行うためNTTデータはシステム開発の契約を2段階に分けることを始めている。1段階目では顧客とシステムデザイン契約を結び、コンサルティングにより、システム開発のグランドデザインや要件を決定する。要件定義を「見える化」し、顧客とNTTデータ側で意見の相違がないようにしておく。 2段階目で実際の開発請負契約を行う。NTTデータが開発した透明度が高い見積り手法を使うことで、顧客の理解度を上げる。SLAも導入し、システム開発を定量的に評価する。このように契約を2段階に分ける考えはフェージング契約と呼ばれる。

この人ほんの少し前にはこの前はこんなこと言ってた。
システム開発は楽しい　ＮＴＴデータ　浜口友一社長に聞く｜産業｜経済｜Sankei WEB

　－－ＮＴＴデータは問題にどう対処しますか

　「大規模システムの一部分でも、頭から全工程を手がけるやり方を試行する。米グーグルを訪問したが、３～６人の小チームがたくさんあり、それぞれが設計からコーディングまでをこなす。それを持ち寄ってひとつの大きなシステムを作るそうだ」

　－－ものづくりの楽しさを取り戻すんですね

　「それもあるが、チームを構成する個々の技術者が極めて優秀でないとこのやり方はうまくいかない。つまり、スーパープログラマーとでもいうべき技術者を集めて、生産性の高いソフト制作の手法を編み出したい。相応の処遇についても検討する」

　－－契約の在り方については

　「徐々に見直してゆきたい。まずは、作るものをクリアにすることが肝心だ。納期と費用だけを決めて開発に着手するという、あいまいな状況を正していく」

確かに言うは易し行うは難しなのは分かるけど、いきなりこの@ITの記事だとさすがに拍子抜け。
普通すぎる、今のSIerの目指す方向としては特に普通すぎる。
プロジェクトマネジメントがしっかりしているSIerだったら今でも普通の契約形態じゃない？

上流は高単価で直営社員を中心にリスク少なく利益を出して、開発請負はさらに請負契約で丸投げして(自社の)リスク少なく利益を出して、という構造が見えるのは考えすぎですか。そうですか。
SIの業界構造の問題はそのままですね。

産経の記事ではNTTデータの社長がこんなこと言うんだーと思ってちょっと期待したのに。

ちょっとした配列処理を簡単に書ける楽しさはかなりいい。
内包表記を多用した後でPHPとか書き始めると、”foreach” と書く前に、”new_array=[x * 2 ･･･” とか書きそうになってくそーと思うくらい。

PHP使ってると高階関数も恋しくなるときがある。
それから無駄にClassとか使わないで、functionの中にちょこっとfunctionって書きたくもなる。

やっぱり関数型言語をちゃんとやってみたほうがいいかも。

「ふつうのHaskellプログラミング」は読んで面白いと思ったけどまだ触ってない。
Lisp（←関数型っていっていいのか？）もちょこっと触っただけ。
流行のErlangでもやってみようかな。並列処理って言うのも面白そう。

うーん、こんなもんだと思いつつも悩みどころ。
十分見通しのよさとDRYのバランスは取れているとは思うんだけど。

■newformsとmodels.py
たとえば、modelに登録日などのタイムスタンプを”created = models.DateTimeField(auto_now_add=True)”なんて書いた日には、普通にform_for_modelを使うと必須エラーになってしまう気がする。
入力フォームとmodelの構造が微妙に違うときなんかも、そのままでは上手く行かない（例えば登録時にパスワードとかemailを2回入力させたり）。
単純なフォーム以外は無理矢理この二つをDRYにしたところで見通しが悪くなるだけなのかなぁ？

■urlの記述
ついついテンプレートにハードコードしちゃう。
{% url %}を使えば良いのか？
将来変更される可能性があります、、、は気になるけど。

■Javascript
上記の二つとは毛色が違うけど、サーバー側処理とJavascriptの記述はやっぱりDRYっぽくないよね。例えばURLとかdomのidとか、その他もろもろの処理がサーバーとJavascriptに混在してしまったり（←設計が悪いとも言う）。
これも上記と同じで、DRYにする仕組みを作って分かりにくくなるより、JavascriptはJavascriptだと割り切ったほうがいいのかな？
書くの嫌いじゃないし。

かなり前の話だが、PythonでCGIを書いてみようと思ってさくらインターネットのレンタルサーバーにCGIをアップしたらInternal Server Errorになって、ものすごーくはまったことがある。

トレースも出力されないし、何をやってもダメ。
そもそも実行された形跡がなさそう。
Pythonのパスが違うのかなーとか色々悩んでしまった。

今思うと恥ずかしい話だが、パーミッションを775にしてしまったのが問題だった。
（共用サーバーだからセキュリティの観点からもパーミッションは 755 or 705 にしなきゃ動かない設定になっている）

久しぶりに実際に手を動かそうとすると、ものすごい簡単なところではまる上に、解決策もすぐに見つからないものだなーと実感した。

プロジェクトリーダーとかマネージャーとかになって手を動かさなくなる人も多いと思うけど、実際に手を動かさないで錆付いちゃうと結構まずいこととかあるだろうなと反省した。

もう少し深く考える力や効率よく考える力を身につけるためにはどうしたら良いのか？
とりあえず自分のことは棚にあげて、後輩をどう指導したら良いのか悩むときがある。

こんな人が身の回りに必ずいると思う。

・本質を理解しようとせず、表面的なものだけなぞって結果を出そうとする
・分からない事象が出てくると、すぐに考えることをあきらめる
・全体感を上手く把握できない
・目に見える細かな事象の積み上げでしか考えられない
・結果的に結論が大きくずれてしまう
・挙句の果てによく分からない外的要因のせいにする

この本は数に強くなると言いながら、こういった人たちがどうやって思考力を磨いていけば良いのか分かるような内容になっていると思った。

数に強くなる

posted with amazlet on 07.05.08

畑村 洋太郎
岩波書店 (2007/02)
売り上げランキング: 1492

Amazon.co.jp で詳細を見る

前述の素養を持った(?)人たちは、4章にあるような数を使ったノウハウをありがたいと思うかもしれないが、これはあくまで思考した結果の例としてとらえるべきだと思う。（もちろんそれ自体も役に立つのだが･･･）
肝となるのは3章までの数を使った考え方の話だろう。中でも特に2章が肝。

まずはこの本で自分の思考過程の振り返りと再整理をしたいと思った。
その上で、考え方を後輩などに伝えながら、折を見て本書を読んでもらうと効果が出る気がした。
多分いきなり読んでもいわゆるノウハウ本ではないため、「はぁ？」と思われてしまいそうだから。

ちなみにこの本は1章の前半が一番抽象的で読みにくいと思う。
数が苦手な人が立ち読みして、そこでダメだと思って読むのを止めないで欲しいなと思う。

偉そうなエントリーになったけど自分のこともちゃんと振り返らなきゃな。

学生症候群、パーキンソンの法則といった言葉を聞いたことがある人は多いと思う。

誤解を恐れずに簡単に言うと、クリティカルチェーン・プロジェクトマネジメントというのは、それらの悪しき習慣を排除するために各タスクの納期を厳しく設定して、遅れた場合のバッファはプロジェクトマネージャーが確保しておき、そのバッファによってプロジェクトの状態を把握する管理手法だ。

これは優秀なプロジェクトマネージャーは無意識で行っていることも多い。スケジュールだけではなく見積もりでも、各自でバッファを積み上げられるととてつもなく膨れ上がってしまうため、極力各メンバーにはバッファを持たせないようにするわけだ。

恥ずかしながら、今までこういった管理手法はウォーターフォールモデルに適用されるようなものだとばかり思っていた。実際にウォーターフォールを例にとった事例も多いし。

でも、Getting Real by 37signals を読んでそれは間違っていたことに気づいた。ここにはクリティカルチェーンと本質的には同じ趣旨の内容が書かれていた。

こういった開発手法をとった結果、（パーキンソンの法則にしたがって発生する）余計な機能を開発せず、余計な議論もせずにスピードをあげて効率的な開発ができ、結果として出来上がるサービスもより効果的でシンプルなものになるのだろう。
もちろんクリティカルチェーンだけでこの効果が出るわけではないが、重要な部分を占めていると感じた。

Web2.0的な開発手法やアジャイルっぽいアプローチが好きな人（特にプログラマ）は、プロジェクトマネジメントを軽視、というか好きじゃない人が多いと思う。日本のSI的ウォーターフォール＋マネジメントの理不尽なかんじがらめが嫌で、クリエイティブなプログラミングを好む人が多いのだから当たり前だとは思う。

でも、クリエイティブを発揮しようとするときほど、予算、スケジュール、スタッフ数を厳しく設定したほうが効果があがることが多いだろう。特にアジャイル開発を実践するのなら全員がプロジェクトマネジメントの視点を共有しておかないと、バラバラになるか、いたずらに時間とお金を浪費するかになってしまうと思う。

何をやるにしても、プロジェクトマネジメントなんかいらないと思わずに、たとえ一人プロジェクトだとしてもきっちりマネジメントしなきゃならないなーと痛感した。
当たり前の結論だけど自分に甘えて忘れがちだから気を引き締めないと。

ちなみに、クリティカルチェーンを知りたい人は、まずはやはりこの本を読んだほうがいいのかな。
例によって物語風で読んでいて楽しいし。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

posted with amazlet on 07.05.03

エリヤフ ゴールドラット 三本木 亮
ダイヤモンド社 (2003/10/31)
売り上げランキング: 27880

Amazon.co.jp で詳細を見る

私は上記の本を読んだだけでは自分が実行しているイメージが沸きづらかったのだが、この本を読んでなるほどと思い実行する気になった。

CD‐ROM付 目標を突破する 実践プロジェクトマネジメント

posted with amazlet on 07.05.03

岸良 裕司
中経出版 (2005/12/17)
売り上げランキング: 11687

Amazon.co.jp で詳細を見る

ザ・ファシリテーター

posted with amazlet on 07.05.02

森 時彦
ダイヤモンド社 (2004/11/12)
売り上げランキング: 931

Amazon.co.jp で詳細を見る

本屋で気になってはいたものの、なんとなく手が出ず読んでいなかったのだが、友人に薦められたので読んでみた。
ファシリテーションの基本を、楽しんで読みながら身に付けられる良書だと思う。

特に、「ファシリテーションって会議の司会でしょ」という認識の人はぜひ読んで欲しい。議論をうまく作っていくための思考フレームワークというのがあることを認識するだけでも価値があると思う。
また、リーダーシップを発揮しなければならない人も参考になる部分が多いと思う。

あえて悪い点をあげるとしたら、あまりにもうまく行き過ぎなところだろう。実際の現場では、もっと政治的な対立や人間的なトラブルがあるはずで、これを読んで簡単だと思って現場に持ち帰ると落胆するかもしれない。

そんな人は続編を読むといいと感じた。

ザ・ファシリテーター2―理屈じゃ、誰も動かない!

posted with amazlet on 07.05.02

森 時彦
ダイヤモンド社 (2007/01/27)
売り上げランキング: 17769

Amazon.co.jp で詳細を見る

この続編では、もっと人間的な部分に踏み込みながら組織改革に取り組んでいく主人公を見られる。
Amazonの評価コメントにもあるように、ファシリテーションを学ぶという意味では前作より劣るが、議論をリードしていくリーダーシップをどうやって発揮するかという意味ではこれもぜひ読んだほうがよい。

ファシリテーションというと会議の進行役のイメージで誰でもできるように思っている人もいると思うが、本質を見通す洞察力、的確な判断力、メンバーを惹きつける人間力など様々な能力が必要なはず。
それは最近のリーダーに求められる能力そのものだと思う。

この本で言っているファシリタティブリーダーというのは、他の流行言葉でいうとサーバントリーダーというのとほぼ同義だと思うが、そのようなリーダーになるためのノウハウというか心構えというか、そんなものが実感できると思う。

前回のエントリーで書いたように画像アップの簡単な仕組みを作ったが、そのときの思ったことを書いてみる。

最初は、画像掲示板を作るんだからRSSを出力する仕組みも必須かなと思っていた。そのほうが便利だと思ったし。
でも、嫁のブログのアクセス元を見ていたらRSSリーダーが皆無だった。というわけでRSS出力はとりあえず一次リリースからははずすことにした。

そこで思った。
RSSリーダーなんて普通の人(はてな界隈に出没する人とは違う、かなり大勢の人たち)は使っていないんだ。ソーシャルブックマークだって使わない。数年後はブログみたいに広がるかもしれないけど、少なくとも今は使われていない。

その他にも、このブログと嫁のブログを比べるとこんなに違う。

■検索エンジンからの流入、Google ： Yahoo!
このブログ　50:1
嫁のブログ　1:1（MSN経由もその5分の1くらいいる）

■ブラウザのIE比率
このブログ　40%
嫁のブログ　90%

まー確かにこのブログは始めたばかりだし、アクセス数も嫁ブログに比べると少ないが、これだけ違いが出るというのは面白い。

サービスを作るときに、みんなが自分と同じようにネットに慣れ親しんでいるわけじゃないというのを忘れちゃだめなんだよな。
新しいサービスの形とか新技術とかがいらないわけじゃなく、それを分かりやすく提供して、普通の人にリーチできるまで地道に続けていくのが大事なんだと感じた。