あんじーのテクニカルブログ技術評価やIT系の情報などについて個人的な意見をつらつらと・・・
|
|
モバイルでもご覧いただけます。 (QRコードは株式会社デンソーウェーブの登録商標です) |
以下引用
皆とにかく忙しく、常に忙しい、忙しいと口にする
メールでのやりとりが主で、対話をしない
やって当たり前で、感謝がない
協力して仕事をしない風土があり、他の人が何をしているのか分からない
上司の話に部下が反応しない
結果だけを求められる
それぞれが重複して行っている業務や作業がある
極端に業務負荷が高い人がいる
八つ当たりをする上司がいる
提案した人に負荷がかかる
よくある話が、最後の「提案すると損をする」というケースだ。提案することがマイナスになるような職場はもう末期に近い段階だ。もし自分の職場がそういう雰囲気ならば、パワーがいるが自分からどんどん提案をし続けて空気を変えるか、職場を変えるしかない。
最近Mixiの開発者ブログを見てやっぱりオープンソースは楽しそうだなぁと思っている今日この頃。
社会人始めて以来、今の会社にはいるまでずっとオープンソースで開発された製品でもって開発したりしてきたわけで、時にはドキュメントがないことにいらだったりしつつもそれを調べるのもまた楽しかったわけで。
今の会社はベンダーの製品でもって開発しているわけだからつねに制約というものと戦っている。オープンソースで身につけた知識を持って内部構造を調べることはできてもそれに手を入れることはできない。
ベンダーから見ればリリースしている製品に勝手に手を入れられたら保証できないというのはもっともな話。ベンダーが保証した製品でもって顧客に展開しているからこそ顧客と保守契約が結べることもまた理解している。だけど製品のちょっとした使いにくさが自分のスキルでもって直してあげられればもっといいんだけどなぁ。。。
オープンソースが僕に与えてくれた刺激はとても大きいみたいだ。
来年からJ-SOX法による運用がスタートするけれども、J-SOX法の本になっているCOSOのモデルになぜＩＴの利用が含まれているのだろうか？
SIerからみればなんでもＩＴ利用してもらった方が儲かるわけだから歓迎すべきだけど、理由を分かってないともちろんどこに重点を置いてシステムを提案すべきかが分からなくなってしまう。
内部統制の重要なキーは会社の規定に基づいて正しく運用されていることを証明できること。そのためには、たとえば承認しなければならない人がきちんと承認していること（承認者でない人が承認できないこと）を証明しなければならない。
アナログ運用だとその確からしさを継続的に保証することができないのでそこでシステム運用が必要になる。システムでそれが保証できるのであれば、バグが残っていたりシステム改修をしない限りはその確からしさが継続的に保証される。
だからこそＩＴの利用でもってその証明にかかる負担を少しでも減らすべきだといっているわけだ。
もちろんシステム化するからこそ、管理者というものが存在することになり、管理者による改竄は発生することになる。それこそログは別サーバーで管理し、そのサーバーが全く別の管理者で管理され、改竄されてないことを証明しなければならないが、その管理者同士が結託すればそれもできなくなる。
根底にある難しさはやはり運用している人間自身にあると言える。オチは結局そういうことです。
正規とは・・・
規則などではっきりきまっていること。また、その規定。（大辞林第2版より）
システム化（プログラミング）するということは今まで手作業でやっていた作業を正規化してコンピュータに仕事をさせるための作業だ。ロボットの目指すところは人間の正規化であるわけだけど、その中で言語の正規化も必要になってくる。言語の正規化は身近なところではコンピュータの日本語変換システムが該当すると思う。
さて日本語変換システムは、単純な漢字変換（といったら怒られる。日本語の変換システムはおそらく他の言語に比べればもっとも難しい可能性があるから。）を経て、予測する世界に入ってきた。
それは、携帯電話などの小型ディバイスの発達に伴って、少ないキーの入力回数でもって日本語入力をする必要が出てきたからだ。あ、便利だと思う人もいれば、この機能が表現を制約しかねない非常に危険なツールだと思う人もいるだろう。
僕は一番最初に出版社に短いながら勤務していた。そこで国語編集部につとめていた先輩に日本語変換システム開発に必要な辞書のデータベースの提供をもとめてきた有名なコンピュータメーカとの打ち合わせに同席してもらったんですが、その会議のあとにぼやいた一言が印象的だった。”言語は生きているのにそれをひとくくりの変換システムに押し込めてしまうなんて。。。”
たしかに言語は生きている。新しい単語もできてくれば新しい言葉の使い方も生まれてくる。僕は詳しくは分からないが、これが正しくて、これが間違っているということはなくて、僕たちが今まさに話している言葉が正しいわけで、それを正規化してしまうということは、その表現の自由が奪われてしまうというわけだ。つまり、新しい日本語が生まれにくくなる。
もちろん誤った日本語の使い方だから制約してしまっても問題ないという考え方もあるだろう。でも誤用がそのまま辞書に載るようになることも長い歴史の中では多いわけだ。だから言葉は難しいのかもしれない。
話はそれてしまったが、システム化するときにエンジニアはこのようなことに注意しなければならない。一つの向きから見てこれは便利だと思ったことをシステム化する事はとても得意だ。この発想がなければエンジニアの仕事は楽しくないはず。ただ、反対向きから見て本当に便利なのかについても考えてもいいだろう。
そんなことは作ってから評価される段階において評論家にでも任せればいいと思うかもしれないが、作りっぱなしのシステムではなく使われるシステム作りを目指して僕たちはいろんな畑の人たちと積極的に話をして、価値観を共有して一つの物事を様々なアプローチから考えることができるようにならなければならないと思う。
今自分がやらなければならないことが手元になくて焦っていることがよくある。何かをやらなければ周りにおいてかれてしまうという恐怖心だ。または、こんなことをやっていて何の役に立つのだろうという疑問。
与えられた仕事をして時間に余裕ができるからそんなことを考える暇ができるのかもしれない。もし余裕ができたら恐怖心を捨てて話をしに行こうと思う。
前の会社でデータセンターの選定作業を行ってから早2年、いろんなデータセンターを見て回ったり、今の会社になってからは作業をしたりすることが多いが、実際にデータセンターを選ばなければならなくなったとしたら選ぶポイントはどこにあるのだろうか？
営業トークにごまかされると後々移転せざるを得ないケースもあるので、このドキュメントが何らか役に立てば嬉しい。
まず立地条件。通常はリモートメンテナンスで何とかなる訳なので、言ってしまえばデータセンターの位置はどこでもよいと言うことになる。ただし、致命的な問題が発生しないということはないので、必ず駆けつけできる範囲であることが最低条件。
次に、電源の問題。基本的にこの問題は当たり前だからこそ気づかない部分だ。1ラックあたり何Aまで追加できるのかをチェック。
そして、サポート内容のひとつであるリモートハンド作業。万一リセットを必要とすることがあれば、センターの人にやってもらうしかないが、そのセンターは担当が24時間いるかどうかを確認しておくべき。この部分をすりあわせなかったために痛い思いをしたことがある。ただ24時間常駐していても、対応には10分程度かかるため、ミッションクリティカルなマシンには必ずDRAC(Dell Remote Access Controller)のようなものを入れておくべきだ。
当たり前と思っていることが当たり前でないことはよくあることだ。
最後に空きスペースの問題。今後増設を検討している場合には思い切ってスペースを借りておいた方が無難。何らかによって急にサーバーを増設することになっても対応できないではすまされない。
ブログサービスで有名なドリコムの社長の記事について。
http://japan.cnet.com/interview/media/story/0,2000055959,20341666,00.htm
僕が非常に共感したのは、”儲ける仕組みをきちんと加味すれば、コストを抑えて高収益率のビジネスを効率的に展開することができます。しかし、現状は儲けの仕組みを全く考えずに展開するWeb 2.0サービスが多いため、「Web 2.0は儲からない」という話になるわけです。”というフレーズ。
ビジネスの上でこのことは当たり前といえば当たり前なんだろうけれども、マッシュアップがベースであれば、おのずとお金がユーザーから取れないというものが生まれてしまう。広告収入だけで頼るのもなんら収益モデルとしては工夫がないだろうし。
ユーザーに使えるサービスを提供し、収益モデルをしっかりと組み立てられる。こんな当たり前のことが、求められているのが今の現状なのだ。
http://www.itmedia.co.jp/news/articles/0702/01/news032.html
http://gigazine.net/index.php?/news/comments/20070131_pc_success/
PCサクセスが破産を申し立てることになってしまった。一時期は配送が遅いなど問題が多かったが、最近は改善されていたのに。。。
一方で激安販売を行っているECカレントを運営するストリームはマザーズに上場する。
マネックス証券のBB考察はアグレッシブとなっており、同じ経営手法で成長した会社の明暗が分かれた格好だ。
Request For Commentに関して。今まで触れたことのあるRFCを紹介していきます。
RFC791
IPに関するRFC。
RFC793
TCPに関するRFC。
RFC822(Obsoletes：STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES)
メールに関するRFC。RFC2822に移行されている。
RFC959
FTPに関するRFC。
RFC2396
URI(Uniform Resource Identifiers)に関するRFC。マルチバイトを含むURIは文法違反。
RFC2616
HTTPに関するRFC。
IT職場の未来はこのままでは将来も明るくないかもしれない。
日経コンピュータの10月16日号に掲載されていた日本情報システム･ユーザー協会の細川さんの記事。
昔は3Kといえば、「きつい」、「汚い」、「危険」だったがITにおいても3Kとして「きつい」、「給料が安い」、「帰宅が遅い」が当てはまるんじゃないかと。学生が情報産業を選ばないことは今後IT業界の更なる人材不足を招くことになり、結果的に情報社会を支えていくことは難しいかもしれないというものだ。
そこで要件仕様を早期に決定する（要件仕様をつめる能力を高める）ことにより、3Kを3T(「楽しい」、「高い報酬」、「たまには定時に帰れる」)に変えられるのではないか？
確かに赤字プロジェクトが発生する原因は文章の中で指摘されているように「仕様の決定の遅れ」、「要件分析作業の不十分」があると思う。仕事を進める上でこれらに注意して仕事を進めていくことで3Tは得られるのかもしれない。
何事においても歴史を知ることは今後を予想する上で非常に重要であることは間違いなさそうだ。
コンピュータの歴史においても同じことが言える。コンピュータの歴史は半世紀程度しかないけれども常に分散と集中を繰り返しつづけているといえるだろう。
ホストコンピュータによる集中時代
マシンが非常に高価だったため、クライアント機はホストコンピュータにつながった端末であり、その端末時代には処理する機能は存在しなかった。（ホストコンピュータにログインして、そこで処理を行うので、画面への出力とキーボードの入力のみを処理）
そして時間単位で課金されていた。とはいっても僕はこの時代にマシンを利用していたわけではないので、詳しいことは良くわからない。
クライアントマシンによる分散の時代
マシンの単価が下がってくると、あえてサーバーで処理する必要もなくなり、より応答速度が速いローカルで処理するようになってきた。この流れは、サーバーの乱立を招く結果となる。
シンクライアントによる集中の時代
サーバーの乱立に伴う管理費用の増加とクライアントマシンにデータがあることによって発生する情報漏えいの2つの観点から、マシンを集約することになる。集約できるようになった大きな背景として、ネットワークの高速化が上げられる。
とくれば次は分散かもしれないが、分散の対象はおそらくマシンではなくネットワークになるだろうと予想する。
インストールとデプロイ（実は今までデプロイという言葉を使ったことがなく、今日はじめて聞いた）は同じようで微妙に違うみたいだ。
インフラ系を中心に価格破壊が起きて久しいが、その結果多くのユーザーは安くなったことのありがたさは忘れ、いつもと同じように当たり前のように使い続けている。
ネットワークインフラにおいては、ブロードバンド化によって提供コストは確実に安くなっている一方で、運用ならびに保守にかかるコストはさほど低くすることは出来ていない。
不幸なことに、動画配信やIP電話の普及に伴い、ますますバックボーンは増強せざるを得ない状況になっている。おそらくコスト削減は行き着くところまで行き着いたようにも思える。
ネットワークインフラ保守のコストは以前から、（ほとんど誰も意識していないが）利用者全員がコストを負担しあうことによって成り立ってきた。しかしながら、一部では、大容量のコンテンツを配信しているようなコンテンツプロバイダーも目立つようになってきた。
プロバイダーは利用者から回線増強にかかるお金を取ることは難しくなってきているので、コンテンツプロバイダーからお金を請求せざるを得なくなっているが、コンテンツプロバイダーはそれに対して応じようという気配は見られない。
こうなってくるとプロバイダーは淘汰されるしかなくなってくる。以前から資金力が無いプロバイダーは次々と吸収されてきたが、それが今後はもっと加速化されるだろう。
エンドユーザーのためにと始まった価格破壊は、最終的に特定プロバイダーの寡占状態に陥って、不幸が始まるかもしれない。
安売りすることによって他に収益源が確保できる見通しがあれば問題ないが、ただ価格破壊をすることは誰にでも出来る。
技術の安売りをするときにはよくよく考えたほうが良いかもしれない。
今日Wikipeidaを編集しようとしたら広域ブロックというものでブロックされていることに気づきました。どうも加入しているISPの一部のホストが大量にスパム行為を行ったらしいです。
巻き添えを食っているISPはウチだけでないようで、Yahoo! BB (220.0.0.0/10)やinfowebの一部（58.0.0.0/16）も含まれているようです。でもサブネットが10ビットってかなりのホストを制限しすぎているような気がしますが。。。。
WikipediaではISPに対策をとってもらうまでの間、制限を解除したりはしないとのことで、このような制限が広がれば広がるほどWikipediaへの活発な議論が行われなくなるのは残念なことだと思います。根本の問題はスパム行為なわけですが、これを問題にしてしまうと埒があかないので・・・
リーダーがメンバーに情報をあえて伝えない場合のメリットとデメリットを整理してみる。
・良い情報を制限する場合
(メリット)特になし
(デメリット)メンバーに少なからず不信感を与える
・悪い情報を制限する場合
(メリット)メンバーの士気を下げずにすむ
(デメリット)情報に期限が含まれている場合、後で現場で火を噴く可能性が高い。
知らなくても良い情報があることは確かであり、太古の昔から情報を握っている人間が必ず物事を有利に進められることは既知の事実であるが、情報を公開しない場合にはメンバーに少なからず不信感を与えることは必死である。
エンジニア(プログラマー/S.E.)として付加価値をつけていくにはどうしたらよいのだろうか？僕が今考えているのは、
・徹底的に特定の言語に固執してスペシャリストになる。のいずれかではないだろうか？
・言語(や開発手法)を幅広く学習して、課題に対して適切な解決策を提案できるスペシャリストになる。
J-SOXの流れを受けて、「見える化」という変な日本語が流行しそうな勢いだ。Y2K問題に続いてシステム業界全体で大きな変革の波が起こりそうなJ-SOXソリューションに対するSIの取り組みはどこも必死だ。
そもそも見える化は業務フローを明確化するという重要な取り組みにもかかわらず、多くの場合にはドキュメントが残っていないなど作業担当者に依存する俗人化といわれる要素が企業内に多いことが問題となっている。
俗人化してしまうと、ビジネス上の一番のリスクは従業員ということになってしまい、企業にとって健全とは到底いがたい。そこを俗人化しないようにするための方法が、見える化なのだろうと思う。
しかし一方で見える化は、J-SOX法の名のもとで監査法人対策というところに置き換わってしまっているケースも多い。この行き着く先は、メンテナンスされないドキュメントの山。これを整えるために数億円というお金を使う企業は間違いなく行き詰まると思う。
プログラマやSEなど実務業務に当たるエンジニアは会社の決められた待遇の中で業務を行っている。僕の場合には、前職が労働組合があった関係もあって、労働条件はかなりよいほうだと感じていたが、転職してからというもの、会社が大きくなるにつれて労働条件が悪化していることが目に見えてわかった。
資本主義において、会社は最大利潤を追求する組織。経営者の確固たる従業員への思いやりの理念がなければ当然労働条件は悪化するものである。それは、純利益を最大化するためには、売り上げを上げることよりも、支出を減らすことのほうが簡単だ（少なくとも選択肢がある）からだ。
働きやすい環境を確保ならびに維持することは、生産性を最大化するための必要最低条件であり、従業員はこの努力を忘れてはいけない。経営者は実務作業をしているわけではないから、働きやすい環境というものが何なのかは現場にいなければよくわからないはずだ。
会社を大きくする上では、従業員を多くとっていかなければならない。現場の人間が誇りを持って新しい人を招きいれられるように労働環境の確保は行わなければならない。
しかし一方で従業員の立場は弱いものである。自分たちの思いを経営者に伝えるためには相当のポストになければならない。自分たちの思いを言葉に表さなくても経営者に伝えられればなんと良いことだろうか？？
ところで、日本の法律には労働組合法というものが存在する。従業員は特定の職種以外であれば労働組合を結成し、経営者にその思いを伝えることができる手段が用意されている。
前職では当たり前のように労働組合と会社は話し合いの場を持っていた。労働組合は足の引っ張り合いになる可能性もないわけではないが、少なからず労働条件という題目において経営者と従業員が話をするためのツールであることは間違いないのだ。
日本版SOX法(2006年6月7日制定の金融商品取引法)だが、ITの利用という項目が含まれている以上は、J-SOX対応は、管理や経理部門だけの話ではなく、システム部門の準備も行わなければならないことになる。いまは、エンジニアが本当に不足している。募集をしても応募すらほとんどこないという悲惨な状態である。こんな状態は半年前に想像もできただろうか？？
J-SOXに対応するためには、文書化などさまざまな部分でいままで以上の業務(おそらく本来であれば作業手順をはじめとする文書化という作業は当たり前に行われなければならないが、Web業界においては仕様書がないとか作業手順書がないなんてことは珍しくない)を強いられることになる。ただでさえ、人員が不足している現在において、文書化までの作業を正しく行うことができるのだろうか？行き着く先は今かつて無いデスマーチの連続なのだろうか？2008年4月から恐ろしいJ-SOX法が施行されることとなる。
・宅配物を紛失した時には損害賠償が上限があるものの決められている。
・購入した電化製品が1年以内に故障したら無償修理する。
このような品質保証をネットワーク業界ではSLA(Service Level Agreement：サービスレベル保証)と呼んでいるが、Webサービスを見てみると、免責条項はあるもののSLAに該当するような品質保証をしているケースはほとんど見受けられない。
Webサービスを行っている会社がSLAを締結できない理由は、
・Webサービスの多くは無償で提供されている
（今回の話題では、有償サービスを前提としているので、これは除いて考える）
・サービス提供元の会社の資本力が小さくて金銭的な補償を含めた保証ができない
・Webサービスの不具合はすぐに改善することができる（なので不完全なアプリケーションが出やすい）
・何かといえばβ版という言葉が流行している
・品質管理の認識が他業種に比べて低い
からだろうと思う。
SLAを締結することは、サービスを明確にすることになるわけなのだが、締結する会社はかなり厳しい条件になることは承知の上で締結することでそれをアピールポイント（差別化）に変えることができる。提供する価格が多少高くなろうとも、顧客の安心感を買うことができるので、結果的に顧客はおのずと集まる。
と考える。ハードウエアにおいては、稼働率の考え方が定着しているもののWebアプリケーションを含んだ全体的な稼働率という部分での定着はまだまだ薄いような気もする。
稼働率が出せなければ、1日間あたり何秒間システムが完全に稼動しなければ補償しますとか、レスポンスタイム何秒を超過したら補償します（これはネットワークという性質上難しいが・・・）といったようなことができないわけで、ここから始めることがSLA締結への取り組みの第一歩なのだろうと思う。
SLAが締結できないような会社は、おのずと仕事がなくなるといった感じの流れができてくるようであれば、Webアプリケーションもよりよい品質を保つことができるようになるのかもしれない。
とはいうものの、自分が開発を担当しているコンテンツでSLAを提供するなんて話になれば、間違いなく難しいか、会社がつぶれてしまう。
理想と現実はつねに乖離しているものなのですね。