▼ブログマップ
▼その他
・・・・・・徒然な感じで思いついたことを書いてます。
▼勉強
・・・・・・挫けず継続できるように、勉強の記録を残しています。
▼仕事
・・・・・・仕事に関する内容を書いています。
▼企画
・・・・・・自由な感じで勝手に企画します。
▼資料
・・・・・・なんと言いますか、資料です。備忘録かな。
▼その他
・・・・・・徒然な感じで思いついたことを書いてます。
▼勉強
・・・・・・挫けず継続できるように、勉強の記録を残しています。
▼仕事
・・・・・・仕事に関する内容を書いています。
▼企画
・・・・・・自由な感じで勝手に企画します。
▼資料
・・・・・・なんと言いますか、資料です。備忘録かな。
先ずWBS作ってよ、の意味が理解できない。
最初に断っておきます。
僕は、WBSという言葉に対し、マイノリティな解釈をしているようです。
僕としては正しいと思って理解しているんですけどね。
WBSは、「Work Breakdown Structure」の頭文字です。
Work(=仕事・作業)をBreakdown(=分割)したStructure(=構成・構造)なんです。
で、ここから僕のマイノリティな解釈の説明が始まります。
Workには、当然ながら目的があります。
その目的を果たすため、組織、つまりOrganizationが形成されます。
Workを成功させるため、つまり目的を果たすため、何が必要なのかを考えます。
目的を果たすため、Workを分解するのです。
この時に最も重要なことは、目的を果たすために分解したWorkと、それらWorkの関連です。
分解したWorkを縦軸に並べる前に、それらWorkの関連を描くんです。
この時点では、未だWBSを作成する行為ではありません。
目的を果たすための過程、つまりProcessを描くのです。
Processを描くことでアウトプットされるものは、PFD(Process Flow Diagram)です。
PFDがアウトプットされることで、得られる情報があります。
それは、目的を果たすために必要な役割、つまりRoleです。
導き出されたRoleに準じ、Organizationを分解します。
分解したOrganizationは、Roleに準じて構成されているはずで、分解したWorkが割り当てられています。
この関係が非常に重要です。
分解したOraganizationとRoleは対になっており、分解したWorkがあるんです。
Roleに準じたOrganizationは、それら独自でさらなるWorkを定義できます。
Roleの定義が揺るがない限り、Organizationは独立します。
分解したOrganizationごとでさらなるPFDをアウトプットできるのです。
Roleの定義が揺るがないという条件は、大元のPDFの確立を意味します。
そして、Roleに準じたOrganizationも確立します。
この時点で、OBS(Organization Breakdown Structure)が完成します。
OBSが完成して始めて、WBSの作成ができます。
Organizationが持つWorkこそが、ワークパッケージとなるのです。
ワークパッケージの定義をOrganizationが行うことで、WBSが完成します。
簡単に走り書きしてしまいましたが、、、
てか、図で説明したい・・・
えっと、わかりますでしょうか？？
説明が下手過ぎて申し訳ないことこの上ないんですが・・・。
WBSでスケジュール管理しているプロジェクトって、火を吹いてませんか？
それはWBSの使い方が間違っているからです。
PFDに基づいてスケジュールが管理されるべきだからです。
大規模な組織を作っちゃって、風呂敷を広げすぎて、火を吹いていませんか？
それはPFDに基づいたRoleを正しく定義できていないからです。
若しくは、Roleに準じたOrganizationを形成していないからです。
WBSありきで形成されたOrganizationほど脆く儚いものはありません。
OBSあってこそのWBSなんです。
タスク一覧イコールWBSなんて言ってて、火を吹いていませんか？
タスクの属性としてWBSがあるのであって、イコールではないです。
WBSはWorkの構造体だと認識すべきです。
ワークパッケージとタスクの違いを意識すべきです。
僕は火を吹いているプロジェクトが好きです。
なんでだろう？
きっと、自分の考えが正しいって思えるからかもしれません。
自分の考えと違ったやり方してるから、火を吹いてるって思えるんです。
いつか、自分の考えに基づいてプロジェクトを遂行してみたいです。
それで火を吹いたら、さすがに言い訳できないですけどねｗ
僕は、WBSという言葉に対し、マイノリティな解釈をしているようです。
僕としては正しいと思って理解しているんですけどね。
WBSは、「Work Breakdown Structure」の頭文字です。
Work(=仕事・作業)をBreakdown(=分割)したStructure(=構成・構造)なんです。
で、ここから僕のマイノリティな解釈の説明が始まります。
Workには、当然ながら目的があります。
その目的を果たすため、組織、つまりOrganizationが形成されます。
Workを成功させるため、つまり目的を果たすため、何が必要なのかを考えます。
目的を果たすため、Workを分解するのです。
この時に最も重要なことは、目的を果たすために分解したWorkと、それらWorkの関連です。
分解したWorkを縦軸に並べる前に、それらWorkの関連を描くんです。
この時点では、未だWBSを作成する行為ではありません。
目的を果たすための過程、つまりProcessを描くのです。
Processを描くことでアウトプットされるものは、PFD(Process Flow Diagram)です。
PFDがアウトプットされることで、得られる情報があります。
それは、目的を果たすために必要な役割、つまりRoleです。
導き出されたRoleに準じ、Organizationを分解します。
分解したOrganizationは、Roleに準じて構成されているはずで、分解したWorkが割り当てられています。
この関係が非常に重要です。
分解したOraganizationとRoleは対になっており、分解したWorkがあるんです。
Roleに準じたOrganizationは、それら独自でさらなるWorkを定義できます。
Roleの定義が揺るがない限り、Organizationは独立します。
分解したOrganizationごとでさらなるPFDをアウトプットできるのです。
Roleの定義が揺るがないという条件は、大元のPDFの確立を意味します。
そして、Roleに準じたOrganizationも確立します。
この時点で、OBS(Organization Breakdown Structure)が完成します。
OBSが完成して始めて、WBSの作成ができます。
Organizationが持つWorkこそが、ワークパッケージとなるのです。
ワークパッケージの定義をOrganizationが行うことで、WBSが完成します。
簡単に走り書きしてしまいましたが、、、
てか、図で説明したい・・・
えっと、わかりますでしょうか？？
説明が下手過ぎて申し訳ないことこの上ないんですが・・・。
WBSでスケジュール管理しているプロジェクトって、火を吹いてませんか？
それはWBSの使い方が間違っているからです。
PFDに基づいてスケジュールが管理されるべきだからです。
大規模な組織を作っちゃって、風呂敷を広げすぎて、火を吹いていませんか？
それはPFDに基づいたRoleを正しく定義できていないからです。
若しくは、Roleに準じたOrganizationを形成していないからです。
WBSありきで形成されたOrganizationほど脆く儚いものはありません。
OBSあってこそのWBSなんです。
タスク一覧イコールWBSなんて言ってて、火を吹いていませんか？
タスクの属性としてWBSがあるのであって、イコールではないです。
WBSはWorkの構造体だと認識すべきです。
ワークパッケージとタスクの違いを意識すべきです。
僕は火を吹いているプロジェクトが好きです。
なんでだろう？
きっと、自分の考えが正しいって思えるからかもしれません。
自分の考えと違ったやり方してるから、火を吹いてるって思えるんです。
いつか、自分の考えに基づいてプロジェクトを遂行してみたいです。
それで火を吹いたら、さすがに言い訳できないですけどねｗ
近況報告。
いやはや、久しぶりとなってしまいました。
近況報告をば。
2009年6月から参画したプロジェクト、こいつが火だるまでして。
もともとC社がやってたんだけど、どうにもこうにも最悪な事態に陥ってしまい、超部分リリースしてみたもののそれすらもダメダメで、結局T社が巻き取る格好となりました。そのT社としてこのプロジェクトに入りました。
6月の一ヶ月間は、C社の要件定義内容を把握し外部仕様に則ったテスト仕様を固める、という任に就きました。しかーし！！要件定義が記されたドキュメントが500ファイル以上もある！！しかも全然整理とかされてないし！！それはそれは大変過酷な作業でした・・・。
7月からは本格的な巻き取りが開始。で、僕は政治的な理由からDBAに就任。7月半ばまでは色々手探りでシステムテストという名のデバッグ作業の支援をしていましたが・・・。
ついに7月半ばごろ、最終顧客のお偉い様が動きだしたのでした。
システムテストを顧客主導でやる、と。
いや、それ、蓋開けちゃうとデバッグですよ～・・・
やばいですよ～・・・
・・・
最終顧客の皆様、全員激怒。
その日から家に帰れなくなりました。
なんせ動かない。
ログイン画面が表示されない。
常駐バッチが常駐してくれない。
マスタデータがない。
ありえない。
仕様書と呼ばれている詳細設計書というタイトルのドキュメントを見てみる。
検索ボタンを押す→データベースを検索する→画面に表示する
1分ごとにデータを検索する→データがあれば処理する
これじゃ使い物にならない。
と、そんな砂漠に一本一本ながら木を植え水をやり・・・
やっと、やっと、なんとか動くようになってきました！！
で、今日に至る。
明日から9月。
明日からちゃんとしたDBAの人がくるらしいです。2人も。
今まで一人でDBAやってて大変でした。
Oracle11ｇ初めてだっつーのに表領域暗号化しろだのなんだの・・・。
開発環境のデータベースをシステムテスト環境と一緒にしてくれだの・・・。
本番環境にデータベース構築してこいっつって出張させるだの・・・。
ひどいときには作ったデータが正しいかどうかSQL作って検索してくれだの・・・。
あー。
愚痴がいっぱい。
文章が支離滅裂。
こうやって書き殴るなんて、すごい久しぶり・・・
まぁ文章力もともとないから違和感ないけどｗ
とにかく、忙しかった、そしてなんとか家に帰れるようになった、
だから、そろそろ人間になりた～い。
そんだけです。
明日からまた頑張るぞっと。
近況報告をば。
2009年6月から参画したプロジェクト、こいつが火だるまでして。
もともとC社がやってたんだけど、どうにもこうにも最悪な事態に陥ってしまい、超部分リリースしてみたもののそれすらもダメダメで、結局T社が巻き取る格好となりました。そのT社としてこのプロジェクトに入りました。
6月の一ヶ月間は、C社の要件定義内容を把握し外部仕様に則ったテスト仕様を固める、という任に就きました。しかーし！！要件定義が記されたドキュメントが500ファイル以上もある！！しかも全然整理とかされてないし！！それはそれは大変過酷な作業でした・・・。
7月からは本格的な巻き取りが開始。で、僕は政治的な理由からDBAに就任。7月半ばまでは色々手探りでシステムテストという名のデバッグ作業の支援をしていましたが・・・。
ついに7月半ばごろ、最終顧客のお偉い様が動きだしたのでした。
システムテストを顧客主導でやる、と。
いや、それ、蓋開けちゃうとデバッグですよ～・・・
やばいですよ～・・・
・・・
最終顧客の皆様、全員激怒。
その日から家に帰れなくなりました。
なんせ動かない。
ログイン画面が表示されない。
常駐バッチが常駐してくれない。
マスタデータがない。
ありえない。
仕様書と呼ばれている詳細設計書というタイトルのドキュメントを見てみる。
検索ボタンを押す→データベースを検索する→画面に表示する
1分ごとにデータを検索する→データがあれば処理する
これじゃ使い物にならない。
と、そんな砂漠に一本一本ながら木を植え水をやり・・・
やっと、やっと、なんとか動くようになってきました！！
で、今日に至る。
明日から9月。
明日からちゃんとしたDBAの人がくるらしいです。2人も。
今まで一人でDBAやってて大変でした。
Oracle11ｇ初めてだっつーのに表領域暗号化しろだのなんだの・・・。
開発環境のデータベースをシステムテスト環境と一緒にしてくれだの・・・。
本番環境にデータベース構築してこいっつって出張させるだの・・・。
ひどいときには作ったデータが正しいかどうかSQL作って検索してくれだの・・・。
あー。
愚痴がいっぱい。
文章が支離滅裂。
こうやって書き殴るなんて、すごい久しぶり・・・
まぁ文章力もともとないから違和感ないけどｗ
とにかく、忙しかった、そしてなんとか家に帰れるようになった、
だから、そろそろ人間になりた～い。
そんだけです。
明日からまた頑張るぞっと。
エクセルで頑張らないで欲しいのです。
なんだか久しぶりのブログ更新となっちゃいました。
よく考えれば、三日坊主の僕がこんなに続くこと自体が奇跡なのです。まぁ、とりあえず、今後もこんなペースでノラリクラリとやってきますわ。
さて、エクセルで頑張らないで欲しいのです。
要件定義書、基本設計書、詳細設計書、テスト仕様書、なんでもそう。課題管理表、タスク一覧、QA一覧、こいつらもそう。他にもあるでしょう。エクセルで頑張ってる資料。納品物にせよなんにせよ。
あのですね、エクセルの使い方、間違ってるときありませんか？
よーは、エクセルで半ば強引に管理している情報、それらほっとんどが2次元で表現できる情報ではないでしょーか。そしてその情報へのアクセスは複数のメンバだったりして、それらメンバが参照や追加や更新や削除をするんじゃないでしょーか。
エクセルは資料を作る上で途轍もない威力を発揮してくれます。
ただ、上述のような情報管理には必ずしも適してはいないのです。
決してエクセルを否定しているわけではありません。
エクセルに共有の機能があることくらいは知っています。
ソートできるのもしってますし、フィルタもかけられますね。
他シート(他ブックも含め)への参照関係も築けます。
様々な関数も提供されていて、わりかし便利です。
ただ、わざわざエクセルでやる必要ありますか？
そんなとき、なぜにRDBMSを使わないのですか？
OracleでもMySQLでもPostgreSQLでもFireBirdでも、Accessでもいいんです。SQLiteでもJavaDBでもいいんです。
使い勝手のいいGUIツールさえあれば、RDBMSの導入を検討した方が良いです。
ただ、もちろん資料を作るという意味ではエクセルは良いです。だから、RDBMSで管理しているデータをエクセルに反映させることができれば良いと思うんです。そんなに難しいことじゃないはずですし。
いや、なんでこんな話になったかと言いますと、今の現場、エクセルで頑張り過ぎてて大変なことになってるんです。デグレしまくり、セル結合しまくり、誰かが更新中で待ち状態発生あり、勝手に「xxx_new.xls」なんてファイルを作ってしまってさあ大変、てなことになってるんです。
なにやってんだか・・・。
まぁ、そんなこんなで、僕はどこの現場でもやってることですが、開発環境にあるOracleやローカルPC上のAccessなど、そういったRDBMSを使って楽しましょう。
てことで、久々更新は愚痴でしたー。ｗ
よく考えれば、三日坊主の僕がこんなに続くこと自体が奇跡なのです。まぁ、とりあえず、今後もこんなペースでノラリクラリとやってきますわ。
さて、エクセルで頑張らないで欲しいのです。
要件定義書、基本設計書、詳細設計書、テスト仕様書、なんでもそう。課題管理表、タスク一覧、QA一覧、こいつらもそう。他にもあるでしょう。エクセルで頑張ってる資料。納品物にせよなんにせよ。
あのですね、エクセルの使い方、間違ってるときありませんか？
よーは、エクセルで半ば強引に管理している情報、それらほっとんどが2次元で表現できる情報ではないでしょーか。そしてその情報へのアクセスは複数のメンバだったりして、それらメンバが参照や追加や更新や削除をするんじゃないでしょーか。
エクセルは資料を作る上で途轍もない威力を発揮してくれます。
ただ、上述のような情報管理には必ずしも適してはいないのです。
決してエクセルを否定しているわけではありません。
エクセルに共有の機能があることくらいは知っています。
ソートできるのもしってますし、フィルタもかけられますね。
他シート(他ブックも含め)への参照関係も築けます。
様々な関数も提供されていて、わりかし便利です。
ただ、わざわざエクセルでやる必要ありますか？
そんなとき、なぜにRDBMSを使わないのですか？
OracleでもMySQLでもPostgreSQLでもFireBirdでも、Accessでもいいんです。SQLiteでもJavaDBでもいいんです。
使い勝手のいいGUIツールさえあれば、RDBMSの導入を検討した方が良いです。
ただ、もちろん資料を作るという意味ではエクセルは良いです。だから、RDBMSで管理しているデータをエクセルに反映させることができれば良いと思うんです。そんなに難しいことじゃないはずですし。
いや、なんでこんな話になったかと言いますと、今の現場、エクセルで頑張り過ぎてて大変なことになってるんです。デグレしまくり、セル結合しまくり、誰かが更新中で待ち状態発生あり、勝手に「xxx_new.xls」なんてファイルを作ってしまってさあ大変、てなことになってるんです。
なにやってんだか・・・。
まぁ、そんなこんなで、僕はどこの現場でもやってることですが、開発環境にあるOracleやローカルPC上のAccessなど、そういったRDBMSを使って楽しましょう。
てことで、久々更新は愚痴でしたー。ｗ
IT業界のK。
IT業界のKに歯向かってみようかと思い。
わてらの業界は3Kなどと言われ、どうにもこうにも新卒採用が難航してみたり、色々と大変な感じなのです。
IT業界の3Kとは、以下のことらしいです。
・きつい
・帰れない
・給料が安い
さらに以下4つを加えて7Kなんて表現もあるらしいです。
・休暇が取れない
・規則が厳しい
・化粧がのらない
・結婚できない
(http://ja.wikipedia.org/wiki/3K)
それでは、その7Kな業界に身を投じている側からの経験談をば。
▼きつい
正直、きついです。ｗ
えと、仕事の負荷がピークの時なんて、きっついきっつい。他のKとの合せ技になりますが、あまりにきつくて帰れない、休暇が取れない。こうなってくると、恐らくは化粧がのらないでしょうし、結婚できないってのもあるかもしれません。但しこの場合、給料が安いっていうのはトレードオフな関係かなと感じています。裁量労働制じゃない限りは。
で、逆に、仕事がない時期が数ヶ月続く、なんてことも平気であります。これはこれで、わりときっついです。作業ないから出勤するの嫌になるし、残業無くなるから給料が安くなるし。
▼帰れない
きついで既出です。ピーク時、帰れません。事実です。
▼給料が安い
きついで既出ですが、ちょっと補足。基本的にこの業界、残業加味した給与体系なことが多いです。なので、仕事がない時期の給料はひどい安いです。ただ、逆に、ピーク時の給料は結構良いです。
但し、裁量労働制というのもあります。ようは年定額制みたいなもんです。この場合、どんだけ仕事なくても、どんだけ徹夜しまくっても、基本的には給料が変わりません。後者の場合、給料が安いと感じることウケアイ。
▼休暇が取れない
きついで既出です。休日出勤の振替ですら困難なこともあり。
▼規則が厳しい
これは業界問わず大体同じだと思ってます。ただ、この業界は機密情報を取り扱うことが多いため、それが故の規則だの何だのってのはあります。ただ、当たり前のことだと思いますけどね、そのほとんどが。
▼化粧がのらない
きついで既出です。僕はお化粧しないのでわかりませんけども。
▼結婚できない
これも業界問わずでしょう。ピークがずっと続いてる人は、確かに婚期逃してる感ありますけどね。IT業界に限ったことではない気がします。
この業界が好き過ぎて結婚まで手が回らない人っていうのは、います。ただ、この業界だからってわけじゃないと思いますけど。
てことで、冒頭で歯向かうって言っておきながら、すべてのKを受け入れてしまう結果となりました。ｗ
じゃなくて。
ピーク時の話に特化していたり、トレードオフなものがあったり、そもそも業界特化じゃないっぽいのもあるので、一概に7Kだなんて言えない気もしています。
では、新しい提案をしてみるﾃｽﾄ。
・好奇心(Curiosity)をくすぐられる
・コミュニケーション(Communication)とりまくり
・創造的(Creative)な仕事
そう！この業界は3Cでもあるんです！
日々進化する技術に魅了され、好奇心をくすぐられちゃう。
しかもIT業界はコミュニケーションが肝。PCと向き合って一日中パチパチやってるなんてことは稀です。むしろ、顧客やメンバとのコミュニケーション無くして仕事は進まないのです。
そして何より！
なんと創造的な業界であるか！
顧客の要件を具体化し、この世に2つとないものを創り上げる、そんな誇り高き仕事なのだ。もちろん、新しい技術の研究だって創造的なのだ。
てことで、7K3Cです。
あと4つCがないとイーブンにならんなぁ。
え？オチ？
ないない、そんなの。ｗ
わてらの業界は3Kなどと言われ、どうにもこうにも新卒採用が難航してみたり、色々と大変な感じなのです。
IT業界の3Kとは、以下のことらしいです。
・きつい
・帰れない
・給料が安い
さらに以下4つを加えて7Kなんて表現もあるらしいです。
・休暇が取れない
・規則が厳しい
・化粧がのらない
・結婚できない
(http://ja.wikipedia.org/wiki/3K)
それでは、その7Kな業界に身を投じている側からの経験談をば。
▼きつい
正直、きついです。ｗ
えと、仕事の負荷がピークの時なんて、きっついきっつい。他のKとの合せ技になりますが、あまりにきつくて帰れない、休暇が取れない。こうなってくると、恐らくは化粧がのらないでしょうし、結婚できないってのもあるかもしれません。但しこの場合、給料が安いっていうのはトレードオフな関係かなと感じています。裁量労働制じゃない限りは。
で、逆に、仕事がない時期が数ヶ月続く、なんてことも平気であります。これはこれで、わりときっついです。作業ないから出勤するの嫌になるし、残業無くなるから給料が安くなるし。
▼帰れない
きついで既出です。ピーク時、帰れません。事実です。
▼給料が安い
きついで既出ですが、ちょっと補足。基本的にこの業界、残業加味した給与体系なことが多いです。なので、仕事がない時期の給料はひどい安いです。ただ、逆に、ピーク時の給料は結構良いです。
但し、裁量労働制というのもあります。ようは年定額制みたいなもんです。この場合、どんだけ仕事なくても、どんだけ徹夜しまくっても、基本的には給料が変わりません。後者の場合、給料が安いと感じることウケアイ。
▼休暇が取れない
きついで既出です。休日出勤の振替ですら困難なこともあり。
▼規則が厳しい
これは業界問わず大体同じだと思ってます。ただ、この業界は機密情報を取り扱うことが多いため、それが故の規則だの何だのってのはあります。ただ、当たり前のことだと思いますけどね、そのほとんどが。
▼化粧がのらない
きついで既出です。僕はお化粧しないのでわかりませんけども。
▼結婚できない
これも業界問わずでしょう。ピークがずっと続いてる人は、確かに婚期逃してる感ありますけどね。IT業界に限ったことではない気がします。
この業界が好き過ぎて結婚まで手が回らない人っていうのは、います。ただ、この業界だからってわけじゃないと思いますけど。
てことで、冒頭で歯向かうって言っておきながら、すべてのKを受け入れてしまう結果となりました。ｗ
じゃなくて。
ピーク時の話に特化していたり、トレードオフなものがあったり、そもそも業界特化じゃないっぽいのもあるので、一概に7Kだなんて言えない気もしています。
では、新しい提案をしてみるﾃｽﾄ。
・好奇心(Curiosity)をくすぐられる
・コミュニケーション(Communication)とりまくり
・創造的(Creative)な仕事
そう！この業界は3Cでもあるんです！
日々進化する技術に魅了され、好奇心をくすぐられちゃう。
しかもIT業界はコミュニケーションが肝。PCと向き合って一日中パチパチやってるなんてことは稀です。むしろ、顧客やメンバとのコミュニケーション無くして仕事は進まないのです。
そして何より！
なんと創造的な業界であるか！
顧客の要件を具体化し、この世に2つとないものを創り上げる、そんな誇り高き仕事なのだ。もちろん、新しい技術の研究だって創造的なのだ。
てことで、7K3Cです。
あと4つCがないとイーブンにならんなぁ。
え？オチ？
ないない、そんなの。ｗ
責任は果たしてなんぼ。
さて、久しぶりのブログアップとなってしまいました。
なんせ、今月から火を吹いているプロジェクトに入ってしまったため、ブログ書いてる場合じゃなくなったんですよね、職場で。
で、責任。
果たしてなんぼです。
ノンフィクションです。
うちの会社にもともと勤怠の悪いやつがいて、そいつがついに無断欠勤をした。自社勤務ならまだしも客先常駐での出来事なので、社長含めて動いた。結局、そいつは体調不良で自宅にいたらしい。携帯にめっちゃ連絡したが応答なかったのは、前日に携帯を紛失していたらしい。
そしてそいつは、これ以上会社にいるともっと迷惑をかけてしまうため退職させて下さい、と言ったらしい。
おかしくね？
まず、詫び入れろ。
迷惑かけたみんなに詫び入れろ。
(少なくとも非常に迷惑を被った僕には詫びのひとつも無い)
で、お前が勝手に処分を決めるな。
迷惑を被った側が処分を決めるべき。
そして下された決断に対し、責任を果たすべくその決断を受け入れるべき。
と、まぁ、口が悪くなっちゃいましたが、これ、本当にノンフィクションです。このご時世、お客様との取引継続だって難しいというのに、辞めちゃいますはねーだろ・・・。
とゆーか、もっと大前提として、社会人になって何年も(4年？5年？)たってんだから、勤怠悪いとか無断欠勤とか、正直信じられない。。
こいつ、自分で退職を言い出したことで責任取った感を醸し出しているのかもしれません。でも、そんなの許せん。正直、根性叩き直した方がいい。
おっと、また口が悪くなった。ｗ
とりあえず、僕が言いたいのは、防げる失敗はなるべくしないようにすること、そして失敗を犯してしまった場合、その失敗から決して逃げ出してはいけないということ。
責任は果たすものです。
無断欠勤のアホくささ以上に、自分の犯した失敗から逃げ出そうとする姿勢にガッカリです。社会人というか、人間としてありえねー。
あ、また口が悪くなった。ｗ
もうやめよう、この話題。ｗ
なんせ、今月から火を吹いているプロジェクトに入ってしまったため、ブログ書いてる場合じゃなくなったんですよね、職場で。
で、責任。
果たしてなんぼです。
ノンフィクションです。
うちの会社にもともと勤怠の悪いやつがいて、そいつがついに無断欠勤をした。自社勤務ならまだしも客先常駐での出来事なので、社長含めて動いた。結局、そいつは体調不良で自宅にいたらしい。携帯にめっちゃ連絡したが応答なかったのは、前日に携帯を紛失していたらしい。
そしてそいつは、これ以上会社にいるともっと迷惑をかけてしまうため退職させて下さい、と言ったらしい。
おかしくね？
まず、詫び入れろ。
迷惑かけたみんなに詫び入れろ。
(少なくとも非常に迷惑を被った僕には詫びのひとつも無い)
で、お前が勝手に処分を決めるな。
迷惑を被った側が処分を決めるべき。
そして下された決断に対し、責任を果たすべくその決断を受け入れるべき。
と、まぁ、口が悪くなっちゃいましたが、これ、本当にノンフィクションです。このご時世、お客様との取引継続だって難しいというのに、辞めちゃいますはねーだろ・・・。
とゆーか、もっと大前提として、社会人になって何年も(4年？5年？)たってんだから、勤怠悪いとか無断欠勤とか、正直信じられない。。
こいつ、自分で退職を言い出したことで責任取った感を醸し出しているのかもしれません。でも、そんなの許せん。正直、根性叩き直した方がいい。
おっと、また口が悪くなった。ｗ
とりあえず、僕が言いたいのは、防げる失敗はなるべくしないようにすること、そして失敗を犯してしまった場合、その失敗から決して逃げ出してはいけないということ。
責任は果たすものです。
無断欠勤のアホくささ以上に、自分の犯した失敗から逃げ出そうとする姿勢にガッカリです。社会人というか、人間としてありえねー。
あ、また口が悪くなった。ｗ
もうやめよう、この話題。ｗ
C/S型とWeb型。
さて、「気軽」に「使いやすい」をモットーにしたITSツール、SmallAdmin。C/S型にしてみようかな、なんて思い始めています。理由は、インターネットに接続できなくても使えるようにしたいためです。
私事ながら(てかブログだから私事でいいんだけど)、今月から現場が変わりますた。で、新たな現場に行ったら、大抵は数日くらいインターネットに接続できないんですよね。手続きだのなんだので。下手したら接続禁止の現場もあるくらいだし。そんな時って、Web型よりC/S型の方が勝手がいいのです。予めPCにインストールしておけばいいんですから。
でも、Web型としても開発したい。基本的にはWeb型の方が何かと便利だったりもするわけですし。
てことで、両方作ることにしようかな。
▼C/S型の構想
Pure Javaを体験してみようかと。
Swing。Java DB。
つまりはJDK1.6系か。
▼Web型の構想
Open JFXに興味あり。
ただ、王道のTomcatでのServlet/JSPもありかな。
DBMSはMySQLかな。
まぁゆーても企画第一弾のMyPortalが先ですけどね。SmallAdminは、早くて7月中旬くらいからボチボチ着手できればいいかな～って思ってます。
通勤時間のお勉強、再開。
さて、通勤時間のお勉強、今はこれです。
ソフトバンクパブリッシング
Javaの哲学
ISBN4-7973-1704-3
もちろん、新たに本を買うお金がないため、これまた本棚から引っ張り出してきた一品です。序章、一章、そして二章を既に読みましたが、独特な感じが僕を惹きつけますね。
しかもポリモルフィズム(多態性、多形性)の説明がかなり前半にある！構文とかの説明なし！どちらかと言うと読み物として成り立っている感じです。
今月中に読みきれちゃうから、もう一冊くらい用意しとかないといけませんね。どうしよっかなー。
ソフトバンクパブリッシング
Javaの哲学
ISBN4-7973-1704-3
もちろん、新たに本を買うお金がないため、これまた本棚から引っ張り出してきた一品です。序章、一章、そして二章を既に読みましたが、独特な感じが僕を惹きつけますね。
しかもポリモルフィズム(多態性、多形性)の説明がかなり前半にある！構文とかの説明なし！どちらかと言うと読み物として成り立っている感じです。
今月中に読みきれちゃうから、もう一冊くらい用意しとかないといけませんね。どうしよっかなー。
その３。気づけば挫折していた。
今年4月から開始した読本読解勉強キャンペーン。通勤時間を有効に使って勉強キャンペーン。今、気づきました。挫折していた自分に・・・orz
てことで、その３の本、読んでません。ｗ
正確には、パーっと斜め読みを数ページしたけれど。正直、読んでないに等しい。てことで、読んでません。
継続は力なり。
継続できないから力がないなり。
敵を知り、己を知れば百戦危うからず。
敵を知ろうとしたが、改めて己の怠慢を知ることに。
よし、違う勉強しよう！ｗ
あ、いや、読本読解勉強キャンペーンは継続しますよ。なんてったって、今月から現場が遠くなったからね！
てことで、その３の本、読んでません。ｗ
正確には、パーっと斜め読みを数ページしたけれど。正直、読んでないに等しい。てことで、読んでません。
継続は力なり。
継続できないから力がないなり。
敵を知り、己を知れば百戦危うからず。
敵を知ろうとしたが、改めて己の怠慢を知ることに。
よし、違う勉強しよう！ｗ
あ、いや、読本読解勉強キャンペーンは継続しますよ。なんてったって、今月から現場が遠くなったからね！
ソフトウェア構成を考えてみた。
とりあえず当面は、以下のようなS/W構成でいこうかなと思いまつ。もちろん、急に気が変わることもあり得ますけどね。
▼S/W構成(ざっくりと概要だけです)
HTTPサーバ：mongrel(1.1.5)
フレームワーク：rails(2.3.2)
DBMS(サーバ)：MySQL(5.0.67)
ちなみに、ruby(1.8.6)のgems(1.3.1)です。
HTTPサーバ、割と悩んでます。どれもこれもよくわかってないだけに、悩むんですよ。Apache＋passengerという選択肢も視野に入れつつ。まぁとりあえず、mongrelにしてみまつ。
あと、開発環境もある程度作っちゃいました。こっからはログを記事に貼っていこうと思ってたんですが、インストール時にログとるの忘れてた。ｗ
よし、次はVer.0.1.0の資料作りぢゃ～！
▼マイルストーンと進捗(2009/6/1(Mon)現在)
2009/05/31(Sun)：S/W構成の概要決定
2009/06/14(Sun)：開発環境構築
2009/06/21(Sun)：Ver.0.1.0の資料作る
2009/06/28(Sun)：Ver.0.1.0試作品作る
2009/07/05(Sun)：Ver.0.2.0の構想固める
2009/07/12(Sun)：Ver.0.2.0の資料作る
2009/07/26(Sun)：Ver.0.2.0試作品作る
新しい現場は少し遠い。
2009年6月より、仕事の現場が新しくなります。
けっこう遠い。。
まぁドアtoドアで1時間15分くらい。
そんな遠いってほどでもない、かもしれませんが。
やることは、他のソフトベンダが作ったソフトを総合的に評価する、ってことらしいです。というか、結合検査フェーズに突入しなければならないのに、品質があまりに悪いため、リファクタリングする的な話でした。
まぁ、正直、どんな仕事でもいいのですが。
とにかく、遠いのは嫌だ・・・。
けっこう遠い。。
まぁドアtoドアで1時間15分くらい。
そんな遠いってほどでもない、かもしれませんが。
やることは、他のソフトベンダが作ったソフトを総合的に評価する、ってことらしいです。というか、結合検査フェーズに突入しなければならないのに、品質があまりに悪いため、リファクタリングする的な話でした。
まぁ、正直、どんな仕事でもいいのですが。
とにかく、遠いのは嫌だ・・・。