2010/07/30

ユーザー企業から見た情報システム

nosaさんのような、、、

パイナップルを食べ過ぎて、まだ、胃からお腹がグッと重い感じが続いています。
サクロンが効いているかどうかも分からない状態ですが、そのパイナップルをお腹が痛くなるほど食べる前に、名刺交換しなかったので、会社名は思いだせないのですが、とある会社の代表の方と情報システムについて話をしました。

非常に腰が低く、人の話をよく聞いていらっしゃる落ち着いた方でした。

一般的と言ってもよいでしょう。システム関連の経験のない方が陥る情報システムに関する勘違いについてです。

1.エンジニアといえば、システム関連のことは何でも知っているという勘違い。
  基盤系(インフラ系、サーバー系など)のエンジニアと開発系のエンジニア、最近では、評価系(テスターなど)エンジニアやコンサル系などシステムエンジニア系の種類は複数あり、その系統によって、持っている得意分野や知識や経験、所謂できることが違うというのは御存じでないケースが多いので、エンジニアと言っても、どんなエンジニアなのか何ができるエンジニアなのか意識された方がいいですね。
  特に、電気のエンジニアとは全然畑違いくらい違ったりします。

2.エンジニアといえば、皆、プログラムを組んでいるという勘違い。
  システム関連の業務、作業内容は全てがプログラミングではなく、プログラミングというのは、全体の数割程度。よって、必要なエンジニアの数も通常、全体の数割程度になる可能性が高いです。プログラマーが他の役割を兼任すれば、別ですが。
  また、プログラムと言ってもいろんなプログラムの種類があり、1.のエンジニアと同じように、プログラマーはどんなプログラムでも組めるということではないんですね。
  例えば、JAVAというプログラム言語が組める人がCOBOLというプログラム言語を組める確率は少ないです。最近ではそういうプログラマーも少しはいますが、ひと昔前では、分野違いくらいの壁がありました。

3.1.2.を総括したようなことにもなりますが、エンジニアと言えば、皆同じようなイメージを持たれている勘違い。
  エンジニアの世界では、1エンジニアを評価するうえで、いろんな角度から見ることができます。私個人的には、次の3点は最低チェックされた方がよいかと思います。
  ◆生産性
  ◆精度(クオリティ)
  ◆知識
生産性と精度はセットでよく評価しますが、我々の世界では、生産性はできる人とできない人では10倍以上の差が出ることは多々あります。
要は、クオリティが同じならば、生産性が5倍あれば、単価が2倍でも全然、貢献度は高いことになります。
精度は最終的に終了したときを終点に考えて、評価することが重要です。
とりあえず、できた。できたということがを聞いた時点を終点として評価するとよく評価を見誤ることがあります。
知識は、今の世の中、1つのことを実現するには、幾通りも方法が見つかります。ある技術を習得してできる人は、その技術にこだわる傾向にあります。只、選択する技術は拘った方がいいケースと拘らない方がいいケースがあり、できることを聞いて、この人に任せようと思うのではなく、いろんな方法論を提案で来て、いろんな視点で提案できる人に耳を傾けた方が良いかと思います。

パイナップルでお腹を痛めているので、今日はこのあたりで。

| | コメント (0) | トラックバック (0)

2005/11/22

エンジニアの面接に同席して

nosaさんのような、、、

私宛にくる案件情報、人材情報などで面接に同席することがあります。

某会社の人事ではないですが、採用面接をした時と比べてちょっと思ったことを。

2000年から2002、3年頃は異業種からの転職者の面接より、同業種の業種の転職者の面接が多かったですが、最近は異業種からの転職者の面接もかなり増えてきました。

建築産業や先物取引など、きつめの業種でパソコンに興味のある人は30代が多いですね。
専門学校行った後、通った専門学校とは違う分野への就職、転職または分野変更の転職の方は20代、30代が多いように感じます。

2000年から2002、3年頃採用面接をしていきたときは、結構アピールして、自分の売りを前面に出してくる方が多いように感じましたが、最近は、自信はあまりないですが、がんばりますので、よろしくって感じの方が多いように感じます。

面接官からすると、前者の方がいい印象を与えるような気がしています。

一番大切なのは、過去の実績での話で、あまり深く関与しなかった場合や結局自分以外の人に重要なところは任していた的な内容の返答の場合は、今度そんなケースがあった場合は私一人で解決できそうですんで、採用してもらえれば、是非、やってみたい的な返答の方がいいように感じます。

仕事はできるだけ、楽したい、あまり紛らわしいことや邪魔くさいことは避けたいと思うのは普通です。
しかし、将来の転職に備えて、そういうことこそ、周りに振り回されずに、率先して対応しておいた方が、そういう場面になったとき、変に考えずにそのまま返答すればうまくいくように感じます。(対象からすれば大きなお世話かもしれませんね)

「やらせてください」「体力には自信があります」「残業はきにしません」、この言葉を聞いたときはうれしいと思ったのですが、その前の展開がうまく流れないとその言葉も面接官の心には響かない可能性もあるような、、、

展開としては期待を持たせて、可能性を見せて、弱みや自信は根性で押しつぶして、「やらせてください」「体力には自信があります」「残業はきにしません」に繋げれば、面接官は採用したいと思うんじゃないかなぁ。

| | コメント (0) | トラックバック (0)

2005/08/18

C言語講習も

nosaさんのような、、、

C言語講習も社内外合わせて5名になりました。
社内の人間からすれば、刺激になって大変良いように感じます。

参加者が様々。
元デザイナー。
Javaエンジニア。
SEOコンサルタント。
元COBOLエンジニア。
社会人1年生。

いい癖、悪い癖がありますが、それもぞれぞれ違うようです。

今までソースコードチェック時に指摘した項目を一覧にして作成し、ソースコードを書いた後は必ずチェック一覧の項目をチェックしてからソースコードを書き終わるようにと指摘している方がいます。

課題を中止しても取り組んでもらっていますが、ここらへんがプログラム組み始めになんとかクリアしないと、プログラムを組めば組むほど、勉強すればするほど、苦しむエンジニアになりそうなので、なんとかクリアして、次ステップへ進んでもらえればと思います。

課題を解く姿勢も見ていると大変勉強?になります。
あくまでも答えを聞き出そうとする方。(内の社員ですが)
興味のあることが見つかれば、どんどん外れていく方。
質問がまとまっていなかったので、質問内容を確認していると、答えが分かった方。

どういう方が伸びそうで、どういう方が伸びそうでないかは、だんだん分からなくなってきました。

昔は次のようなタイプは確実に伸びると思っていました。
■根性のある方
■継続性のある方
■一次的に集中力のある方

最近では、そういう方でもうまく伸びなかったり、そういう方でなくても伸びそうな方をみたりと一度、私なりにまとめてみるのも良いのかもしれません。

| | コメント (0) | トラックバック (0)

2005/07/25

人材紹介会社の人と採用担当者の方と

nosaさんのような、、、

ITエンジニアの採用活動する上で、通常、面接を最低1回は実施するかと思います。
企業採用における応募者には履歴書と職務履歴を持参頂き、
人材紹介では、履歴書と職務履歴に加えて詳しいスキルシートを準備してもらうケースがあります。

面接では、特に試験をしない限り、会話における判断と履歴書、職務履歴、スキルシートでの判断で次ステップなど決定します。

企業採用担当者では、受け答えで、過去採用者で優秀だった人を想定して、できるだけ似ている方を採用し、期待から外れてしまった人を想定して、絶対に採用しないようにしている話を聞きました。
勿論、一般的な方法かどうか分かりかねますが、一理あるかなと思いました。
只、採用実績の少ない企業ではこのノウハウは使いにくいですね。

人材紹介の方は、人間性全体で過去出会った優秀だった人、使えた人を想定して、企業に紹介するそうです。これも企業採用担当者と同じく一般的な判断かどうかわかりませんが。

いずれも人を見てきた経験を元に採用及び紹介をしていて、履歴書や職務履歴などの面接上のネタに近い印象を受けました。

もちろん、転職を繰り返し過ぎていたり、転職サイクルが1年未満が続いていたりなど、複数(3種類)の職種にまたがった転職を繰り返していたり、面接までに判断することはあるそうですが。

私の経験では、求める人材、特に即戦力には、実際、やってもらう作業に等しい作業を試験するのが一番と思っていましたが、他社ではもっと人間重視しているなぁと感じました。

その中で一致した意見がありました。
受け答えの印象で、なんとなく、彼は難しいかもしれないと思うとき。
そのとき、総合的に判断して期待できそうな部分があったら、私は期待して取ろうかなと思っていましたが、他の2人は絶対に取らないそうです。

どんな印象ときか、激論の末、こんなときでした。
面接官「あなたは、、、、、?」と質問したときに、
応募者「わたしは、、、、、。」と応えない人でした。

こんな奴いないと思われるでしょうが、結構いるんです。
1人称、2人称、3人称など、質問では何人称かでの答えが明確にも関わらず、「私は、、、、」でしか答えない人、逆に「私は、、、、」と応えない人、いるんですね。

周りでこんな人いますでしょうか?
っていうより、私はちゃんと答えているかなと心配になりました。

また、お二方、暫くたってから、情報交換しましょう。

| | コメント (0) | トラックバック (0)

2005/07/11

C言語土曜日講習

nosaさんのような、、、

土曜日14:00より、社外の方も含めてしました。

つり銭計算及びコード変換プログラムは難しかったみたいです。
というより、標準関数使う上で、ポインタと頭で考えていることとコーディングにギャップがあったみたいです。

ポインタに関しては将来、習得するとして、おまじないと思って進めるか又はポインタを使用せずにすることにしました。

後者ですが、ひょっとしたら、新人の方を教えているときにありえる現象かもしれません。
私が推測するに、10頭に入って、次10入れるときに最初に入れた5が抜けている、また、更に次に10入れると、最初の5~10が抜けているといった、頭でなんとなく理解してもコーディングで初歩的な文法でつまづいたりして、なかなか前に進まないっていった感じです。

夕方頃までして、その後、中目黒の焼肉にいったのですが、私的には次のようなアドバイスをしました。
まず、私物なので、10年以上前の本ですが、情報処理試験勉強用のC言語の参考書の問題の2章くらいまでを全てコーディング及び全てのステートメントにコメント入れる演習を提案してみました。

次の講習はいつか未定ですが、成果は報告してみたいと思います。
ちなみに、当日、前述2課題は解きました。ちょっと私がコーディングしてしまったので、次回は絶対に手助けせずにチャレンジしてもらおうと思っています。
きっと彼ならできるでしょう。有給取ってまで勉強しに来るんですから。

次回、提案した演習と次の課題を解いてくれれば、、、
課題は、カレンダーと30000と60000と100000と10億の中に1~10の公倍数はいくつ存在するかです。
前回のエンジニアとしての課題と演習と課題をどこまで解いているか楽しみです。

| | コメント (0) | トラックバック (0)

2005/07/08

社内C言語講習に新メンバー

nosaさんのような、、、

社内のC言語講習に新メンバーが加わった。
社外からで、会社は有給を取っての参加。

私が若い頃は有給を取って、スキルアップに使うなんて考えたこともなかった。
最近の若い方は、スキルアップに貪欲な方と、そうでない方の差がどんどん広がっているような気がします。

参考になる本を4冊ほど紹介したのですが、2冊買って自らの選択で1冊準備していた。
自分の選択で買った1冊はC言語の本ではなく、言語に関係なくプログラミングの本でした。
中を確認してみましたが、Perl、C、BASIC、COBOLなど様々な言語で説明されていた。

これはちょっと最初からは難しいと思い、この参考書は避けての講習に決定。

プログラミングの世界に慣れていないせいか読み進めるのにゆっくりでした。
但し、表情的にネガティブじゃ無さそうなので、前向きにプログラミングに取り組んでいそうです。

プログラミングは精神コントロールしていないと、吸収、結果を出すときにそのときの状況が反映されやすいので、安心しました。

質問内容が、結構高度なことまで聞いてきたので、課題まで出しました。

さあ、今日、明日でどこまで成長しているか楽しみです。
この報告は月曜日くらいかな。

| | コメント (2) | トラックバック (0)

2005/07/07

社内C言語講習にて

nosaさんのような、、、

ゴールデンウィーク明けから社内エンジニアは関数マスターにならないように、プログラムのアルゴリズムの習得などを目的に社内でC言語講習をスタートしました。

6月も後半に差し掛かった頃、元デザイナーからの質問とは思えない質問が。
「関数のポインタについて、、、」
「typedefの使い方で問題はないか、この場合のスコープは、、、」
「void型関数のreturnについて」
「static型関数について」
「void型関数における char型キャストについて」

結局、C言語の文法を駆使すれば、C++でいうクラスを実装することはある程度可能なことに気づく。

会社にとっては、彼は一番忙しい存在であり、C言語講習をメインに就業しているわけでもないので、脅威の成長にびっくりしました。

その彼がActionScriptのメモリの扱いのところでバグを発見し、彼なりにActionScriptヘルプに載っている使い方をせず(その使い方だと正常に動作しないので)に、アルゴリズムの理解によるプログラムで切り抜け(ActionScriptのヘルプにたよらず)、更にActionScriptのメモリの扱いで怖い部分を発見した(どうして正常に動作していないか)ときは、もうデザイナーではなくプログラマーになっているなぁって感じました。

特定サービス産業動態統計2004は昨年のデータだが、参照してみると、エンジニア不足と言われ続け、人材紹介・派遣でもITエンジニアは常に需要があることを耳している私としては疑ってしまう情報が。

エンジニアは売り手市場だと思っていましたが、この業界男子の平均年齢は34~35歳、平均給与は、25歳、30歳、35歳ともに年々下がってきている。

私も案件で人材紹介、派遣の単価が下がっているのと、他社で採用面接で希望年収が下がっているのは肌で感じていたが、、、

私なりの推測だが、ITエンジニア業界は景気がいいとの噂により、異業種からの転職が活発になりつつあり、異業種からの転職では年齢は若くなくても初心者に近いため、給与は据え置きになりやすいなどの影響があるのでは。

と書いていたら、弊社実績で異業種からの転職組を中心に採用して成長している企業様がいるのを思い出しました。

採用ページの実績から次は全体リニューアルの予定です。

最後にJISAから公開される2004年版、2005年版、賃金状況を心待ちにして。

| | コメント (0) | トラックバック (0)

2005/06/15

ITコーディネーターの人と

nosaさんのような、、、

先週、ITコーディネーターの方と話をしたときのお話。先週、書き忘れたのを思い出しましたので、書きます。

日本の某有名ベンダー、米国の某有名ベンダー、などなどを渡り歩かれて、今年にITコーディネーターとして活躍されているそうです。某協会に参加され、発表や研究もされているとか。

システムハッキングやシステムトラブルとすっかり、システム関連の問題はニュースの常連になってしまいました。

前述のような出来事が発生した場合、注目があつまるのは経営陣の対応。

詳しくは書けないので遠回しに表現しますが、
対応しなければいけないが、どう対応すればよいかわからない。
しかも一度、失敗して二度目となると、対応しなければならないというよりかどう対応すればよいかわからないケースが多いみたいです。

企業として人材がいないのか人材はいるが意見を求めていないのか意見を求めても何を言っているのか分からないのか、、、など理由はたくさんあります。
経営陣>管理職>社員>パートの順で危機管理のなさがほとんどですが。

いずれにしても企業は株主、経営陣、管理職、社員、パートで構成されていますが、前述の構成では健全な経営が望めないので、監査(内外含めて)があります。
只、監査はどちらかというと経営陣の監視ですね。

前述の構成では、力関係で力のある部分が押し切ってしまうのは、力の原理。

株主、経営陣、管理職、社員、パート、、、などなど会社全体を監視する組織、士業などがやはり必要なのでしょうか?

私的には、組織を求めても天下り、裏○、、、などなど解決策は難しいでしょう。

税理士や会計士、行政書士のような会社監査士のような職が必要かなと。
もちろん、担当した会社の株主、経営、その他に関わってはいけない立場が前提ですけど。

そのITコーディネーターの方はCIOの支援を目指されていますが、会社内で、CIOが正しい発言、行動をとっても経営陣、株主には却下する権限がありますし、受け入れなければなんのためのCIOか、、、

上記のような士業の方が株主総会議事録や取締役会議事録にサインが必要など、税理書類や法務書類でも、穴は多少あるかもしれませんが、法人登記するときに法務局が勝手に選任し、法人税と一緒に担当した前述士業の人の報酬も徴収できるようになれば。

まだまだ考察の余地はありそうです。

ITコーディネータに関する書籍

| | コメント (0) | トラックバック (0)

2005/06/13

ウェブデザインする、依頼する上で

nosaさんのような、、、

ウェブデザインする上で、又は依頼する上でスケジューリングやゆくゆくのトラブルを避けるうえで気をつけておきたい点を走り書き。

デザイナーがDTP出身の場合、
■モリサワフォントなどの購入する素材などが必要な場合
 当たり前と思わず、デザイナー側はデザイン制作以外で必要なものをユーザー(依頼者側)に確認するようにしましょう。DTPと違って納品物の修正は在り得るかなども確認して、ユーザーにて準備(購入を要)するものは必ず伝えましょう。
 ユーザー側は見積金額に全て込みと思い込まず、準備するもの、修正が必要な場合は、どのような環境が必要か見積金額以外に必要なものを確認するようにしましょう。

共通では、
■対応ブラウザ(IE、NS、FF)、バージョン
 お互いきっと動くだろうと思い込まず、スケジューリングのタスクとして入れておきましょう。
■Windows、Macintosh
 上記と同じ、あまり変わりないだろうと思い込まず、スケジューリングのタスクとして入れておきましょう。
■対象ディスプレイ、解像度
 左上が一番優先順位が高いですが、デザインパターンによっては、確認して前提を決めてから進めないと、修正を繰り返す元になったり、想定範囲外になる可能性があります。
■ナビゲーション機能
 必要か否か又は必要な場合の遷移図の確認。プログラム開発が伴う場合、プログラマーが必要になります。社内にいればよいですが、いなければ、、、
■CSS
 制約になる可能性もありますし、ブラウザ、バージョン、プラットフォーム間で同じ動作しないことはよくあります。動作の違いが発生した場合は、口頭もしくはできうる限りドキュメントで確認を取る様にしましょう。微妙な違いは当たり前、同じ動作するのは当たり前以外の選択肢も早期にユーザーと確認を取ることにより、含めることはできるかもです。
■ロゴなど必須素材の準備
 必ずスケジューリングしましょう。他のタスクにも影響する可能性があります。あるページや自分の作業のみだけで調整せずに、タスクとしてスケジューリングしましょう。他タスクや担当者にも準備を当てにされるケースは多々あります。
■ページサイズ、ファイルサイズ、レイアウトパターンとカラー、フォントを含めたテイスト
 全て確認して進めることはまずないでしょう。しかし、将来的なことを考えた場合、確認して無駄になることはないかと。エンドユーザーからの印象を考えた場合、当然なのですが、多少はいいだろうの甘えが説明つかないことをする可能性を秘めています。
■SEO対策、テキスト準備
 マーケティングも含めたテキスト文言も含んでいると思い込んでいるユーザーは永遠になくならないと思います。SEO対策もプロモーションに影響しますので、後で誰かに決めてもらえればいいと思っていたら、スケジュールが伸びたってことはよくあります。自分が作らない場合は、必ず、スケジュール通り準備されているか確認するようにしましょう。
■コンセプト
 になりますが、お金を儲けるポイントと情報を提供するポイントと目的とするページへの誘導などごっちゃに検討したり、制作すると手直しを繰り返す原因を作ることになります。本番アップ後、更新作業でよくあります。ある担当者はお金を儲けるポイントを優先順位高く考えていたのに、他担当者によって、情報を提供するポイントの方が高い修正を依頼してしまったとか。元の担当者はどちらに怒りをぶつけるかは置いておいて。
■ユーザー責任者、フィックス(コミットメント)
 を意識したスケジューリング及び作業の流れ、まずに納期までに何回ほど確認依頼できるかも含めて。制作側のディレクターとユーザー側の偉いさん両社のスケジュールの都合があわないだけで、スケジュールが伸びたってケースは以外と多いです。
■プログラムインターフェース、更新作業
 プログラムインターフェースにおけるテンプレートや更新作業を意識して、なんでもかんでもデザインしたり、システムの人の問題や運用の問題などと逃げないようにしましょう。

まだまだありますが、とりあえず、当たり前のことを並べました。
次回の機会にチェックリストとして利用された方は感想頂ければ幸いです。

通常、3分の2はどちらかの思い込みのみで確認せずに(コミットメントを得ない状態で)進めているかと思います。
そして、微妙な(もちろん大幅なケースも)スケジュールのずれ、コミットメントのずれの原因は上記を確認し忘れていたケースが殆どだと思います。

今回はメモ風に。

ウェブデザインに関する書籍

| | コメント (0) | トラックバック (0)

2005/05/31

C言語を教えていて思ったこと(アルゴリズムと関数マスター)

nosaさんのように、、、

ぽよ~んネタを書いてしまいましたので、またまたC言語ネタです。(プログラム言語に関係のない共通でいえることですが)

最近、数名の方と私がこの業界に入った頃の入門書を見て、この入門書を解ける人はいるだろうかと話をしました。
恐らく、PHPやJavaでできると言われている半数方は解けないでしょう。というのが、予想です。

その入門書自体に意味がないのか?10年ほど前に比べてプログラマーのレベルが落ちたのか?

10年ほど前と現在の環境の違いは、
1.マシンスペックが高くなった。
  ⇒処理速度を意識しなくても少々負荷の高いプログラムを作ることに気を使わない傾向にある。
2.高スペックマシンの低価格化。
  ⇒高スペックと低スペックの区別をせずに、マシンスペックを意識しないプログラムを作る傾向にある。
3.インターネット、書籍などから簡単に多くの情報を入手できるようになった。
  ⇒プログラムを理解していなくても、とりあえず動くプログラムはだれでもできるようになった。
4.PHPやPerlなどのスクリプト言語(インタープリター言語)の普及。
  ⇒プログラム制作、テスト、本番運用実行のメリハリがなくなってきた。
5.関数、クラスなどの開発支援モジュールの増加。
  ⇒アルゴリズム構築能力より、関数知識が重視されるようになった。

10年ほど前に比べると、
開発環境はぐんとアップし、転職や学習などのエンジニアになる敷居も低くなり人口も増加、しかし、業界では高級エンジニア不足は10年ほど前よりひどくなっている感じがしています。

一昔前は、とにかくエンジニア不足。最近は、プログラマーがいても、プロジェクトを進められないなどのような、PM、PL、SCなど高級エンジニアが不足していて、プロジェクトを開始できない話がとても多く感じます。

プロジェクトの失敗やシステムのミスなどになると、高級エンジニアの問題というより、経営者の問題がほとんどだと思います。
しかし、経営者が重なる問題を経験して意識、常識を理解するまでに高級エンジニア不足を解消しないかぎり、ツールを使えるエンジニアだけでは、汎用的なプログラム、メンテナンス性のいいプログラム、堅牢性の高いプログラムなど質の高いシステムができない状況は続くのか。

で、どうすれば高級エンジニアを育てればいいのか?

こんな話をよく聞きます。Javaプログラマーは質の悪い人が多く、それをプログラマーの問題ではなくJava言語のせい。
恐らく、Javaプログラマーの多くは所謂、アルゴリズムを組めるプログラマーではなく、関数マスターのようなツールプログラマーでは無理があるだけだと思います。

低級言語かJavaなどで、標準関数や標準クラスでは実現できないアルゴリズム構築能力向上をはかる必要があるかと。

これをすると、想像できるのは、できると思われたプログラマーの化けの皮がはがれる。
しかし、今までできると言われたプログラマーはこんなプログラムは実務では必要ないと言い訳をするだろう。

そこで、言い訳をせずにできたプログラマーが、いざというときに結果を残してくれるプログラマーだということがわかり、将来、高級エンジニアになる可能性があるエンジニアとして素質を見つけれることにもなるのかな?

C言語に関する書籍

| | コメント (2) | トラックバック (0)

より以前の記事一覧