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

nosaさんのような、、、

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

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

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

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

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

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

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

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

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

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

C言語講習も

nosaさんのような、、、

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

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

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

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

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

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

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

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

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

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

nosaさんのような、、、

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

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

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

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

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

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

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

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

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

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

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

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

C言語土曜日講習

nosaさんのような、、、

土曜日１４：００より、社外の方も含めてしました。

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

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

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

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

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

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

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

nosaさんのような、、、

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

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

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

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

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

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

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

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

社内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年版、賃金状況を心待ちにして。

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

nosaさんのような、、、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nosaさんのような、、、

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

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

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

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

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

今回はメモ風に。

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

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

nosaさんのように、、、

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

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

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

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

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

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

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

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

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

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

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

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

C言語に関する書籍

会社でＣ言語を教えていたら、、、

がんnosaさんのような、、、今日は１歩近づきそう。

会社でＣ言語を教えていたら、その流れで現在しているウェブ制作（開発有）の話になりました。

簡単な作業に限らず、ウェブ制作の進め方のよくパターンとして、
１．要望を聞く
２．要望をフローチャートにする
３．エラー処理を洗い出す。
４．要望での確認事項を洗い出す。
５．調査項目を洗い出す。
※確認する人がお客様の場合として可能性があるのは、
６．画面遷移図を作る又はページ遷移の分かるプロトタイプを作る
があると思います。

建築業界のプロのように工程を抜かしても大丈夫なケースはありますが、やはりプロでない場合は、上記工程を抜かさず、進めたほうがいいように感じます。

最終的に、次のような効果が現れます。
■要望との認識のずれがなくなる。
■ユーザーに要望を再認識してもらう。（細かいところまで確認した場合、何かあった場合、時間が掛かる場合の理解に繋がる）
■ドキュメントが制作できる。
■運用性が高まる。
■調査を効率的に進めることができる場合がある。
■制作、確認事項の調整、調査、ユーザーとのコミット、運用準備を同期的に共有できる。
■正確な最短スケジュールを導きやすくなる。

頭でやろうとした場合、楽をしようとした場合、
３．４．が後回しになりがちのようです。（場合によってはしない。）

２．はしないケースが多い。

５．は自分の判断でする。

２．をすることによって、３．４．５．を確認してからウェブ制作をすることの意味は、
２．は、言葉ではなく、（感覚的になるのを防ぐand将来の履歴、仕様変更、運用ドキュメント、他、、、）ドキュメントに残すことができる。最終的に下記の項目が効率的になる。

３．は制作後の運用性の向上、ユーザービリティ向上に繋がる。制作及び試験時の効率に繋がる。

４．はユーザーとの認識のずれを無くす。ユーザーの要望の理解、ユーザーの制作への理解に繋がる。しかも効率的に。

５．or６．精度の高いスケジューリングに役立つ。調査が効率的になる。
６．の場合は、上記２．～５．の再確認にも役立つ。
と考えられます。

今一度、上司のおられる方は部下として、部下のおられる方は、部下の作業の上記を見直すことによって、
上記■項目の効果が現れるのではないでしょうか？

慣れてきたり、スキルが足りなかったりすると、どうしてもできない２．～５．or６．はおろそかになったり、省いたりしがちですが、■の効果を将来又は現作業で期待する場合は、是非、もう一度思い出して実践されては。

理由として時間がないを考えるとできませんので、■の効果を期待するだけを考えて実践することをお薦めします。早く済ませたいや時間がないという雑念を取り払う方法があれば、知りたいですね。知っている人はコメント頂ければありがたいです。

と、たまには真面目な内容でした。明日は、また、「ぽよ～ん」とか書いていたりするかもしれません。
C言語に関する書籍