CALENDAR
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30     
<<Back 2024年04月 Next>>
LOGIN
現在のモード: ゲストモード
USER ID:
PASSWORD:
NEW ENTRIES
RECENT COMMENTS
■ 奥脇という名前の由来
└ s.okuaki(02/27)
└ hide okuwaki(11/23)
■ ブログを引越しします。
└ okugaku(03/07)
└ yurika(03/05)
└ OFFICE DOYU (03/03)
RECENT TRACKBACK
■ 岸和田観光農園(いちご狩り)
└ 現役栄養士のお仕事日記(04/25)
■ やっと終わった
└ MY Favorite Things(03/19)
■ PDA版にのりかえ
└ 大阪でWEBサイトをプロデュースするということ(01/06)
CATEGORIES
ARCHIVES
LINK
PROFILE
■ 奥脇学(2088)
POWERED BY
script by Blogn+
skin by vivid*face
OTHER
■ RSS 1.0
■ 処理時間 3.51371秒
SEARCH
体重計

なかなか・・・
なかなかむずかしいですね。

今関っているプロジェクトは「一括」という「全てをお任せしました」っていう形を取っておきながら
中身を細かく細かくチェックされるという異常さ。

プロジェクトの進め方が非常に難しいなーと感じています。

もともと今回のプロジェクトは
XXXX->XXXX->XXXX->XXXX->うち、というような一番下っ端なお仕事の頂き方で
直上のところとパートナーとして一緒にやっていっていますが、
そのパートナーさんと、その上のパートナーさんの関係がビミョーで・・・

やっぱり難しいですねー。

| 仕事関係 | 11:01 PM | comments (0) | trackback (x) |
興味深いプロジェクト
実はあるプロジェクトかなり特殊な方法で契約しています。

1ヶ月の作業料だけを決めて、XXXのものを作るのにはおおよそ何ヶ月かかるから、これぐらいの期間ください。
それで出た分は痛み分けということで半々としましょう。

かなりリスキーでチャレンジング!!

初めての試みなので、かなりお安くしてこのような感じでいけるか試しているところです。

この進め方はお客さんと私たちの信頼がないととても出来そうにありません。

幸い、このお客さんはとてもよく理解してくださり、本当に信頼していただきびっくりするほどうまくいっています。

作業量オーバーしても想定ラインから追加ということをお話させていただくと、全額出していただけるようなとっても理解のある会社さんです。

今回はとってもお客さんが良い方なのでうまくいっていますね。

全てがこうなると、私たちの理想に近づくんですが・・・

| 仕事関係 | 11:36 PM | comments (0) | trackback (x) |
ウォーターフォール
さあ、長いぞー。

「ウォーターフォールモデル」(説明はこちら)
システム開発をする上でもっとも基本的な開発方法の一つ。

システム開発を長くやっているが、最初はこの方法しかなかった。

メモリ、CPU、ハードディスクが非常に限られた中で、少しでも無駄なメモリを使用することや、無駄な処理をすること、要らない情報を書き込むこと、これが今の状況では考えられないほど厳密に管理、検討されていた時代だった。

言語もアセンブラという俗にいう「機械語」
メモリの管理がどうなっているのか、どのような処理がCPUを消費するのか、タスクスイッチはどのようなタイミングで発生するのか、理解しないと無駄な処理を作りこんでしまうので、徹底的に教え込まれたものだった。

昔はコンピュータ資源の消費を減らすためなら、どれぐらいの工数をかけてもハードウエア代に比べれば安いものだった。
なので、細部に渡り全てを検討し確実に作りこむことができる開発方法が必要だった。

それで「ウォーターフォールモデル」の様な開発方法が確立されて行き、私達も厳密にこの開発方法通りに開発をしたものだった。

さて何をいいたいか。それは昔はこうだったという話をしているのではない。

まず「ウォーターフォールモデル」の有るべき姿をきちんと考えたいと思う。
今は安直に管理がしやすいということで「ウォーターフォールモデル」で開発している所が多い。

正直私から見れば「馬鹿みたい」(ニュアンスわかりますか?私は大阪人です)にひとつ覚えでしているところは、本当に「なんも考えていないんやなー」って腹立たしくさえ思います。

「ウォーターフォールモデル」は基本をきちんとやっていないととんでもないことになります。
大事な事は
・各工程の定義を明確にして、徹底させる。
・各工程を手順毎にきちんと行う。
・各工程毎に成果物を十分に検討し、一つ一つ確実に確定させて行く。
・仕様変更等の後戻りが発生した場合は、対象部分の上位工程からのすべて見直し、上流工程からの修正を反映させる。
等々。
一番大事な事は、書かれているレベルが統一されていて、手順通り上流工程から下流工程にきちんと流していくということが大事。

私からしてみれば、「XX」の工程での検討時に、その上流工程の「XX」の部分の修正が発生するなんて事は全くありえない話し。
また、工程を飛ばすなんて事もありえない。
そんなことが普通行われているプロジェクトではもう基本的に「ウォーターフォールモデル」という定義から外れていると思う。

さて、ここで考えることは、「こんなことやってたら、時間が思いっきりかかるやん!」
そう、「ウォーターフォールモデル」はきちんと時間をかけてやらないと失敗する。

上流工程であいまいに決めたようなプロジェクトでは、そもそも下流工程にしわ寄せがくるようになっている。

そんな基本的なことも分からないようなプロジェクトに関るのは本当に苦痛このうえない。
ちょうど今がそんな時・・・(ほとんど愚痴やん)

| 仕事関係 | 11:48 PM | comments (6) | trackback (x) |
oyakataさん、コメントお待ちしてましたー。

実は私もそう思っているんですよねーってことで、今日まとめて書いたブログの記事の中にもそういうことを書いています。

とってもタイムリーでした!!

やっぱり考えることは同じなんですかねー。
| okugaku | EMAIL | URL | 2006/06/28 04:17 PM | 5CQqvtUY |


初めてのコメントです。
ウォーターフォールって、経営に似てません?
長いようで案外短い仕事して、生きてる時間を全てあてはめる事はできないと思いますが、経営の仕様書を描く時、私は参考になりました。ありがとう。m(_ _)m
| Oyakata | EMAIL | URL | 2006/06/26 05:24 PM | yKExlGGU |


そうですねー。

皆さんと一緒にぱーっとできる日を心待ちにしています。
| okugaku | EMAIL | URL | 2006/06/25 11:25 PM | A2OGm8ZY |


状況を知っているだけに、うまい言葉が見つかりませんが、本当に体調とメンタルケアだけ気をつけてくださいね。

辛抱が終わったら、一度パーっと行きましょう。垢落としに。

そして、また仕事を・・・。セッセコセッセコ。
| たけだ | EMAIL | URL | 2006/06/25 09:45 PM | IU/vCLYU |


まさかこれに光代さんが反応してくれるなんて。

ソフトウエア開発方法について思ってみました。

体調はやっと戻りつつあります。
また明日からは大変でしょうが、あと2週間ぐらいの辛抱かなと思います。
| okugaku | EMAIL | URL | 2006/06/25 09:59 AM | A2OGm8ZY |


昨日も徹夜だー
昨日も徹夜だったー。はー、しんど。

こちらの見積りの甘さから大変なことになっているが、どうもそれだけではないということが徐々に分かってきた。
なんとなく現状が分かれば対策の仕方もいろいろ考えられるもの。

パートナーさんと毎日の様に時間をかけて対策方法を練っています。

昔なら誰かれ構わずに文句もいっていたところでしょうが、さすがにパートナーさんの立場やら状況やらを考えてしまって今はなかなか言えない状況。

でも誰に言えばいいのか、徐々に分かってきたのでこれからはちょっとはやりやすくなるだろう。
(といってももうすぐ終わりですが・・・)

なんだか久しぶりに作業をしているので、本当に会社員のころ自分が疑問に思っていたこと、こうした方がいいと思っていたこと、再認識するにはうってつけのプロジェクトだった。

そういう意味では、「ちょっと初心にもどれよー」っていう天の声かな?

| 仕事関係 | 11:36 PM | comments (0) | trackback (x) |
キッチンタイマー
私が仕事を効率良く作業できたり、自分の作業量の見積りが、わりと正確にできたりすることができるのは、あるアイテムのおかげ。

それが(パパラパッパラー)「キッチンタイマー!!」(ドラえもん風に!)

作業をしようとするとき、「この作業を60分で」というように目安をつけます。そしてタイマーをスタートさせます。

そうすると自分の目安の時間の狂いや、割り込みが有った場合の時間の狂いなどが分かります。

なので、「XXの場所でXXの時間で作業するときには、作業効率XX%」みたいなことが大体分かって来ます。
もちろん「深夜、割り込みの無いところで、目的に向かってひたすら集中し作業できる」という環境を100%とします。

うちで作業するときは、朝だと「80%」、昼だと「60%」、夕方だと「70%」ぐらい。
外で作業するときは大体それが平均して「30%」ぐらいになります。(私の場合は半分営業、調整作業等が入りますんで)

ただ重要なのは「純粋に作業している時間」だけを計るんではなく、「気になった情報をネットで検索する時間」「トイレに行く時間」「電話で割り込みが入る時間」も含めていれることが重要です。

そうすると、自分の目安とかかっている作業の時間の狂いも分かりますし、あとあと調整できるようにおおよその目安を考えることができます。

それも各プロジェクトの難しさによって100%の作業効率で行った場合に出てくるアウトプットも分かるので、一度100%の作業をしてみたら、全体のおおよその作業時間と言うのはパッと出てくるようになります。

いかに時間を効率良く使うようにするか、苦労して考えたひとつの答えです。

これにはもうひとつ重要なことがあります。
それは明日のネタに取っておきます。

| 仕事関係 | 11:37 PM | comments (0) | trackback (x) |
実務100%
最近、ちょっと仕事にはまって、作業実務が100%になっています。

そうそう、こんな時、いやなんですよねー。

何がいやかって、今までやってきた中で経験上仕事に追われた3〜6ヵ月後は、結構大変になっているんですよねー。

そりゃそうでしょ、営業も、経営も考える時間が取れないんだから、その影響は後に響いて来ます。
作業実務100%は、けっしてストレスにはなりませんが、その先のことを考えると「今やらなければいけない」ことができなくなっているんで、非常に危機感を持っています。

私が作業実務をすること自体、会社に取っては大損失なんだよな。

| 仕事関係 | 11:58 PM | comments (0) | trackback (x) |
すごいなー
今日は朝9:30から東京で打ち合わせ。始発の新幹線にのって行ってきました。

それも今東京での案件が開発を始めているのに、大幅に軌道修正することになりそうだから。

そもそもこのシステムを開発するにあたって、どのように実現すべきかというのをじっくり3ヶ月ぐらいかけて調査検討して、さあ開発という時に「いろいろ考えたんだけど、やっぱりこのシステムの理想ってこうなんだと思うんだね」って感じで。

どうも今のシステム以外のシステムに適用するときに、相手先のシステムに応じていろいろ修正が入るのが理想ではないようです。このシステムは独立して、他のシステムと容易に接続できるようにしたいということです。

こちらからも、いくつか案を出させて頂いておそらく選ばれそうなのが「一から考え直し」っていう一番大変な案。

実はお客さんの新しい要望をお伺いして考えると、技術的な面からみて私としても絶対この方がいい。って思っていました。

でもそうなると、ちょっとお金も期間も結構伸びるし、今までの調査の半分ぐらいは無駄になるし。

お客さんは大変だなーと思っていましたが、それでもこの案を進めようとされているその姿勢にほんと感銘しました。

本当にすごいなーて思うと同時に、なんだか技術者として参加させてもらっていることが嬉しく感じました。

| 仕事関係 | 11:13 PM | comments (0) | trackback (x) |

<<NEXT  PAGETOP  BACK>>