Usa*Usa日記

■[Work]定時で帰ると花火の時間にぶつかります

画面はワイヤフレームの作業に入ったり、DBは第0版の設計までして処理一覧までは拾えたので、僕ちんは来週からアプリの骨組みの準備に入ります(・∀・)

っていうか、Controller、View、Repositoryのひな形までは今日一通り準備しちゃったけど。

Repositoryのメソッド数計は43。

まあ、そのほとんどはリソース系のテーブルをCRUDするだけのものなので、手間もかからなそうですが(・ω・)

っで、骨組みを作っていて思ったんだけど、今回のアプリ、VPSじゃなくてクラウドで動かしてもイインジャネ(ﾟ∀ﾟ)？、なんつったりして。

2つばかり集計クエリがあるけれど、そんなたいした処理ではないので、どうとでもなるし。

まあ、それは遊び半分でちょっと考えておくことに(・∀・)

ところで、今日は市川神明の花火大会ですね。

道路混みそうだけど、環状線を通って帰るのなら大丈夫かな(・∀・)？

家から花火が見える人なのでした。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 11:58

■[Work]今日からはしばらくWebの人ですよ

今日はインフラ周りの要件をまとめてインフラのチームに伝えて、午後からはとりあえずURL設計とか。

明日はDB設計で、お盆の前までに骨組みを固めて、後は作るだけの状態にする予定(｀・ω・´)

デザインチームからデザインの正式版があがってくるのは8末予定。

っというか、提案書と平行でそういう事をやっているけれど、時間的な余裕も無いし。

悠長に待ちスタイルでいくべき案件でも無いので、「こうします」と言ってどんどん作業を進めていくのです(´Д｀)

とりあえず、15 Controller、69 Method(・∀・)

VerbがPOSTな処理はその1/4くさい。

まあ、メインな機能はほぼ参照系(メインのメインはFlashだし)なWebアプリです(・ω・)

ツイートする

Permalink | コメント(0) | トラックバック(0) | 20:29

■[Work]階層型チーム、機能別チームが唯一のものだなんていうのは完全な思い込みにょ

外科チーム型というか、チーフプログラマを中心に置いて最適化した体制というのは、日本でも昔からあったと思いますよ(・ω・)？

PMの判断で、それが有効だと判断したからそういう体制にしているだけで。

まあ、外部的な体制や進捗の見せはまた別物だったりすることもあるので、そう認識されていないだけかもしれませんが(´д｀;)

大規模なプロジェクトでは無いんじゃない、みたいな疑問もありますが、そんなこともなく。

むしろ、火を噴いた大規模プロジェクトにチーフプログラマ型のチームを投入して鎮火したんだぜ〜、みたいな武勇伝を語るオサーンPMも居たりしますね(・ω・)

それは自慢する所じゃなくて、それが有効なら最初からそうしていろよ、っというツッコミポイントだと思いますけどね(´д｀;)

あと、同じようにクロスファンクショナルなチームというのも昔からありますよね(・∀・)

それは特殊な事ではなくて、状況に応じて、何が本当に有効かなのかを判断しているだけの話だと思います。

まあ、外部的な見せは別としてｗ

ツイートする

Permalink | コメント(0) | トラックバック(0) | 17:59

■[Work]別にデスマっているわけではなく、一般論についてですが

よく、プロジェクトの規模について大規模だの小規模だの言ったりするけど、世間一般の共通認識とかってるんですかね(・∀・)？

人の話を聞いていると、規模の定義についてコンセンサスが得られないまま話を進めている事も多いような気がして。

自分の感覚で言うと、金額ベースでこんな感じだったりしますが(・ω・)

• 大規模(500,000k〜)
• 中規模(50,000k〜)
• 小規模(それ以下)*1

指数なカンジ？

まあ、人月な話でスマンけど、40人*12.5ヶ月と考えると5億つってもたいしたことは無い気もするので、その倍くらい〜を想定しても良いかもしれませんが(´д｀)*2

あと、デスマーチって言葉もよく使われているけど、これはヨードンの定義があるので、それにのっとて欲しいな〜とは思ったり(・ω・)

仕事がつまらないだけの状況をデスマとか言わないように。

スコープを操作する余地が無い仕事は、パラメータの差異が50%以内でもつまらないかもしれんけど(´д｀;)

で、明日は昼から渋谷。

ちなみに、PCの不具合はメモリだけの問題では無いかも…(´・ω・`)

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:49

■[Work]重量級プロセスで形式重視な案件をやってきたSI屋と、スピードと変化への対応を重視で軽量級なプロセスを使ってきたWeb屋が、不況な世の中で仕事をコンバートしようとした時の注意点(;´Д｀)

自分は今日から仕事始めなのですが、まあ、世の中の状況も絡めて少し。

この不況の中、SI屋、Web屋の仕事も減ってくるわけですが。

SI屋の金融・製造方面の影響はこれから目立ってくるでしょうし、組み込みとか、メーカー系にぶら下がっている所は、去年のうちから既に人減らしが始まっていたりしますが(;´Д｀)

っで、人が帰されたり、新規の仕事が取れなくなってくると、やる仕事をコンバートしていこう〜なんて話になったりします(・ω・)

今まで官庁系や金融系の業務をやっていたSI屋が、Web 2.0的な仕事に手を出してみたり、逆に、Web屋が仕事が取れなくなってきて、大手SI屋の下請けを始めたりとか。

技術面では似たような事をやっているので、コンバート可能だと考えやすいですが、そう単純な話でもなくて。

テクニカルな部分については重なるところもありますが、考え方を変える必要のある部分もあったりして、この辺の事は前にも少し触れていますが(・ω・)

テクニカルな事とは別に、意志決定の仕方や見積もり、お金の稼ぎ方なんかでも違う部分があったりして。

その辺を認識していないと危険ですよ!!( ﾟдﾟ)、っというわけで、ありがちな話を少し。

プロセス

いわゆるSI系の案件と、Web系の案件では考え方に大きく違う部分があると思っていて。

それは何かというと、スピード感というか。

Web系の案件ではスピードと変化への対応が最も重要で優先度が高くて。

その為には無駄な事はやらない、結果重視、プロセスも軽量化という感があるのに対して。

SI系の案件の場合、品質が最も重要、その為にプロセスも重量化、形式的な作業も給料のうち、っという考え方があると思ったり(・ω・)

リスクに対する考え方も、軽量級プロセスの場合はリスクドリブンでより主体的にリスクを潰しにいきますが。

重量級プロセスの場合、スコープを明確化することでリスクの責任回避をしたりしますよね。*1

っで、案件によってこの辺の考え方の違いがあることを認識しておかないと、リスクを全部押しつけられたり、後になって不明確だった部分の責任を取らされたりということもあるので、気をつけましょうねということで(´Д｀)

見積もり

っで、その辺の違いをあまり意識せずに見積もりを行ってしまうと、想定外の作業で工数を喰ったり、目的に対して必要以上に工数をかけて赤字になったりという危険がありますよ、っというのが今日のメインなお話(・ω・)

「形式重視な仕事」をメインでやってきた人達が「スピードと変化への対応を重視な仕事」をやる場合、目的に対して必要以上に工数をかけてしまって赤字になるというパターンが良くあります(;´Д｀)

大規模な案件の中で作業者をやっていると、形式的にやっている作業も給料のうちというわけで、その作業が本質的に必要なものかどうかを考えなくなるきらいがあったりするからですね(・ω・)

その感覚でスピード重視の案件をやってしまうと、本質的に必要の無い作業に無駄な工数をかけて赤字になってしまうので、スピード重視の案件ではまず最終的な動くシステムをイメージして、その為に必要な作業のみをやるようにする必要がありますネ(・∀・)

あるいは、上流工程(笑)分の工数を積み過ぎて、金額が高くなって仕事を取れないっていうパターンの方が多いかな(ﾟдﾟ)？

っで、それとは逆に「スピードと変化への対応を重視な仕事」をメインでやってきた人達が「形式重視な仕事」をやる場合、想定外の作業が発生してトラブルというパターンが良くありますね(;´Д｀)

大規模案件の場合、生産性よりも作業の定型化、均質化、形式化で仕事を進めようとします。

そこを理解せずに、今までの自分達のやりかたを基準にして見積もってしまうと、必要とされる作業に漏れが出てトラブってしまいます(´・ω・`)

今まで生産性やスピードを重視してきた人達が形式重視な仕事をやる場合、いっそ「誰も読まないドキュメントを書くのも給料のうち」みたいに割り切った方が精神衛生的には良いかもしれません(・ω・)

あと、想定外の作業によるリスクを回避するためには、レビューとかはフェーズの最後に1回やるのではなくて、ディレクションが間違っていないかを確認する為に、フェーズ内の複数のチェックポイントでやるようにしてください(´Д｀)

まあ、これまでと違うパターン(商流って言っても良いかも)の仕事をするときは、自分達のそれまでのやりかたを基準にするのではなく、顧客やプロセスなんかを良く判断して見積もる必要があるというお話です。*2

品質

ついでに品質についてもチョコっと(・ω・)

「品質」っていう言葉も、スピード重視な案件と形式重視な案件では意味が違ったりするので要注意デス。

スピードと変化への対応が重視な案件の場合、(変化に対応するため)スピードに最適化すると、必然的に品質もあがらざるを得ないという風な考えで、構成管理の改善やEoD、テスタビリティの向上の事を指していたりしますが(・∀・)

形式重視な案件の場合、フェーズゲートで要件をきちっと決めてこそ品質はあがるという幻想(?)をベースとするので、スピードと品質は相関関係ではなく逆相関になっていると考えている人も多いから注意が必要ですξ(`・3・)＜うぜーぜ

まとめ

とりあえず、利益(原価や粗利でも良い)を意識せずに仕事ができるのは小学生まで(#ﾟДﾟ)

っで、技術的には同じような事をやっているからといって、それだけでは単純に見積もりはできなくて。

必要とされるプロセスによって、案件ごとにその分をちゃんと増減した見積もりを作る必要があるよという、そんなお話ですた(・∀・)

あと、この辺は、発注側も気をつけるべき内容で、発注先が今までどちらの仕事をメインにしてきたのかを理解していないと、トラブルが発生した時に結局困るのは発注側なんでね(・ω・)

ツイートする

Permalink | コメント(0) | トラックバック(0) | 23:06

■[Work]今年のお仕事の総括も近いうちに

次のお仕事も決まったので、年内はその準備をしつつ、穏やかなお正月を迎えらるように(・∀・)

今度作るのは、管理用のWebアプリ、バッチ、SocketサーバをJavaでという構成なカンジですが。

Socketサーバとか、昔はC++でコレ系をメインにやっていたりもしたんですが、最近はWebばかりだったので、こういうのをやるのはお久しぶりんこで。

ちょっと、MINAとかNettyも見てみようかな〜とか思ったりしていたり(・∀・)

アプリ全体としては、やること自体はそんなに難しくないと思うんだけど、既存システムの流儀に従わないとならない部分が多いと、ちと面倒になりそうな予感もあったりしますが(´・ω・`)

既存システムの資料を見たけど、有設定Strutsとか、手書きDAOっぽい内容だったので(´Д｀;)

5年前ならともかく、今となってはタルいというか、冗長な書き方をしなくてはいけなくてストレスを感じそうな気も*1。

で、昨日は夜は忘年会なので、適当に資料に目を通したところまでで終了(・ω・)

来週はリスクリストを作ったり、機能面をブレークダウンして完成イメージを高めたり…というあたりをやりますか。

プロジェクトのキックオフもあるのかな？

そんなことをしているうちに、年内のお仕事は終了となる予定。

5月くらいから総合テストの予定ですが、年が明けてからはアーキテクチャ検証したりプロトを作ったりという所からですかね(・ω・)

ツイートする

Permalink | コメント(0) | トラックバック(0) | 15:47

■[Work]ちょっとお説教タイム(´・ω・`)

時々勘違いしている人がいるけど、いわゆる製造工程で行うのは、ロジックをプログラムの制御構造に落とし込んだり、画面の構成要素とデータのバインディングだとか、後は量産するだけの作業だからね(・ω・)

フレームワークの準備とか、アーキテクチャの決定とかは、要件定義の段階ではじめるものだよ。

ギリギリになって泣きつかれても助けないからね。

「アーキテクチャ不在」によるプロジェクトの失敗なんて、プロジェクトの失敗理由としては下の下だからね(゜Д゜#)

ちなみに、よくプロジェクトの失敗をプロジェクトマネジメントのせいにしているケースがあるけど、そのうちの何割かについては、失敗の真因は「アーキテクチャ不在」だなんてこともあったりして( ´,_ゝ`)

まあ、それ以前に、だ。

• ちゃんとタスク管理している？
• じゃあ、あとどれだけの工数を消費すれば終わるのか言ってみて
• 予測工数を出せないところがあるとしたら、その理由はなに？
• どうすればそれがはっきりするの？

今更基本的なことが出来ていないと、お母さん怒るよ(｀Д´)!!

ツイートする

Permalink | コメント(0) | トラックバック(0) | 20:48

■[.NET][Work]まだアーキテクチャ検証とロジックの抽出フェーズ

新しい仕事の土台を作り始めている今日この頃ですが(・∀・)

データアクセスについてはLINQを使うけど、LinqDataSource使わない方針で。

結局、ObjectDataSourceを使うところはあるので、そちらに統一(・ω・)

コンテナについては、今回、Unityを使ってみようかと思い、調査実験したりインテグレーション用のクラスまで作ったのだけれど、やっぱりSpring.NETでいこうかと考え中。

オブジェクトの管理だけなら別にUnityでもいいんだけど、Springの方が多少オマケがあるかな(・ω・)？、ってくらいの判断で。

ちなみに、with ASP.NETでSpring.NETを使うのは初。

クライアントアプリではコソーリ使っていたりはするけれど。

インテグレーションに関しては、Spring.Webをそのまま使いはしないかも(・ω・)

その他の必要そうな機能に関しては、Flashな仕組みもあった方が良いかなと。

結果だけ表示する画面とか用に。

ASP.NET MVCにはTempDataなんかがあるけど、ちょっと仕掛けを用意しようかなっと(´∀｀)

今回新規に試すこともいくつかあるけれど、60画面くらいだし、そんなにたいしたアプリではないかも。

っというわけで、マターリ進行中ヽ(´ー｀)ノ

ツイートする

Permalink | コメント(0) | トラックバック(0) | 20:29

■[Work]イントラなシステムではページ駆動で良いんだけど、コンシューマなサイトの場合は綺麗なURL(SEOに対応してRESTfulっぽくてユーザフレンドリー)が必須

URL設計があまり進んでいないようなので引き取ってみる。

300画面*2(PC/携帯)ということで、いつもの10倍くらいのボリュームがあるのだけれど(´・ω・`)

画面遷移図からユースケースを拾って、URL及びアクションクラスの一覧(with メソッド)を作っていくという、地味に面倒な作業(・ω・)

単純に画面に1:1というわけでもなく、更新処理だとかPOST用のURLも拾わないといけないし。

他にも画像の生成や他サイトへのプロキシーだとか、画面には対応しないものも(Ajax用のはまた別途)。

90画面分ほど作業したところで飽きた( ﾟдﾟ)

今週中には終えたいけどな〜(´ー｀)

ツイートする

Permalink | コメント(0) | トラックバック(0) | 21:21

■[雑][Work]またキナ臭くなってきた...

• トータル○億(HW込み)
• 2008上期中(2009年度版なのでスケジュール厳守)
• 余所がゴメンナサイしたものです
• フロントJava、バックエンドASP.NET
• 想定ユーザ数はバックエンド10,000、フロントは…*1
• 要件は『ほぼ』Fixしているから(^Д^)
• 4月からはバリバリ作るぉ(・ω・ﾉ)ﾉ
• まだ要員の調達ができてないんだけどネ(*^-^*)ゞ

( ﾟдﾟ)ﾎﾟｶｰﾝ

• っというわけで、3月中にアーキテクチャ設計してね(´３｀)

工エェェェΣ(゜Д゜；)ェェェエ工

ツイートする

Permalink | コメント(0) | トラックバック(0) | 21:29