コストについて考える

こんにちは。

今日は、コストについて考えてみたいと思います。

突然ですが、みなさんは自分の時給がいくらか計算したことありますか？

会社員だと毎日出社すれば、決まった給料が支払われるので気になりませんよね。

でも、学生時代はバイトの時給って気になってませんでしたか？
私も学生時代は、時給を見てバイト先を探していました。

でも、社会人になって給料を貰うようになると、時給よりも残業時間が気になるようになりました。残業手当が給料に大きく影響しますからね。

では、なぜ今、時給を気にするかというと、昨今の働き方改革で残業代が減ったからではありませんよ(笑)

結論から言うと、無駄な時間を出来るだけ減らして、自分の時間をみなさんに生きてもらいたいのです。

もっと言うと、私の大切な時間を勝手に使うな(怒)と言いたいのです。

あなたの時給はいくら？

ではまず、自分の給料から時給を計算してみましょう。

ここで使うのは、額面(各種保険料、税金が控除される前の金額)です。

例えば、額面が30万だとします。
ひと月の勤務日数が20日とすると、1日15,000円。
1日8時なので、時給は1,875円です。
(思ったより時給安いですね。)

1時間の会議はいくら

では次に、毎日行われる1時間の会議の費用を考えてみましょう。

毎日１時間、その日の進捗状況を確認する会議が１０人で行われるとします。
１０人の時給は同じとすると、1回の会議のコストは18,750円になります。
１ヶ月で375,000円となります。

何と、この毎日行われる会議をやめることで、１人雇うことができます。
（実際には、１人雇うためにはもっとかかるのですが。）

あなたがやってるその作業はいくら

では、今あなたがやっていることは、時給に換算するといくらになるのでしょうか。
（お金だけが全てではないことは分かっています。）

でも、大切な時間を会社に言われたことのみに使っていないでしょうか。

大切な時間を、ゲームをしたりテレビを見たり、娯楽のために使いすぎていないでしょうか。

それでいて、「お金がない」「時間がない」を言ってないでしょうか。

本当にそうでしょうか。

まとめ

では、本題に戻りましょう。

自分の時間を大切に使うには、その時間の価値を考えると良く分かります。

あなたにとって時間が大切なように、私にとっても時間は大切なのです。

誰かの時間を借りるのであれば、それだけの準備をし、最大限の利益を得るように心掛けるようにすることで、大切な時間を有益なものにできるのではないでしょうか。

そうして、自分の時間を生きていきましょう。

では、今日はこの辺で。

システム会社の現状

こんにちわ。
今日は、雨の休日です。

さて、今日は、システム会社の現状について書いてみたいと思います。

これから就職活動や転職を考えている方の参考になればと思ってます。

大手メーカー企業とその他の企業

大手メーカー系のシステム会社と、中小のシステム会社では、ビジネスモデルが違います。

ビジネスモデルとは、利益を生み出す製品やサービスに関する事業戦略と収益構造を示す用語である。（ウィキペディアより）

大手メーカー系のシステム会社のビジネスモデル 

大手メーカー系のシステム会社のビジネスモデルは、大きなシステム開発を受注し、上流工程（仕様調整、基本設計）を社員が行い、下流工程（詳細設計、プログラミング、単体試験、結合試験）は、子会社やパートナー会社、中小のシステム会社にやってもらいます。

なぜ上流工程のみ行うのかというと、大手メーカー系のシステム会社は、独自でシステム基盤を持っている場合が多く、システム開発でも独自のシステム基盤を使用するためです。

独自のシステム基盤を使用してもらうことで、その使用料を保守運用費に上乗せすることができます。独自のシステム基盤をどう使うかを決めてしまえば、その上で動作するアプリケーションを下流工程（子会社やパートナー会社、中小システム会社）で作成することになります。

下流工程の作業が完了すると、そこで作成されたアプリケーションを、システム基盤に乗せて仕様通りに動作するかを確認します。

あとは、本番環境へデプロイして納品することで完了です。

つまり、上流工程が終われば、下流工程を行っている時間は空くことになります。その時間を使って、次のシステム開発の上流工程を行います。

そうすることで、自社独自のシステム基盤を盛り込んだシステム開発をどんどん開発することで、保守運用での利益を追求しています。

大手メーカーが持っている独自システム基盤は、作成された後、不具合が発生するたびに対応しているため安定して動作しています。

しかし、その反面、最初に作成されたのが一昔前なので、動作するシステム環境はかなり古い場合が多いです。古いシステム環境にセキュリティ対応を施し使っているのが現状です。

それに、多くの人が不具合対応を行うため、ソースコードがスパゲティー状態になっています。スパゲティー状態とは、一つの処理が長いソースコードとなっており、解読が難しい状態を言います。（スパゲティー状態のソースコードを改修するのは苦痛でしかありません。一箇所変更するだけで動作しなくなる場合もあるからです。）

中小のシステム会社

では、次に中小のシステム会社のビジネスモデルについて書いていきます。

中小のシステム会社の多くはSES（システム・エンジニアリング・サービス）を行なっています。主事業がSESという会社も多いです。

SESとは、システム開発や保守・運用に技術者の労働を提供するサービスです。

主に、大手メーカーの下流工程を行ったり、別の会社のシステム開発や保守・運用を出向して行うことが多いです。

企業としては、技術者を出向することで、固定収入が毎月入るため安定した事業となるのでリスクも少なく、技術者が信用を受ければ、継続的に契約がとれるため、新規営業を行う必要がないのです。

求人内容で、社員数が多いのに実際事務所に行ったら、社員がほとんどいない会社は、SESを主事業としていると考えて良いでしょう。

SESでの出向は、若い方やIT業界での経験が浅い方にはおすすめです。なぜなら、出向先では、下流工程を担う場合が多いからです。つまり、プログラミングを行うことになります。システム会社でまず面白さを感じられるのはプログラミングでしょう。それに、人柄がよければ、継続で同じ会社へ出向となります。長い時は、５年〜１０年となりますので、出向先の社員とも仲良くなることができます。

しかし、弊害もあります。一つの会社で下流工程のみを行うと知識が偏りがちになります。また、出向先で上流工程を行うことはまれで、スキルアップを目指すことが難しくなります。

また、出向している技術者は、プロジェクトの終盤で次のプロジェクトに参加できるのか、このまま、同じ会社で作業できるのかといった不安をもつ人も多いです。

中小のシステム会社のその他の事業として受託開発があります。

受託開発とは、顧客からシステムの開発を請負うことです。つまり、上流工程から下流工程まで行うことができます。

中小のシステム会社へ開発を依頼する会社は、やはり中小企業が多いです。なぜなら、大手のシステム会社は、独自システム基盤を使うため開発費用が高額になります。それに比べて、中小のシステム会社は、オープンソースを使用するため開発費用が低く抑えることができるのです。

発注する中小企業では、IT技術のスキルが低いことが多く、何でもシステム化することで利益が増えることを夢見ていることが多いです。（これ困るんですよね。）

中小のシステム会社では、請負った企業の業務状況を調査し、システム化できるところと手作業が必要なところを分けて仕様を作成する必要があります。

本来、仕様作成は、依頼する企業が作成するのですが、中小のシステム会社が受注するシステム開発は、その仕様作成を受注するシステム会社が行うことが多いです。（そのため、出来上がったシステムが使い物にならないなど問題になることもあります。）

このように、システム会社と言っても、大手と中小では担う作業が異なります。就職する際には、自分がどのような経験を積みたいのかを充分に考えて会社を選ぶ必要があります。そうしないと、やりたいことがやれなく、精神的にまいってしまうということになり長くは続きません。

これが、システム会社の現実です。

では、今日はこれで。

久しぶりの投稿

かなり久しぶりに投稿します。
どんだけ久しぶりかというと、２年ぶりの投稿になります。


２年間、Bloggerでは書いてなかったのですが、
実は、いろんな無料のブログサービスを使っていました。

めぐりめぐって、結局Bloggerに戻って来た感じです。

無料のブログサービスも今は色々と良いところがあったのですが、
何となく書き辛かったり、見た目が気に入らなかったりで、
長い目てみて使いやすいのは、Bloggerかなと思いました。

また、これからBloggerに投稿していこうと思いますので、
よろしくお願いします。

自己紹介

かなり久しぶりなので、まずは自己紹介をします。

私は、佐賀県に住むシステムエンジニア です。

会社は、福岡の小さなシステム会社で、１時間半程かけて通勤しています。

システムエンジニア と言っても、やってる仕事はプログラマー的な仕事が主で、主にWeb系の開発を行っています。

IT業界の方は分かると思うのですが、Web系と言ってもホームページ作成ではないですよ。企業の基幹システムの開発だったり、アプリケーションの作成だったり、たまに企業のホームページ作成などもしています。

IT業界歴は長く、１０年以上になります。

昔は、組み込み系の仕事（携帯電話のミドルウェアの作成など）をやってたのですが、７〜８年前から組み込みの仕事が減ってきたので、スキルチェンジしてWeb系の仕事をするようになりました。今では、バリバリでもないけどWeb系の仕事をやってます。

その他にも色々と考えてて、今後その辺もこのブログに書いていこうと思っています。

使えるプログラム言語は、C/C++、Java、PHP、.NET、SQLとメジャーな言語は使えます。

その他、HTML、Javascript、CSSも使えます。

ITに関するご相談にものりますので、コメント頂けたらと思います。

では、今日はこの辺で。

プロジェクト開始前に決めておくこと

これまで、多くのプロジェクトに参加してきました。
しかし、毎回と言って良いほど、プロジェクトの最終段階で炎上している。

原因を分析すると、プロジェクトの開始時にクライアントと決めておかないといけないことを、やってないための場合が多い。

そのため、クライアントの要望が増大し、無理に要望を組み込む事で、品質が大きく低下する状況になる。また、プロジェクトが炎上し、そこに携わるエンジニアに多大な負担をかけることになる。

エンジニアは、ロボットではないし、資源でもない。使えなくなれば、変えれば良いということにはならないし、エンジニアを多く抱え込めばうまくいくわけでもない。

プロジェクト開始前に決めておくこと

少なくとも以下のことについては、プロジェクトを始める前に決めておく必要がある。これを怠ると、プロジェクトの最終段階で、炎上する可能性が高い。

開発理由の確認

まずは、クライアントがシステム開発を必要と考えた理由について、共有する必要がある。詳細を聞き、システム開発が本当に必要なのかを確認する。もしかすると、マクロを作ることで解決できるかもしれない。

ビジネスとしては、システム開発を行う方が利益を得れるので、プロジェクト化したい気持ちは分かる。しかし、使用されないシステムを開発するよりも、必要とされているものを作ることの方が、クライアントにとっては良いし、空いた時間で、別の開発をすることで、結果的に、利益を最大化できる可能性がある。

機能確認

開発理由を充分に共有できた上で、必要となる機能について決めて行くことになる。ここで、決めるのは、開発理由で上がった問題を解決するために必要となる最低限の機能である。

間違えてはいけないのは、外部設計でないことだ。UIは、設計段階で行えば良いし、細かい機能を言い出すと時間がいくらあっても足りなくなる。

ここで決めた機能については、納品する時に実装されていないといけない機能となる。

マイルストーン確認

次に必要となるのは、どの機能をいつまでに確認できる環境に上げるかということだ。開発方法によっても違ってくるかもしれないが、マイルストーンを決めておくことで、どんな仕様をいつまで用意してもらうのかを決めて行くことができるようになる。

また、クライアントからの要望を、どこまで取り入れるかの基準となる。

たまに、開発スケジュールを立てた上でマイルストーンを決めるプロジェクトがあるが、これは、エンジニアの負担をかけることになるし、クライアントからの要望を追加できない。

ウォーターフォールで開発するのであれば、各段階ごとに受けるクライアントのレビューでマイルストーンを決めることができる。

アジャイルで開発するのであれば、どの機能から作って行くか、どの段階でクライアントの確認が必要となるのかでマイルストーンを決めることができる。

ステークホルダ

ここで決めないといけないことは、お互いの窓口だ。クライアントにとって、開発側の窓口は、１つであった方が連絡が取りやすい。開発する側も、クライアントの窓口は１つ良い。それに加え、利害関係にある相手には、状況を共有しておく必要がある。

炎上するプロジェクトの特徴として、開発が進むにつれて、ステークホルダが増えて行く。ステークホルダが増えると、情報の共有に時間が必要となるし、突然、仕様が変更され、後戻りが大きくなる可能性が増える。

複数の企業が参画するプロジェクトの場合は、それぞれの窓口を確認する。

Q&A管理

クライアントと開発者との質問を管理する方法を決める。エンジニアであれば、お馴染みのことであるが、クライアントにとっては、使い方を知らない場合が多い。どのように記載するのか、どのように対応するのか、そして、どのように管理するのかを共有する。

この管理方法を共有できないと、複数の方法で質問がきたりする。ファイル、メール、チャット、電話…。

Q&Aの管理ができないと、プロジェクト後半で、言った、言わないの問題となり、プロジェクトは炎上して行く。

要望管理

多くのプロジェクトでは、要望の管理をしていない。なので、クライアントは、Q&Aに要望を記載する。しかし、Q&Aと要望は別であり、それぞれ管理しないといけない。

これまで、Q&Aに記載された要望は、エンジニアが抜き出して別管理していたところが多いのではないだろうか。

しかし、それでは、エンジニアの時間が開発以外の作業に費やされてしまう。それに、クライアントが要望と感じていないため、不具合となってしまう場合が多い。

リスク管理

これも、多くのプロジェクトで管理されていないのではないだろうか。

リスク管理で必要となるのは、どのような要因がプロジェクトの失敗に繋がるかをクライアントと共有することである。それぞれの要因について閾値を作り、定量的に管理していく必要がある。

そして、リスクが発生した場合の対応方法と共有しないといけない。ここでやっていけないのが、残業や休出で対応するということ。対応方法が、エンジニアに負担をかけて対応するのは、プロジェクト内で行うことであり、クライアントと共有することではない。

そもそもの要因が、クライアントによるものである場合は、エンジニアへの負担を最小限にできるよう対応方法を共有しておかなければいけない。

進捗管理

これは、多くのプロジェクトでやってるよ、と言われるが、それはクライアントと共有できているのでしょうか。月１や週１の進捗会議などで状況報告して終わりではないだろうか。それに、進捗の使い方をクライアントが理解していない可能性もある。

クライアントとしては、開発がどれほど進んでいるか以外に、確認がいつ必要になるかを知りたいのではないだろうか。クライアントは、実作業があるのだから、確認のために予定を早めに立てる必要がある。早めに確認できるのであれば、早く確認したい場合もあるだろう。

プロジェクトとしては、予定と実績を記録しておくことで、分析や今後のプロジェクトの参考にすることができる。

不具合管理

これも、多くのプロジェクトでやってるよ、と言われるのではないだろうか。

しかし、不具合管理で必要なので、出来上がった機能やシステムの品質を上げることである。そのために、必要となる不具合の量など、定量的に閾値を決めて、クライアントの要望する品質を担保する必要がある。

上記の「Q&A管理」「要望管理」「リスク管理」「進捗管理」「不具合管理」については、できれば、リアルタイムでクライアントと共有できるようにしたい。表計算ソフトで共有している場合がよくあるが、これは、内容が入れ子になって、漏れる可能性がある。それに、バージョンによりレイアウトが変わったりするため、共有するためのコストがかかってくる。

環境

これは、プロジェクトごとに作成するタイミングが違うのかもしれない。しかし、どれだけの環境が必要になるのかを、クライアントと共有しておく必要がある。

最低、以下の環境は必要になるのではないだろうか。

・本番環境

・ステージング環境

・開発環境

特に、本番環境をどう運用していくのかを決めておかないといけない。それによっては、本番環境をどこが構築するのか、ステージング環境を開発完了後どうするのかを決めないといけなくなる。

セキュリティの問題もここで決めておいた方がいいのかもしれない。既知のセキュリティ問題と、今後のセキュリティ問題に対する対応についても決めておくと、意識のズレが少なくてすむのかもしれない。

納品物

最終的に納品物について決めておく必要がある。よくあるのが、プロジェクト完了後に設計書が欲しいなどが出てくる場合がある。しかし、納品ようにドキュメントを作成するとなると、コストがかかるということをクライアントと共有しておかなければならない。

ドキュメントやソースコードには、著作権が発生することも、共有しておかないと、後々問題になることが多い。

今回は、私が、プロジェクト開始前にクライアントと決めておかないといけないと考える内容を記載した。と言うよりも、炎上した場合に後悔した内容をまとめた。

フリーランス募集をしている企業は、派遣法の改正によるもなのか

「フリーランスになる」と決意してから、半年が過ぎようとしています。

私は、エンジニアとしてフリーランスになろうとしているのですが、フリーランスになると言うことは、企業の看板（後光効果）を使わずに、自分の技術的のみで仕事を探さないといけないのです。

そうしたフリーランスと企業をつなぐエージェントの会社も、web上に沢山のあります。

そうしたフリーランス向けのエージェント企業のページを見ていると、企業に常駐して働くフリーランスの募集が多いようです。

派遣法の改正（平成２７年９月３０日施工）により、特定労働者派遣は廃止となりました。しかし、その時点で特定労働者派遣法をしている企業は、平成３０年９月３０日まで特定労働者派遣が可能となっています。

私が務める企業も、SES事業として、特定労働派遣を行なっています。来年の９月３０日までに一般労働者派遣の認定をもらえるとは考えられません。一般労働者派遣法の認可を得るには、いろいろと条件があり、私の務める会社では難しいようなのです。

私の予定では、6月までにフリーランスになる事を目標としているので、今勤めている企業のことは気にする必要がないように思いますが、フリーランス向けの情報サイトを見ていると、派遣法で規制されない任意契約で、エンジニアを集めようとしている企業の多さを実感されられます。恐らく、特定派遣で減少するエンジニアの代役を探しているように思われてなりません。

私は、時間や場所に拘束でされないライフスタイルに憧れてフリーランスになろうと決意しました。なので、仕事を斡旋してくれるエージェエント企業は使用せずに、仕事を探そうと考えています。

その場合、ソフト開発会社を探して、営業をかけて行くしか方法がないように思われます。

エンジニアとしてフリーランスで活躍されている方は、どのようにして仕事を得ているのでしょうか。

よろしけてば、お話を聞かせてください。