EVMは極めれるのか
日経ITプロフェッショナル2004年12号より
特集１ 「進ちょく管理の大本命 EVMを極める」
という記事が興味深い。
EVMとはEarned Value Managementの頭文字だ。プロジェクトマネジメント手法の1つであるPMBOKにもEVMについての記述があるので、少しは聞いたことがある単語かもしれない。
EVMは、一単位あたりの作業コストを事前に算出しておくことが重要になる。建設現場等では、一つ一つの作業にかかるコストが事前に詳細に検討されており、これをベースに進捗状況とコストを同時に確認することが可能になる。
さて、ソフトウェア業界にこれを適応するとどうなるか。基本的に全く同じことはする必要がない業界である。１度作ったものは２度目以降のコストは０である。これを１度作ったものと同じだけのコストを算出して、EVMとして管理するのがどれだけ不毛かということがわかるだろう。
そうすると、EVMの前提となる作業量算出というのが厳密な意味ではほとんど不可能に近いと思っている。適当にやるとどうなるか。人月計算と同じアバウトなものになるわけだ。
適当に工数を積み上げるととてつもない金額になってしまいかねない。それでは駄目と言う話になると、たぶん期間と予算から逆算した１単位あたりのコストが設定されることになるのではないだろうか。予算ってなんだったっけという感じになりそうだ。
また、本文を見ると、なぜか懐かしいクリティカルパスが登場する。システム工学の世界にクリティカルパスはあるが、ソフトウェアの世界ではフィードバックが多数発生するためクリティカルパスほど無意味な図はないと思うのだが、EVMを語るためにはクリティカルパスを登場させざるを得ないのだろうか。
どうにも破綻が見え隠れする管理手法である。学ぶことを否定しないが、現実に即してうまくいきそうだという感じが見えない。何事もやってみないとわからないだろうとか怒られそうだが、どうも管理者のエクスキューズとして使われているだけっぽい気がする。
特集１ 「進ちょく管理の大本命 EVMを極める」
という記事が興味深い。
EVMとはEarned Value Managementの頭文字だ。プロジェクトマネジメント手法の1つであるPMBOKにもEVMについての記述があるので、少しは聞いたことがある単語かもしれない。
EVMは、一単位あたりの作業コストを事前に算出しておくことが重要になる。建設現場等では、一つ一つの作業にかかるコストが事前に詳細に検討されており、これをベースに進捗状況とコストを同時に確認することが可能になる。
さて、ソフトウェア業界にこれを適応するとどうなるか。基本的に全く同じことはする必要がない業界である。１度作ったものは２度目以降のコストは０である。これを１度作ったものと同じだけのコストを算出して、EVMとして管理するのがどれだけ不毛かということがわかるだろう。
そうすると、EVMの前提となる作業量算出というのが厳密な意味ではほとんど不可能に近いと思っている。適当にやるとどうなるか。人月計算と同じアバウトなものになるわけだ。
適当に工数を積み上げるととてつもない金額になってしまいかねない。それでは駄目と言う話になると、たぶん期間と予算から逆算した１単位あたりのコストが設定されることになるのではないだろうか。予算ってなんだったっけという感じになりそうだ。
また、本文を見ると、なぜか懐かしいクリティカルパスが登場する。システム工学の世界にクリティカルパスはあるが、ソフトウェアの世界ではフィードバックが多数発生するためクリティカルパスほど無意味な図はないと思うのだが、EVMを語るためにはクリティカルパスを登場させざるを得ないのだろうか。
どうにも破綻が見え隠れする管理手法である。学ぶことを否定しないが、現実に即してうまくいきそうだという感じが見えない。何事もやってみないとわからないだろうとか怒られそうだが、どうも管理者のエクスキューズとして使われているだけっぽい気がする。
「日本語の外へ」という本を読んだ
先輩から紹介された本。日本語という軸から日本人及び日本についての分析がすごい。
本の紹介はamazonのレビューでも読んでもらうとして、メモしておきたいところを引用。
--
作業の能率は、それによって作り出されてくる物の、使われ方における質の高低を無視するとき、もっとも高く達成される。商品として大量に人の手に渡ったあと、これはいったいなにに使われるのか、どう使われるのか、そのことにどのような意味があるのか、それによってなにがどう達成されるのか、どのような新たな価値がそこに生まれるのか、というような本質的な問いかけを落ち着いた気持ちでおこなうという精神活動、つまり哲学を徹底して無視することが生産作業の高能率化とひとつにつながっている。
--
製造業で大量生産をしている時はこれでよかった。今でも考えずに手を動かせと言っている管理者も結構いるわけだが。手を動かすだけではだめで、脳みそを使わなくてはいけないんだと普通に思っていたが、今回この本を読んで、哲学的なものを徹底的に無視させるような風潮が一番問題なんだと気づいた。
顧客がどう使うかなんてどうでもいいから言われた通りに作ればいいんだとか、我々の仕事は要求に100%答えることだ、とか聞こえはいいが、実はお互いに不幸な道を歩んでいるということに気づいていない。
ソフトウェア開発者には哲学がないとだめだ。ポリシーに反するものは作らないとかそういう頑固親父の話ではなくて、ソフトウェアの設計思想と言うべきものだ。アーキテクチャと呼ばれているもののことだ。
何か仕様変更が発生しそうになった場合、設計思想に反するから拒否ということではなくて、設計思想に添った形でスムーズに拡張できる方法を提案してみるとか、そういうことを試してみるべきだ。
哲学（設計思想）が無いから、提案もできず、つぎはぎのような拡張をしてスケジュールが破綻して、デスマーチに陥る。
どういう使われ方をするのか、どの方向に拡張されうるのか、どこに価値を見出しているのか、を把握せずに、上っ面の仕様書だけで見積を出すと大変なことになるということだ。
本の紹介はamazonのレビューでも読んでもらうとして、メモしておきたいところを引用。
--
作業の能率は、それによって作り出されてくる物の、使われ方における質の高低を無視するとき、もっとも高く達成される。商品として大量に人の手に渡ったあと、これはいったいなにに使われるのか、どう使われるのか、そのことにどのような意味があるのか、それによってなにがどう達成されるのか、どのような新たな価値がそこに生まれるのか、というような本質的な問いかけを落ち着いた気持ちでおこなうという精神活動、つまり哲学を徹底して無視することが生産作業の高能率化とひとつにつながっている。
--
製造業で大量生産をしている時はこれでよかった。今でも考えずに手を動かせと言っている管理者も結構いるわけだが。手を動かすだけではだめで、脳みそを使わなくてはいけないんだと普通に思っていたが、今回この本を読んで、哲学的なものを徹底的に無視させるような風潮が一番問題なんだと気づいた。
顧客がどう使うかなんてどうでもいいから言われた通りに作ればいいんだとか、我々の仕事は要求に100%答えることだ、とか聞こえはいいが、実はお互いに不幸な道を歩んでいるということに気づいていない。
ソフトウェア開発者には哲学がないとだめだ。ポリシーに反するものは作らないとかそういう頑固親父の話ではなくて、ソフトウェアの設計思想と言うべきものだ。アーキテクチャと呼ばれているもののことだ。
何か仕様変更が発生しそうになった場合、設計思想に反するから拒否ということではなくて、設計思想に添った形でスムーズに拡張できる方法を提案してみるとか、そういうことを試してみるべきだ。
哲学（設計思想）が無いから、提案もできず、つぎはぎのような拡張をしてスケジュールが破綻して、デスマーチに陥る。
どういう使われ方をするのか、どの方向に拡張されうるのか、どこに価値を見出しているのか、を把握せずに、上っ面の仕様書だけで見積を出すと大変なことになるということだ。
いつでも適当な絵を書ける訓練をしよう
適当な絵というのはドラえもんを描けとかそういう話ではなく、プログラムの流れや、データ構造や、画面遷移等を、箱や丸やドラム缶や矢印を使って図式化してみようという話である。
プログラムというのはどうがんばっても最後はソースコードに落とし込むため、可視化が難しい。そのため新しく来た仲間や上司や顧客に対しては、いろいろな文章や図表やHTMLで作ったWEB画面そのものを使って説明することになる。
その際に、まだ作ってないけど構想している部分や、用意してきたドキュメントの切り口ではわかりにくいので別の側面から説明してくれと頼まれる場合等は、即興でホワイトボードに絵を描く必要がある。
即興で絵を描いてうまく説明できれば、相手は信頼してくれるようになることが多い。ここで一度よく考えてまた後日云々と言う話になると、相手の勢いが削がれてしまい、開発に対するモチベーションも低下してしまう。鉄は熱いうちに打たないとまずい。
プログラムを絵にするのは、ある程度抽象化能力のある人でないと取っ掛かりが掴めず、どこから描いたらいいのかわからないということになりがちだ。どこを曖昧にしてどこを詳しく描くか、相手が知りたいポイントはどこか、というのを判断する能力は、実際に手を動かさないと身につかない。
どこを曖昧にするかというのは、ある意味インターフェース設計に通じるものがある。曖昧な部分とは、命令を送って結果が返ってくれば中で何をやっているかは問わないという部分のことを指すわけで、適当な絵が描けること＝ある程度の規模のソフトウェア設計を任せても大丈夫、という指標になるかもしれない。
まずは小規模なソフトウェアの流れを頭から順に眺めて、箱と線を使って適当に描いてみるところから始めてみるとよいかもしれない。
昔はみんなフローチャート描いてた気がするのだが、最近はめっきり見なくなった。絵を描くという行為は右脳に作用して、プログラムの全体の構造把握に役立ちそうな気がするのだが。右脳とか左脳とかいう時代ではないのだろうか。
UMLはちょっと複雑すぎるので初心者にはお勧めできない。CADの３面図をばらばらに記述しているような印象が強すぎる。まずはフローチャートで。菱形はIFでいいじゃないかと思う。昔の人ですいません。
プログラムというのはどうがんばっても最後はソースコードに落とし込むため、可視化が難しい。そのため新しく来た仲間や上司や顧客に対しては、いろいろな文章や図表やHTMLで作ったWEB画面そのものを使って説明することになる。
その際に、まだ作ってないけど構想している部分や、用意してきたドキュメントの切り口ではわかりにくいので別の側面から説明してくれと頼まれる場合等は、即興でホワイトボードに絵を描く必要がある。
即興で絵を描いてうまく説明できれば、相手は信頼してくれるようになることが多い。ここで一度よく考えてまた後日云々と言う話になると、相手の勢いが削がれてしまい、開発に対するモチベーションも低下してしまう。鉄は熱いうちに打たないとまずい。
プログラムを絵にするのは、ある程度抽象化能力のある人でないと取っ掛かりが掴めず、どこから描いたらいいのかわからないということになりがちだ。どこを曖昧にしてどこを詳しく描くか、相手が知りたいポイントはどこか、というのを判断する能力は、実際に手を動かさないと身につかない。
どこを曖昧にするかというのは、ある意味インターフェース設計に通じるものがある。曖昧な部分とは、命令を送って結果が返ってくれば中で何をやっているかは問わないという部分のことを指すわけで、適当な絵が描けること＝ある程度の規模のソフトウェア設計を任せても大丈夫、という指標になるかもしれない。
まずは小規模なソフトウェアの流れを頭から順に眺めて、箱と線を使って適当に描いてみるところから始めてみるとよいかもしれない。
昔はみんなフローチャート描いてた気がするのだが、最近はめっきり見なくなった。絵を描くという行為は右脳に作用して、プログラムの全体の構造把握に役立ちそうな気がするのだが。右脳とか左脳とかいう時代ではないのだろうか。
UMLはちょっと複雑すぎるので初心者にはお勧めできない。CADの３面図をばらばらに記述しているような印象が強すぎる。まずはフローチャートで。菱形はIFでいいじゃないかと思う。昔の人ですいません。
ソフトウェア開発をサッカーにたとえると
一般的に、プロジェクトとは何らかの目的の成功のために、ある一定期間に行われる活動のことをいう。要するに期限付きで目標が設定されているものは全部プロジェクトだ。
そう考えると、サッカーの１ゲームを１プロジェクトと言ってもプロジェクトの定義には反しない。ゲームに勝つということがプロジェクトに成功したということになる。そんなわけで、ソフトウェアの開発プロジェクトをサッカーと対比させてみようと思う。
サッカーでゲームに勝つには、やはり人だ。戦略を決めてどういう人材をどう配分するかを決める。配分を決めるのは監督だ。チームのメンバーは力関係はあるかもしれないが、ゲーム上では皆役割が決められているが、最終的には個人が権限を持って動いている。
組織構造は、オーナー／監督／（キャプテン）／チームメンバーという感じだろうか。キャプテンはゲームが始まればチームメンバーと同列だが、チームの代表としての役割が与えられている。オーナーは監督を決めて後は委任。監督はチームメンバーのマネジメントを行うが実際にゲームを行うのはチームメンバーだけである。
さて、ソフトウェア開発プロジェクトではどうか。対戦相手がいないということはさておき、監督に相当する人がマネージャ、チームメンバーに相当する人はSEであったり、プログラマであると思う。適当にマッピングすると、FWはプログラマで、MFはSEで、DFはテスターとかだろうか。
当然のようにチーム内は相互に依存しあっている関係だが、FWはMFより能力が低いということはありえない。FWはFWとしての能力がある人が必要である。それが役割分担でありプロフェッショナルであると思う。
だがなぜかプログラマはSEより一段低い立場で見られることが多い。それでプロジェクトが成功に導かれるのであれば、マネージャの戦略としてはありである。だが、マネージャがそこまで考えているのかどうかはかなり未知数だ。
プログラマは頭数が一杯必要で、SEは少なくていいと考えているのかもしれない。ただ今までそれでやってきたとして、それで毎回成功しているのかどうか。毎回サドンデスの延長戦に突入して、延々と作業したあげくそれでも敗北するゲームをもう一度やりたいと思うメンバーはいないはずだ。そうなるかどうかは監督の采配次第だ。
ここまで書いて、サッカーとソフトウェア開発プロジェクトが決定的に違う点を発見した。観客の存在だ。プロサッカーなら見てもらうことこそが目的だったりするわけだが、ここではそれは取り上げない。
観客に見られていることを意識すると、チームメンバーはやはり自分の行動を意識するようになる。ソフトウェア開発はチームで開発していても結構孤独感がある。自分のチームがどう評価されるか、というのは結果だけ見てもらってもなかなか満足感が得られない。
サッカーで言うところの試合結果だけ見てもらっても味気ないのと同じように、ソフトウェア開発も出来上がったソフトウェアだけ見てもメンバーとしては物足りない。どんなパスを出してどうシュートしたのかと同じように、どういう設計でどういう実装でどういう概念でどういうテストをしてソフトウェアがリリースされたのか、というのを見て欲しいわけだ。
ここで根本的な問題点がある。ソフトウェア開発は会社の利益の源泉だったりするので、そういう気持ちに相反して、全然公開されないということだ。
やっと最近はオープンソースなソフトウェアの台頭でようやく皆でソフトウェアを作ったりいじったり批評したりできるようになってきた。会社でソフトウェア開発に関わるよりオープンソースソフトウェアの方が楽しいと思う人の気持ちもよくわかる。
今までのプロプライエタリなソフトウェアの開発モデルは少し人間の心理学的にずれているような気がするのだ。マイクロソフトぐらい大きい会社であれば、開発と観客をお互いに勤めることも可能だが、中小の会社では観客になりえる人材なんてほとんどいない。
オープンソース万歳という話ではなくて、もう少しプロジェクトの中身を評価できるような人材と体制を整えないと会社の中からいい人材がいなくなってしまいますよ、と言ってみる。
そう考えると、サッカーの１ゲームを１プロジェクトと言ってもプロジェクトの定義には反しない。ゲームに勝つということがプロジェクトに成功したということになる。そんなわけで、ソフトウェアの開発プロジェクトをサッカーと対比させてみようと思う。
サッカーでゲームに勝つには、やはり人だ。戦略を決めてどういう人材をどう配分するかを決める。配分を決めるのは監督だ。チームのメンバーは力関係はあるかもしれないが、ゲーム上では皆役割が決められているが、最終的には個人が権限を持って動いている。
組織構造は、オーナー／監督／（キャプテン）／チームメンバーという感じだろうか。キャプテンはゲームが始まればチームメンバーと同列だが、チームの代表としての役割が与えられている。オーナーは監督を決めて後は委任。監督はチームメンバーのマネジメントを行うが実際にゲームを行うのはチームメンバーだけである。
さて、ソフトウェア開発プロジェクトではどうか。対戦相手がいないということはさておき、監督に相当する人がマネージャ、チームメンバーに相当する人はSEであったり、プログラマであると思う。適当にマッピングすると、FWはプログラマで、MFはSEで、DFはテスターとかだろうか。
当然のようにチーム内は相互に依存しあっている関係だが、FWはMFより能力が低いということはありえない。FWはFWとしての能力がある人が必要である。それが役割分担でありプロフェッショナルであると思う。
だがなぜかプログラマはSEより一段低い立場で見られることが多い。それでプロジェクトが成功に導かれるのであれば、マネージャの戦略としてはありである。だが、マネージャがそこまで考えているのかどうかはかなり未知数だ。
プログラマは頭数が一杯必要で、SEは少なくていいと考えているのかもしれない。ただ今までそれでやってきたとして、それで毎回成功しているのかどうか。毎回サドンデスの延長戦に突入して、延々と作業したあげくそれでも敗北するゲームをもう一度やりたいと思うメンバーはいないはずだ。そうなるかどうかは監督の采配次第だ。
ここまで書いて、サッカーとソフトウェア開発プロジェクトが決定的に違う点を発見した。観客の存在だ。プロサッカーなら見てもらうことこそが目的だったりするわけだが、ここではそれは取り上げない。
観客に見られていることを意識すると、チームメンバーはやはり自分の行動を意識するようになる。ソフトウェア開発はチームで開発していても結構孤独感がある。自分のチームがどう評価されるか、というのは結果だけ見てもらってもなかなか満足感が得られない。
サッカーで言うところの試合結果だけ見てもらっても味気ないのと同じように、ソフトウェア開発も出来上がったソフトウェアだけ見てもメンバーとしては物足りない。どんなパスを出してどうシュートしたのかと同じように、どういう設計でどういう実装でどういう概念でどういうテストをしてソフトウェアがリリースされたのか、というのを見て欲しいわけだ。
ここで根本的な問題点がある。ソフトウェア開発は会社の利益の源泉だったりするので、そういう気持ちに相反して、全然公開されないということだ。
やっと最近はオープンソースなソフトウェアの台頭でようやく皆でソフトウェアを作ったりいじったり批評したりできるようになってきた。会社でソフトウェア開発に関わるよりオープンソースソフトウェアの方が楽しいと思う人の気持ちもよくわかる。
今までのプロプライエタリなソフトウェアの開発モデルは少し人間の心理学的にずれているような気がするのだ。マイクロソフトぐらい大きい会社であれば、開発と観客をお互いに勤めることも可能だが、中小の会社では観客になりえる人材なんてほとんどいない。
オープンソース万歳という話ではなくて、もう少しプロジェクトの中身を評価できるような人材と体制を整えないと会社の中からいい人材がいなくなってしまいますよ、と言ってみる。
いつの間にか捕捉されている。
えんきみ日記
■ [diary]「それゆけ西表島」が 00:18
復活していた！
はてなから移転しても気付いて頂ける、というのは有難いことだと思います。
タイトルいっしょにしておいてよかった感がありますね。
今後ともよろしくです。
■ [diary]「それゆけ西表島」が 00:18
復活していた！
はてなから移転しても気付いて頂ける、というのは有難いことだと思います。
タイトルいっしょにしておいてよかった感がありますね。
今後ともよろしくです。
自動でモノを作るということ
「キヤノン 国内２５％無人ライン」
国内生産額（約一兆円）の２５％に相当する製造ラインを自動化・無人化するとともに、五千人規模の配置転換と合理化を行うことなどを柱とする生産体制の抜本改革に乗り出すことが二十二日、分かった。
ハードウェアの世界で自動化が進むというような記事が出ると、ソフトウェアの世界でも自動化を進めるべきだという話になったりするわけだが、ソフトウェアの世界ではすでに自動化は極限まで進んでいる。
具体的には、プログラム（設計書）を書きさえすれば、実行ファイルの作成を自動的に行ってくれるわけだ。これはハードウェアの世界でいうと、設計書だけあればラインが全自動で動いてモノができることに他ならない。
要するにソフトウェアの世界では、設計書を作る工程に２年も３年もかかるわけだ。正確には「何を作るか」の仕様を決める段階でやたらめったら時間がかかるわけだが。
企画会議を延々やっているといっても過言ではない。そして設計書を作っている最中にも、仕様の変更が発生する。一度ラインに載ってからも仕様変更が発生する。
ソフトウェア開発は、後は自動化できない部分が残っているだけだ。まだ自動化できるという主張もあるかもしれないが、それは工程の途中で自動化工程と非自動化工程を切り分けただけで、なんの解決にもなっていない。
仕様から設計書を自動的に作成するということであれば、その仕様が設計書なのである。何を作るか（仕様）、どう作るか（設計書）が自動化できるのであれば、それはすでに世の中にある製品ということなので、ことさらアドバンテージはないはずである。
まぁそれでも、ソフトウェア開発にはまだまだ無駄はいっぱいあるので、それを省くことが急務であるような気はする。それが何かは長くなるのでまた次の機会に。
プログラムの部品の粒度をコントロールしよう
プログラムを組むという言葉があるが、プログラム作成というのは決められたルールに基づいて部品を組み立てる作業である。
基本的な部品の数は少なくて、できることも限られている。なので、基本的な部品からもうちょっと複雑なことができる部品を作る。そして、もうちょっと複雑な部品を組み合わせて、高度なことができる部品を作る。最終的にやりたいことができる部品になるわけだが、元を辿れば基本的な部品のかたまりに過ぎない。
逆に辿れば、ソフトウェアは基本的な部品だけで成り立っている。物質が原子で成り立っているというのに似ている。
現実世界では、原子で何かをしようとする人と、建築現場で建築作業をする人は、別々に仕事をしている。だが、ソフトウェア開発の現場では、基本的な部品と高度な部品を同じように扱う。実世界にたとえると、建築されたビルにある原子が組み込まれていて、その原子を触ると瞬間的にビルの屋根が三角になったり、ビルの７階の電気が消えたりする。
これが１つの原子だけならまだ制御は可能だが、このような原子が数十、数百と組み込まれて、お互いの振る舞いに影響されるとなると、もう誰にもわからなくなる。
その昔、ソフトウェアはスイッチ１つでなんでも変更できるというのがウリ文句だった時代もあったようだが、ある程度以上高度な部品を扱うようになるとデメリットの方が目立つ。
便利と不便は表裏一体なので、プログラムの部品の粒度のコントロールというのは大事だ。オブジェクト指向というのは、無駄が増えるだけと思うかもしれないが、部品の粒度をある程度コントロールするにはちょうどいい考え方と言えるのではないだろうか。
基本的な部品の数は少なくて、できることも限られている。なので、基本的な部品からもうちょっと複雑なことができる部品を作る。そして、もうちょっと複雑な部品を組み合わせて、高度なことができる部品を作る。最終的にやりたいことができる部品になるわけだが、元を辿れば基本的な部品のかたまりに過ぎない。
逆に辿れば、ソフトウェアは基本的な部品だけで成り立っている。物質が原子で成り立っているというのに似ている。
現実世界では、原子で何かをしようとする人と、建築現場で建築作業をする人は、別々に仕事をしている。だが、ソフトウェア開発の現場では、基本的な部品と高度な部品を同じように扱う。実世界にたとえると、建築されたビルにある原子が組み込まれていて、その原子を触ると瞬間的にビルの屋根が三角になったり、ビルの７階の電気が消えたりする。
これが１つの原子だけならまだ制御は可能だが、このような原子が数十、数百と組み込まれて、お互いの振る舞いに影響されるとなると、もう誰にもわからなくなる。
その昔、ソフトウェアはスイッチ１つでなんでも変更できるというのがウリ文句だった時代もあったようだが、ある程度以上高度な部品を扱うようになるとデメリットの方が目立つ。
便利と不便は表裏一体なので、プログラムの部品の粒度のコントロールというのは大事だ。オブジェクト指向というのは、無駄が増えるだけと思うかもしれないが、部品の粒度をある程度コントロールするにはちょうどいい考え方と言えるのではないだろうか。
ユーティリティクラスなんて作ってはいけない
プログラムを作る時に、似たような関数群は１つのファイルにまとめてユーティリティクラスとか、ユーティリティライブラリというようなことをよくやる。
しかし、今のソフトウェア管理ソフト（CVSとか）は、ファイル単位で管理できるが、関数単位では管理できない。関数単位で管理できないというのは、関数を別のファイルに移動した場合に、トラッキングするのが困難ということである。
JavaAPIは、数学系の関数を全部java.lang.Mathというクラスにまとめているが、実際の開発において、それを真似する必要はない。
よくわからないけど文字列関連だから文字列関連ユーティリティクラスを作ってそこに全部入れる、というようなことはなるべく避けたほうがいい。そもそも独立した関数は独立したものとして扱うべきで、その場の判断でグルーピングするぐらいなら、独立したまま１関数だけのクラスにした方がモアベターだと思う。
要は、関数をまとめてファイル数を減らすという方向に進むのは、プログラム全体を管理する面から見るとあまりよろしくないということだ。
関数単位の管理ツールがあればまた話は変わってくるような気もするが、ポリモーフィズムとか考えると一筋縄では作れそうにないような気もするので、とりあえずはありもので考える方がよい。
しかし、今のソフトウェア管理ソフト（CVSとか）は、ファイル単位で管理できるが、関数単位では管理できない。関数単位で管理できないというのは、関数を別のファイルに移動した場合に、トラッキングするのが困難ということである。
JavaAPIは、数学系の関数を全部java.lang.Mathというクラスにまとめているが、実際の開発において、それを真似する必要はない。
よくわからないけど文字列関連だから文字列関連ユーティリティクラスを作ってそこに全部入れる、というようなことはなるべく避けたほうがいい。そもそも独立した関数は独立したものとして扱うべきで、その場の判断でグルーピングするぐらいなら、独立したまま１関数だけのクラスにした方がモアベターだと思う。
要は、関数をまとめてファイル数を減らすという方向に進むのは、プログラム全体を管理する面から見るとあまりよろしくないということだ。
関数単位の管理ツールがあればまた話は変わってくるような気もするが、ポリモーフィズムとか考えると一筋縄では作れそうにないような気もするので、とりあえずはありもので考える方がよい。
アメブロ雑感
２日ぐらい使ってみたアメブロの雑感。一部はてなの時との比較も。
１番のメリットは、自分のサーバで適当に日記を書いても誰も見に来てくれないが、こういう集約型のサービスでは、同じジャンル、隣の日記という概念が出来やすいので、わりと頻繁に更新していれば見に来てもらえる率があがることだと思う。
はてなはキーワード抽出で似たような内容の日記を抽出していたわけだが、アメブロはそこまではやっていない。関連抽出は処理がわりと高負荷になりがちなので、今ですら処理速度が遅いアメブロでは難しそうだ。
その代わりといってはなんだがランキングシステムがある。ランキングシステムは上位数％は本当の人気を表しているだろうが、それ以外の人でも毎日更新していれば内容はともかくある程度順位が上にあがっていくと思う。そういう意味ではいいシステムだ。
なので、最初の２週間ぐらいは順位が上にあがっていくことで、日記を更新するモチベーションがあるが、その後順位が動かなくなったあたりで、システム側が何かサポートできるかどうか・・このあたりが肝ではないだろうか。
私なら、不動の１位はさっさとランキングシステムから離して殿堂的な扱いに変えて、他の人たちでまた１位を競わせるようなことをやってしまいそうだ。いいか悪いかは別にして。
１番のメリットは、自分のサーバで適当に日記を書いても誰も見に来てくれないが、こういう集約型のサービスでは、同じジャンル、隣の日記という概念が出来やすいので、わりと頻繁に更新していれば見に来てもらえる率があがることだと思う。
はてなはキーワード抽出で似たような内容の日記を抽出していたわけだが、アメブロはそこまではやっていない。関連抽出は処理がわりと高負荷になりがちなので、今ですら処理速度が遅いアメブロでは難しそうだ。
その代わりといってはなんだがランキングシステムがある。ランキングシステムは上位数％は本当の人気を表しているだろうが、それ以外の人でも毎日更新していれば内容はともかくある程度順位が上にあがっていくと思う。そういう意味ではいいシステムだ。
なので、最初の２週間ぐらいは順位が上にあがっていくことで、日記を更新するモチベーションがあるが、その後順位が動かなくなったあたりで、システム側が何かサポートできるかどうか・・このあたりが肝ではないだろうか。
私なら、不動の１位はさっさとランキングシステムから離して殿堂的な扱いに変えて、他の人たちでまた１位を競わせるようなことをやってしまいそうだ。いいか悪いかは別にして。
Seasarのからさわぎ＠東京 2004 Finalに参加
Seasarのからさわぎ＠東京 2004 Finalに参加してきました。
主催者及びスタッフの皆様お疲れ様でした。
朝まで騒ぐ人が20人以上いたようですが、先に撤退しました・・。
さて、午後の部はビジネストラックに参加して、事例を目の前で拝見したのだが、S2フレームワークを駆使して業務を規定しコストダウンを図るにはどうすればいいか、という命題と答えが用意されていた。
2次会から3次会に渡り、延々とS2をどう適用するかという話をしていた気がするが、フレームワーク＝とことん抽象化、業務部分＝１つ１つ定義して淡々と作る（部品化、抽象化をあまりしない）という結論になんとなくしっくりきた。
S2を含むフレームワークというものは、頭のいい人がかちっと作るものであり業務に依存させない。そして、そのフレームワークを用いて業務を組み立てる部分というのは、誰でも作れるレベルまで落とし込み、あまり横断的な抽象化や部品化を考えずに作る方が、納期や単価の設定が容易になる。
オブジェクト指向開発の根本的な問題点は、全体も部分も全て抽象概念に支配されていて、少しでも同じようなコードがあればリファクタリング、抽象化、デザインパターンという流れになってしまう。
この中途半端な機能の抽象化、集約が設計や実装やスケジュールや見積を困難にしている原因のように思ってきたのだが、フレームワークと実装を完全に分離することでこのあたりの考え方が解りやすくなってきたように思う。
あとは、適用範囲の見極めぐらいか。画面オリエンテッドでなんでもできるということでもないのだが、考え方はかなり応用範囲が広そうだ。
主催者及びスタッフの皆様お疲れ様でした。
朝まで騒ぐ人が20人以上いたようですが、先に撤退しました・・。
さて、午後の部はビジネストラックに参加して、事例を目の前で拝見したのだが、S2フレームワークを駆使して業務を規定しコストダウンを図るにはどうすればいいか、という命題と答えが用意されていた。
2次会から3次会に渡り、延々とS2をどう適用するかという話をしていた気がするが、フレームワーク＝とことん抽象化、業務部分＝１つ１つ定義して淡々と作る（部品化、抽象化をあまりしない）という結論になんとなくしっくりきた。
S2を含むフレームワークというものは、頭のいい人がかちっと作るものであり業務に依存させない。そして、そのフレームワークを用いて業務を組み立てる部分というのは、誰でも作れるレベルまで落とし込み、あまり横断的な抽象化や部品化を考えずに作る方が、納期や単価の設定が容易になる。
オブジェクト指向開発の根本的な問題点は、全体も部分も全て抽象概念に支配されていて、少しでも同じようなコードがあればリファクタリング、抽象化、デザインパターンという流れになってしまう。
この中途半端な機能の抽象化、集約が設計や実装やスケジュールや見積を困難にしている原因のように思ってきたのだが、フレームワークと実装を完全に分離することでこのあたりの考え方が解りやすくなってきたように思う。
あとは、適用範囲の見極めぐらいか。画面オリエンテッドでなんでもできるということでもないのだが、考え方はかなり応用範囲が広そうだ。