Aggressive Style 5

読者です 読者をやめる 読者になる 読者になる

Aggressive Style 5

昨今はコミケ関係を中心に書いています。同人やニコニコ動画方面で活躍される方の相互リンクをお待ちしています。

IT初心者が、IT企業で生きて行く上で必要な5つの背景知識をまとめてみた

追憶

今回はソフトを使う会社側の特徴、作る側の会社側の特徴をまとめてみた。会社の特徴のみならず、商売道具の使い方の勉強のやり方、商売道具の活用の仕方、商売道具の運用の仕方など日々思ったことを以下の第一章〜第五章までの5つの章に分けてまとめてみた。まとまりのない文章になるが、是非とも読んで欲しい。

第一章:会社の中でのIT技術の流れ

日本国内のみを見渡し、IT企業と言っても様々だ。IT企業といっても様々。例えばPhotoshopのような専門的な知識を要求するAdobe Systems2ちゃんねるfacebookと言ったBtoC向けの製品を企業。方や企業向けBtoBな会社も多い。第一章ではBtoBに的を絞り、こうした会社にIT系のツールが導入される流れを以下にまとめてみた。

  1. 事業が発足する。
  2. 会計、営業、現場、販売...と事業の枠組みが完成していく。
  3. 会社の枠組みを動かす上で、非効率な仕事をIT技術などで置き換えて行く
  4. IT技術や調査スタッフなどを使い、売り上げ向上の要因などを調査し、よりよい結果に持って行く(この他高負荷に耐えられるような設計を考案し直すなど)

1〜4の順番は前後するが、3〜4の段階からIT技術が入り込んで行くことが多い。要は会社の枠組みを構成する上で必要なシステムを作って行く流れとなるのだ。例えば商品のおつりの計算をするとき、まずは算盤、次に電卓、最終的にレジで計算するようになる。こうして人為的なミスが多くなる等で非効率になる箇所等を置き換えるような仕事が発生する。

次に3の段階で日々の売上の集計を行うが、グループ店の場合POSのデータを一カ所で集計する。こうなると実店舗では作業中心となり、本部の方で売上の集計や経理を行うようになる。こうしてITにより業務の枠組みが変わって行くようになるわけだ。

今度は過去の事例を基に、どうしたら商品が売れるか?を考えるようになっていく。この過程が4の段階に当たる。各店舗のレジの集計結果を1カ所に集め、「コンビニのおにぎりの値段は何時100円に下げると、利益向上が見込めるか?」などを調査するようになって行く。そして3の仕事をエンジニアと呼ばれる人たち、4の作業をデーターアナリスト、データーサイエンテイスト、コンサルタントと呼ばれる人たちがそれぞれ担当する流れとなる。もちろん4の周りで仕事をするツールを開発しているデーターマイニングエンジニアという職種も存在する。ここで3〜4をまとめる上で「できるポケット+ ビッグデータ入門 分析から価値を引き出すデータサイエンスの時代へ (できるポケット+シリーズ) 」を参考にした。データの活用法の詳細があるので、是非とも読んでみて欲しい。

できるポケット+ ビッグデータ入門 分析から価値を引き出すデータサイエンスの時代へ

できるポケット+ ビッグデータ入門 分析から価値を引き出すデータサイエンスの時代へ

第二章:どっちがいいの?社内案件or外注案件

さて今日ITを駆使する企業は沢山ある。その中で社内にIT部門をおく企業と、社内にIT部門をおかず、外部からツールを買ったり受注する企業の二つに分かれる。ここで前者から受けた案件を社内案件。後者から受けた案件を受託案件と呼ぶ事にしよう。以下分類の仕方が雑な気もするが、以下自分の経験上からそれぞれ良かった点、悪かった点をまとめてみた。

社内案件の会社で働いて良かった点

  • 他業種(職種)の業界事情を仕入れやすい
  • 他業種(職種)の人脈を広げやすい
  • 会社全体を見渡して、必要な機能を追加しやすい(1〜4全てに携わりやすい)

社内案件の会社で働いて悪かった点

  • 会社や業界に取って必要な技術を売る形式になるので、IT関連の技術習得がしにくくなる場合が多い

受託案件の会社で働いて良かった点

  • 色々な会社の案件に当たれ、技術を覚えやすい。

受託案件の会社で働いて悪かった点

  • 技術を売りにした会社程、IT技術以外の事情が見えにくい(変に技術よりな会社に多い)
  • 作ったソフトウェアの実際の効果を確認しにくい(顧客の声を聞きにくい)

強引にまとめると技術は程々でも良いから総合的にやって行きたい場合は社内案件技術一筋で行きたい場合は受託案件と言った具合になる。

第三章:実務を通して勉強していく流れ

自分の場合最初はナイトワーク系のホームページの改修で、そもそもクエリすら知らなかった。良く勉強しろ勉強しろと言われた事もあったが、実際に何を勉強すればいいの?第三章では自分が今までで実務を通じて勉強していった流れを説明する。今回はSNSやブログやCRMと言った、DBを扱う案件に絞って説明する。

まずは基本的な書籍と格闘

まず自分の場合はナイトワーク系のホームページの改修案件からスタートで、だんだん一からシステムを作成するような流れとなった。この際やった事は「独習○○○」と言った基本的な書籍を覚え、クエリと言った基本的な用語を覚えていった。おそらく最初の頃は基本的な用語の意味を覚えつつ、要件達成の為に必要な事を覚えて行く流れとなる。本を読む際に気をつけなければならないのは、1ページ目から読もうとしない事だ。

この点が学校の勉強とは違う方法だ。まず学校の勉強は、教科書をP1〜最後まで流すように勉強していく為順序立てて知識を習得しやすい。しかし実務の場合時間の問題で、こうした事をやっている暇が無い場合が多い。具体的には今日は教科書のP20、明日はP30と言うように実務で使われた順に覚える流れとなる。この時そのページに付箋や折り目や栞などを挟み、常に復習しやすくするようにしておくのもコツだ。

次にシステム全体をまるっと覚える

ここまでをまとめると「要はA社内でやっていくのに必要な事をその都度覚える」事がコツだ。最初はシステムの改修をまかされ、いよいよ上司から「よし、一システム作ってみろ」と言われるようになる。自分の経験上こうしたときは、ステージ1、ステージ3、ステージ5をクリアする事ができても、どこかで踏み外している箇所があったりする。言い換えるならプログラム全体の部分部分はできても、全体を理解できてない状況となってる場合が多いはず。こんな時勉強でどこまでやれば良いのかを自分なりにまとめてみた。

  1. MySQLなどのテーブルを定義し、それを表(Excel)にまとめる
  2. サーバー側の言語(Java,PHP,Perl,Ruby on Rails,Python等)でDBに接続、SQLのクエリの実行の方法を覚える
  3. 各項目の入力(insert)、表示(select)、更新(update)、消去(delete)画面を作れるようにする
  4. SQLインジェクションXSS対策を考慮したり、入力された内容が正しいかを調べる(validate)の方法を覚える

フレームワークなど全体の仕組みを把握した上で作成する

閑話休題。第一章の会社の仕事の流れにも枠組みが存在するように、プログラムにもフレームワークと言って設計〜運用までの作業の枠組みを定義したものが存在する。会社の創業から数年経っているような古いシステム程フレームワークは使われない傾向があり、最近ではメンバーのみんなが作業しやすくするため等の事情で採用している会社(案件)も多い。

もちろん会社に応じて使っている言語やら、フレームワークなど使う商売道具も違ってくるわけで、それに合わせてその都度必要な事を覚える事が肝心だ。この際自分の場合ならば担当する会社の案件のフレームワークや言語が分かったら、その説明を書いた書籍を押さえておく事だろう。

以上自分の経験上から仕事の覚え方をまとめてみた。ここまで読んで、もっと初心者向けの方法が聞きたいと言う方は「プログラミング未経験のタワレコ店員がエンジニアになって思ったこと」というスライドを書いてみたなどを読んでみてほしい。

第四章:「結局どのフレームワークや言語や環境がいいんですかね?」と言った宗教論争について

最近ブログなどで「結局どのフレームワークや言語や環境がいいんですかね?」という商売道具に関する宗教論争が盛んだ。第三章のような基本的な事を覚えた後でも、「いったい何を覚えるべきなんですかね?」と言う悩みはつきない。個人的にその理由の一つに宗教論争があると考え、第四章ではこの宗教論争について語ろうと思う。

小規模の会社でやって来た自分としては?

まず自分の場合事業規模が数10人未満の会社、つまりユーザー数が数10人程度のソフトウェアを1から作ってきた。主にクライアントの要望や納期を聞き取り、その通りのシステムを作成し、納品する。そして納品したものを活用しクライアントの業務の枠組みを改善。こんな理想的な流れでやってきた。

そんな自分からすればそもそもクライアントの商売道具を作る話なので、自分が今まで使って来た商売道具を使い、クライアントの商売道具を作る事に力点を置くだろう。使い慣れた商売道具を使い結果的に短期間で納品。その分ソフトの操作法や活用法をまとめた説明書を作り、使う側がすんなり運用できるようにする等に力点を注いでいく。

ここでクライアントのための商売道具の作り方をまとめたブログとして、「システムコンサルタントとは何ぞや? | 株式会社メイプルシステムズ」があるので紹介したい。

大規模なWeb系会社の場合は?

一方SAPやSNSと言ったユーザー数が数100万人規模の場合はそうは行かず、サイトの表示速度の事まで考慮する必要が出て来る。又ページ数が数100ページにも及ぶだろうし、そういった運用もしやすいような商売道具の選定が必要となるだろう。さらに「各エンジニアの負担(コスト)=習得コスト + 設計、運用にかかる人月コスト」と考えたときコスト管理をどうすべきか?と悩みがつきない。昨今では「優秀なIT技術者の定義:TAIMEI'sBlog:TriFort社タイメイのブログ」等で「いやいや作る側が仕事しやすい手法も大事だけど、機械側が仕事しやすい方法を考えないと」と言う意見も出ている。

結論:制約条件に応じた商売道具の選定が必要

強引にまとめると「○○が素晴らしい」と言うよりも、「使う側が使いやすい」「作る側が運用しやすい」「機械側が仕事しやすい」「ユーザー数○○人を想定」「事業規模○○人」と言った制約条件に応じた商売道具の選定が必要だと考える。ただ「○○が良い」だけでなく「▲▲という制約条件の下で、□□の面でメリットがあるので、○○を採用する」と客観的に言えるように心がけたい。

第五章:商売道具の手入れも大変

又一度選定した商売道具を長く手入れしていく必要も出て来る。第五章では「商売道具のメンテナンスも大変だよ」と言う事を話す。第五章では数100万人が使うサービスの運用方法を例に話してみたいと思う。例えば我々がamazonで注文した商品は、工場から運送屋の手に依って運ばれ、我々の手に届く。一方我々が今画面上で見ている情報というのは、株式会社はてなが保有するサーバーから、通信回線や基地局などのインフラを経て各端末がそれを受け取る形で見ている訳だ。

このとき通信回線の速度はどうしようもできないので、サーバ関連で以下の点を手入れすることとなる。

  • LinuxWindows Server等のOSが遅い原因なので、OSの通信に関わる部分を調整する
  • データを引っ張るデータベースの構造が遅い原因になっているので、構造を見直す
  • データベースをからデータを引っ張るSQL文(Select)を見直す(こちら参考)
  • ユーザーからの呼び出し回数が多そうな内容は、あらかじめメモリ上に溜め込んでおく(KVSの活用)
  • AjaxやNode.js等非同期通信の技術を使って、一遍にデータベースから引っ張って来るデータ量を減らす
  • ユーザーの端末に送り届けるhtmlを軽量化する

尚上記は自分が思いついた事や、「Web開発者のための-大規模サービス技術入門-―データ構造、メモリ、OS、DB、サーバ-PRESS-plusシリーズ」等から聞きかじった内容を元に書いてみた。こうした手入れができる人は重宝される傾向にある。さてこういう人に主導権を握られてしまったり、自分が居ないと組織が回らないようにしてしまう現象が発生するなど黒い事情もあったりする。

尚この話はゲームの「now loading画面」に似ている。スーパーファミコンの頃はカセットの容量も少なく、画面遷移の際に読み出すデータ量も少なかった。しかしプレイステーションになると、画面まわりの容量が増え、画面遷移の際に読み出すデータ量が多くなった。このためロード時間が余りにも長いので、プレイステーションを叩きたくなった事は誰しもあったはずだ。この仕事をやっていると、now loading画面は、こうした事情を隠す為の画面と言う事が分かってくる点も面白い。こうしたロード時間短縮と言うのも案外大変な案件だと思う。

最後に

この連休、統計の本を読んだり色々やってみた。作りたいものが見当たらないので、様々な会社の特徴のまとめ記事を書いてみた。その会社毎の考え方を上手く読み取れず、失敗する事の多い自分なのでこういう時間があったのはありがたい。GWも残り48時間を切ったが、皆さんも有意義に生活してほしい。