スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ネタつつき204 - 私が歩んでいる情報道

 いった張本人が言わないといけないと思いますので、私が考えて実践している「情報道」を書きます。といっても、「道」を意識して考えたものではなく、仕事をする上で心がけてきたことの集大成にすぎません。ですから、道としては不完全ですが、「道」を考えるうえで参考になるかもしれません。
 以前「適時適情」と表現したように、基本はお客様が望むときに、お客様が望む情報を提供することを目標として働いています。それを実現する為に、温故知新の考えで、新旧関係なく、日々技術を学習しています。毎日1時間は学習に充てています。嫌いな情報技術はなく、好きに強弱があるだけで、プロジェクトに役立ちそうならば何でも使います。
 それを基本とし、細かい単位で考えると以下の考えを持って仕事をしています。

  • お客様を第一に考える。
  • お金は適切な金額しか受け取ってはならない。
    多すぎたら駄目。少なすぎても駄目。
  • 適切な金額は、帳簿などを参考に実際の効果から算出する。
  • お客様のためにならない事ならば、お客様の要望に対してNOを言う。
  • ただNOを言うだけならば誰でもできる。NOを言う際には対案を言う。
  • お客様を尊敬する。
  • お客様の業務に興味を持つ。
  • 仕事仲間に敬意を持つ。
  • その他自分以外のすべての人に敬意を持つ。
    例えば、掃除婦のおばさんにも敬意を持つ。
    システム開発とは関係がない人などと考えない。
  • 毎日学習する。学習しない技術者は技術者ではない。
  • 情報技術以外の学問も積極的に吸収する。
  • 神羅万象の全てを教師と考える。
  • すべての人が教師。
  • 見聞きするものを全て分析する。
  • 生きているだけで幸せ。この世のすべてに感謝する。
  • 情報技術は人間ありき。人間なくして情報システムは成り立たない。
    それを常に意識する。
  • 情報技術を極める事だけを考えて生きていく。
  • 常に正直であれ。嘘は自分の身を亡ぼすだけ。

大体こんなところです。注意せねばならないのは、お金とお客様の部分です。日本では「お客様は神様だ、だからなんでもYesを言うしかない」もしくは「お金を儲けてなんぼ。自分だけの利益を考える。その為ならばお客様を騙してもいい。他の企業から搾取してもいい。」などと考える節があります。これは日本特有の、本音と建て前というもので、建前は「神様」、本音は「お金さえ儲ければ何をしてもいい」です。すごい二枚舌です。悲しいかな、実際にそう考えている人が多いようで、日本の情報産業は無茶苦茶です。
 日本人は理性ではなく、空気に従う傾向があり、看板に騙されやすい傾向があります。それ故に、看板は「神様」、中身は「詐欺」という事が多分にあるのです。いつからそうなったのかは知りませんが、歴史から推察するに、本来の日本人はそこまで愚かではなかったと思います。
 経営学とか学んだ人ならば知っていると思いますが、お金はただの道具であり、それを第一目標にする時点で、精神性が低く、つまらない考えだといえます。私の考えは「たかだかお金で満足するの?」です。私はもっと欲張りで、正しく儲け、正しく使い、人生を謳歌することを考えます。少なくとも私は、犯罪者と変わらない人をプロだとか技術者だとか専門家だとか呼びたくないと思いまし、認めてはならないと思います。そうしないと日本はただの犯罪大国になってしまいます。
 現在の私の状態は、1円でも売上増経費削減になれば成功というのであれば、プロジェクト成功率は100%なのですが、満足とは程遠いです。事前に5%利益増と約束したときに、10%利益増になるぐらいでなければ、真の技術者とは言えないと考えています。しかしながら、5%増と約束したのに6%ぐらいしか増えないとき(不完全成功)や、3%ぐらいしか利益増になっていないとき(失敗)があります。この結果は、私の技術力不足を意味していると反省しています。
 ちなみに、納期に遅れたことは一度もありません。速いのは当たり前だし、例外的状況に対してはちゃんというからです。例えば、システム開発では、酷いときともなると、納期1日前に仕様追加を言ってくるお客様もいます。そんなときは、はっきりと、必然的に納期を守れないから、次のイテレーションで対応するといいます。もちろん、悪意がある人もいますが、どちらかというと、何が仕様追加になるかわからないお客様が多いので、話せばわかってもらえます。悪意がある人に対しては、「その行為は貴方の不利益になるだけだ」と説得します。そして、納得しないのであれば辞退します。
 私の考えはごく普通のもので道といえるほど立派なものではありませんが、道を考えるうえで参考になれば幸いです。
スポンサーサイト

テーマ : 文明・文化&思想
ジャンル : 学問・文化・芸術

コメントの投稿

非公開コメント

WannaBeWithYou

>適切な金額は、帳簿などを参考に実際の効果から算出する。

ここについて詳しくお聞かせください。
そのシステムが介入する業務の成果物(アウトプット)は同等以上であるというのは当たり前の前提だと思います。
となると、ここで「帳簿」が出てくるということは原価で見ていくことになりますよね。定量的に計れるものが他に存在しませんので。

原価管理は原則として、正確でなければなりませんから、その効果は長い目でみなければなりません。
たとえば、年締めを考えれば最低でも1年以上ですね。

そこで質問なのですが、納品後、どれくらいで請求されているのでしょうか?

Re: WannaBeWithYou

> ここについて詳しくお聞かせください。
企業秘密なのであまりお話しできませんが、少しならOKです。

> そのシステムが介入する業務の成果物(アウトプット)は同等以上であるというのは当たり前の前提だと思います。
そうです。

> となると、ここで「帳簿」が出てくるということは原価で見ていくことになりますよね。定量的に計れるものが他に存在しませんので。
>
いいえ。それ以外にも色々あります。
何の原価を指しているのでしょうか?

> 原価管理は原則として、正確でなければなりませんから、その効果は長い目でみなければなりません。
> たとえば、年締めを考えれば最低でも1年以上ですね。
何の原価を指しているのかわかりませんし、それ以外の加味しての事なので私の想定とずれていると思います。
よく記事を読んでいただければわかると思いますが、独自手法で効果を想定しています。
その金額を請求することになるので、不完全成功と失敗もありうると書いています。
未来を予測するのは難しいのですが、システム屋はそこまでしないと駄目だと考えています。
ちなみに、最近の原価計算は、未来の測定も言われています。
過去しかわからないのは昔の原価計算です。
未来予測用の原価計算方式もあります。
ただし、私の場合は、独自限界計算を作ってやっていますし、原価計算以外もやっています。

> そこで質問なのですが、納品後、どれくらいで請求されているのでしょうか?
ケースバイケースです。

補足

お客様の企業の原価計算は、お客様自身がしています。
ですから、私自身が帳簿を作っているのではありません。
従って、私が行っているのは、原価計算というよりも企業分析です。
企業分析には色々な方法があるというわけです。

ケースバイケースですか

> > そこで質問なのですが、納品後、どれくらいで請求されているのでしょうか?
> ケースバイケースです。

なるほど。ケースバイケースですか。

最短は翌月とかだと思いますが、最長だとお客さんが検収後どれくらいで請求していますか?
ざっくり○ヶ月くらいとかでいいので教えて頂けませんか?

Re: ケースバイケースですか

> なるほど。ケースバイケースですか。
>
> 最短は翌月とかだと思いますが、最長だとお客さんが検収後どれくらいで請求していますか?
> ざっくり○ヶ月くらいとかでいいので教えて頂けませんか?
ごく普通に、お客様の締日で支払ってもらっています。
これが原則であり、どこの会社も同じだと思います。
ですから、最短というよりも、最長で何か月かと聞く方がよろしいかと思います。
最長の場合、お得意様が泣きついてきて、3か月ほど待ったことがあります。
普通は待ったなしなのですが、その辺は人間なので人情もあります。

Re: ケースバイケースですか

もしかしたら、わかりにくいかもしれないので書きます。
先ほどのコメントは

>最短は翌月とかだと思いますが、最長だとお客さんが検収後どれくらいで請求していますか?
>ざっくり○ヶ月くらいとかでいいので教えて頂けませんか?

についての返事で、最短とか最長とかではなく、普通の会社同様請求はすぐに行い締日に頂くのが常識だから、最長でどれぐらい待ったか聞いた方がいいよという事です。
請求を何時するのかと聞いたら、どの会社でもすぐにしますと返ってくるから意味がありません。
ケースバイケースというのは、締日は会社ごとに違うし、人情で待つこともあるという意味です。
プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

QRコード
FC2カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。