日暮らしSEの日々考慮 〜名古屋でオフショア そしてセレブへ？〜SE業をしている私の特に仕事をしていくなかで考えることなどを記載していきたいと思っております。
|
|
ページ番号とヘッダー/フッターの操作
仕様書も基本的には納品物として扱われる… しかも電子的なものと、紙として印刷したものとなど… 意外とみんなドキュメント作ってる中で、印刷後の事を考慮せずに記載して、 あとで手直しがめんどくさいなんてことはざらにあることですね… そんななかでも忘れがちなのが上記のページ番号。 これがなきゃ何が何の次だかわかんねぇ！！ってことになりかねません。 でも意外と忘れがちなんですよね… あとは気をつけたいところとしては、索引と目次などかな？ 自分が、さらには他の人がどんな文書なら読みやすいかを考えて書くことが 大事ですね。 まぁ大体体裁は決められていたりはしますけど、その体裁も技術の１つとして 覚えていって損はないように思います。 （ただ、各企業さん毎に多種多様な状態はあまり好きじゃないですが… 仕様書言語仕様およびコンパイラみたいなものあるといいのになぁ…）  はい、第二回キックオフということで、仕事先の職場でちいと飲んでから
今は自社にいる茶太郎です♪ 正直帰りたかった（ぉぃ）でも明日少しでも楽に仕事をするためには自社に立ち寄っていきたかった… （※自宅と自社と仕事先から反対の方向です。） まぁでもメールみてBlogってますけど… で、タイトルとここまでの話と全然かんけいない技術的なお話ですが、 VB6からVS2005への移行って皆さん考えてたりしますか？ VB6からVB.netの時にくらべ比較的らくにできるとの情報が公開されていますが、 そこらへんの調査をしてる身からいわせれば否ですね。 使用しているOCXに関してはラッパークラスを作成してくれるなどとありますが、 それが正確に動作することを確認したり、下手にそのラッパークラスを使えば、 VB6の頃のイベントや関数を使用し、VB2005に即した形ではなく、両方の知識を必要とするために、 保守がしずらくなったりすると思います。 そのように、あくまでも移行作業と生産性だけにとらわれてならないような気がします。 また今年度中に新しいVSがでる話もありますし、予算があるから使いきりたいんだよとか 下手にVS2005の開発を行うよりは、次期をまちながら、 移行しやすい修正をしながら機能UPなどの方が費用対効果は高いんじゃないでしょうか？ ただ、あくまでも私個人が入り口ぐらいの感覚で記載していることなので、 確実にとはいえませんので、その点だけご了承ください。  はい、第二回キックオフということで、仕事先の職場でちいと飲んでから
今は自社にいる茶太郎です♪ 正直帰りたかった（ぉぃ）でも明日少しでも楽に仕事をするためには自社に立ち寄っていきたかった… （※自宅と自社と仕事先から反対の方向です。） まぁでもメールみてBlogってますけど… で、タイトルとここまでの話と全然かんけいない技術的なお話ですが、 VB6からVS2005への移行って皆さん考えてたりしますか？ VB6からVB.netの時にくらべ比較的らくにできるとの情報が公開されていますが、 そこらへんの調査をしてる身からいわせれば否ですね。 使用しているOCXに関してはラッパークラスを作成してくれるなどとありますが、 それが正確に動作することを確認したり、下手にそのラッパークラスを使えば、 VB6の頃のイベントや関数を使用し、VB2005に即した形ではなく、両方の知識を必要とするために、 保守がしずらくなったりすると思います。 そのように、あくまでも移行作業と生産性だけにとらわれてならないような気がします。 また今年度中に新しいVSがでる話もありますし、予算があるから使いきりたいんだよとか 下手にVS2005の開発を行うよりは、次期をまちながら、 移行しやすい修正をしながら機能UPなどの方が費用対効果は高いんじゃないでしょうか？ ただ、あくまでも私個人が入り口ぐらいの感覚で記載していることなので、 確実にとはいえませんので、その点だけご了承ください。 あぁ、やってしまった。
自社の仕事をやっていてさぁそれをまとめるぞという時に、 まちがって正しいファイルを削除してしまった。。。 そんでもって復旧も無理な状態。 さぁがんばって再度やりますか。。。 そんな休日で、当初予定の本日の過ごし方できずじまい。 みなさんそうな事の無いようにこまめにソース管理にアップだとか ファイルを保存する場合には二重化をするとか、 僕みたいにShiftデリートするのでなく、ゴミ箱にいれるとかしましょうね。 よくある話がNoと言えない人。
そんでもってまたある話はNoと言わない人。 ITバブルがはじけた状態となっている今日では、 お客様が全てあり、お客様の言う事はちゃんと聞かなきゃいけない。 だから仕様も膨らむけど安い費用でなんとか… そんな状況が多いと思っている。 そんなさなかにIT業界で仕事をする方々、特に第２新卒を超えた経験３年目あたりの方々には 次の言葉を意識して欲しい。 個人の自立とは、プロフェッショナル化であり、無理な要求に「ノー」と言える人を増やすことである。ベンダー、ユーザーが対等に近い立場で要求について議論できるようになれば、ソフトウエア産業は健全になっていく。 ↑ 「日本のソフトウェア産業、衰退の真因」より抜粋。 「頑張ります。」「やれるように努力します。」「できる限りやります。」 そのような言葉だけでは最終的に信用も失うだけになりと思います。 電通「鬼十則」、そして電通「裏十則」
そんなタイトルでの記事があった。 いや〜コレって一応会社の規定？だから外部に公開されている事実があるってのは どうなの？って話はおいておいて… あとは紹介している記事に記載されている「裏十則」… これもなんていうか日本的な企業だと納得できる。１つ前に在籍していた会社だと裏十則の方が適してるかな… 小さい会社だと鬼十則の方が適しているかな〜。 一応潰れはしたものの最初に入った会社でも似たような「鬼十則」があった。 ここらへんは人種的な文化圏も影響していると思うし、集団を重んじるこの国では どうしても大きな会社となると「和」が重視される為にやむ終えない事でしょう… 結果的には、裏十則でいる人は一生そのままである事はほぼ間違いないと思います。 まぁ鬼十則を行い、ある程度以上認められるようになる！！ これが実行できないのなら裏十即でいた方が無難。 そんなところでしょうか？ それとこっち「責任三カ条」の方がいい事をいっているように思う。 けれども人間なので誤りはつきものなので、畑村様の著書にもある「失敗学」のように 失敗という経験を活かせる状態にしていくという合わせ技が必要。 「ITアーキテクト」という本がでている。
サブタイトルとしては ITシステムを"創る"人のための技術情報誌 とある。 "創る"の言葉のとおりにPG自身というよりは、一般に言う 上流工程を手がけるために、役に立つようなものを紹介 していっている。PG自身ではないけれども、ソフトウェア業界に居る プログラミングをされている方々にも為になるものだとおもう。 その中でも書かれている開発手法およびモデリングといったものは 物事をよりわかりやすく表現する為に欠かせないものだと思う。 大きなくくりの中では、時代にあわせた最適となるものが代表として 取り上げられるようになっているのだろうけど、 小さなくくりの中では、個人個人がその時に最適だと考えた手法や モデリングというのも存在するわけで、 100%の正解があるものでは無いと思っている。 だからこそ切磋琢磨して、経験と知恵を働かせていかないと！！ 本日より新しい職場での実務となりました。
何はともあれ初日ですので、現状と今後の説明と 開発環境設定にて終了。 開発環境としては自社パッケージの開発環境も構築するので PHPによる開発環境を作成しているのだけど、 XAMMPという開発環境をインストールします。 これはなにかっていうとApache+MySQL+PHPでの開発環境を 簡単に構築するものであって便利なものです。 ただし、技術者として理解を含めるためには、 ちゃんとそれぞれ単独でインストールした時の設定方法や XAMMPによって設定されている状況などを理解していかないと いけないよなぁって思っております。 実際にWebベースの開発というのは短期間しかないので、 これからちゃんと勉強していかなければいけない。 またC/Sに比べてセキュリティとかもちゃんと考慮していかないと いけないし便利なシステムな反面、学んでいかなきゃいけない 技術や指針というのも多い。 Blogなども普及し、Webって簡単に使えるってイメージがますます 増加しているような状況だけれども、それを支える部分って 大変なんですよ(~~;) いやぁ〜今日は久々にお客さんのとこへ打ち合わせに行きました♪ それはともかく新しい仕事に入り、およそ1週間… |
