下請け目線で見たシステム開発の世界!下請けとSIの良い所と悪い所。

f:id:stayyou:20141129232017j:plain
こんばんは。

最近色々書きたいことあったので、
どんどん書いていきます。

気がついたら東京に転勤してました。
お客さん(自分は下請けなので、SI会社の方)と
よく打ち合わせしたり一緒にテストしたりしてます。

下請けとお客さんという立場でシステム開発を
していて感じたことを今日は書いていきます。

悪い所

f:id:stayyou:20141129232115j:plain
書いていくとどんどん鬱になりそうなので、
まずは悪いところから書きたいと思います。

金がない

下請けの一番痛いところと言っても過言ではありません。


一次下請けならまだしも二次下請けなんて
なったらほんとにこの問題に悩まされます。


プロジェクトでの工数も少なく、
炎上した際に人を投入しようにもお金がない・・・


なんてことがよくあります。


SIで働いたことがないので、なんとも言えないのですが、
この問題に関しては確実にSIのほうが安全でしょう。


最近はエンドユーザの予算から少なくなっているので、
これはダイレクトにSI、そして下請けに響いてきます。

労働時間が長い

システム開発を行う際に必ずスケジュールを作成します。
しかしこれは確実に計画通りに行きません。


小規模で短いスケジュールなら大丈夫かもしれませんが、
大規模なプロジェクトにもなるとスケジュールは
あってないようなものです。


下請けは多発する問題、バグを解決し、
納期までに納品物を完成させなければいけません。


定時内で終われない場合は残業をして
終わらせないといけない会社がほとんどでしょう。


実際のところ、下請けが大変になると発注元の
スケジュールも遅れていき、同じく残業を
強いられることになります。


そういった意味ではどちらも労働時間は
長いですが、実際にバグ修正など時間がかかる
作業は下請けなので、下請けの方が大変だと思います。


徹夜が続いたり、体調を崩して会社に
来れなくなるといったことはよくあります。

下請けという立場

お金をもらっている立場ということもあり、
基本的に立場は弱いです。


見積に関しても基本的にSIがエンドユーザから
もらっている見積よりは低くなりますので、
見積が高いと言われれば、色々な理由を
つけて見積を下げるといったことがよくあります。


そういった状況の中で仕事をするのは、
後ろめたい気持ちがあるものです。

良い所

f:id:stayyou:20141129232203j:plain
最初に悪い所をあげましたが、
決して悪い所だけではありません。

今度は自分が働いてて感じる良い所を
あげていきます。

スキルが身につく

なんといってもスキルが身につきます。


単純にプログラミングをして、
スキルをつけることはもちろんですが、
問題解決のアプローチ方法や仕事の進め方など、
多くのことが身につきます。


日本であまり評価されていないことは
残念ですが、アメリカでは非常に評価されています。


しかし近年、エンジニアを優遇する会社が多くあり、
SIでやっているSE業務よりも下請けがやっている
PG業務の方が評価されつつあります。


こういった風潮がある以上、
やはりSIのやっている上流工程で
身につけれらないスキルが身につくのは嬉しい事です。

プログラミングができるようになる

システム開発の真骨頂であるプログラミングを
頻繁に行う下請けでは黙っていてもプログラミングが
できるようになるでしょう。


SIにいるひとではなかなか技術をあげることは難しく、
下請けにいるひとのメリットと言えるはずです。


将来起業をしたいと考えていたり、
アプリを作ってみたいと考えている人は
必ずプログラミングができてよかったと思う日が
来ると確信しています。


お金で他人に頼むのではなく、
自分で作れるということは言うまでもなく魅力です。

最終的な責任を追わなくていい

最終的な責任を追わなくてもいいというのは、
精神的なメリットであると考えます。


もちろんお金をもらって仕事をもらっている以上、
下請けにも納期や品質を守る責任はあります。


しかし、
SIの見積が桁違いに違っていて全く話にならない、
下請けがどうしようもなさすぎて完成しない、
と自体は起こってしまうものです。


ニュースに取り上げられるような大規模なプロジェクトで
そういった事態になると社名が出てくるのはSIであり、
その際にエンドユーザに頭を下げるのはSIです。


下請けはSIから切られるだけで済むかもしれませんが、
SIは以降すべての案件に影響が出てくる可能性があります。


そういった意味で下請けはまだ精神的に
余裕なのかもしれません。

まとめ

f:id:stayyou:20141129232239j:plain
良い所と悪い所の両方を書いてみました。


私のようにまだまだ下っ端の立場からすると、
SIの年収の高さは正直魅力的だと思います。


しかし、
将来的に長い目で見るとスキルがある分、
下請けが有利なのかもしれません。


「SIは下流業務のスキルが不足している分、
自分の時間で勉強をする。」


「下請けは収入が低い分、
本業とは別に仕事受けたり、アプリ作って副収入を得る。」


などのような、それぞれ努力しなければ
いけない所が出てきます。


ここまで色々書いてみましたが、
結局はどちらが自分の中で納得いくか
という所になるのかと思いました。



上流・下流工程から改善・監査までわかる システム開発のすべて


月間PVが100超えたので色々話していく。

f:id:stayyou:20141129164507j:plain
こんにちは。


気がついたら、月間PV100超えてました。
やっとです。どれだけ時間かかってるのか(笑)


記念なのでPV100超えて感じたことや
良いこと悪いことをずらずらと書いていきます。

1.ブログを更新しない

f:id:stayyou:20141129164251j:plain
ブログ初めて66週間立ってました。

やっと100超えれたことを考えると、
ブログを更新しないことは明らかに悪いことです。
やはりブログの更新率は重要だと思います。


正直ブログで広告収入が入ることを願っていますが、


・ネタがない
・書くのが面倒くさい


という理由で記事を投稿できていないことが
PV増加に繋がっていないんだと思います。

2.自分が思わずぐぐりたくなる記事を書く

これは重要。


PV100の中に自分がアクセスした回数も含まれています。
過去に投稿した記事は「◯◯のやり方」といったような
メモ代わりの記事がいくつかあります。


仕事をしている中で、「あれのやり方どうだったっけ?」と
たまにしかやらないことは案外覚えていないものです。


結局思い出せずぐぐってみると過去に参照したサイトではなく、
自分のブログを参考にすることが多々あります。
(気がついたら自分のブログだったなんてことがあります。)


メモ程度で書いたため、内容が濃いわけではないですが、
要点がまとめられているため、分かりやすいのです。


検索で一番上に出てくるようなしっかりと書かれた記事は
SEO対策上も効果的なのかもしれませんが、
検索をかけるひとから見ると二、三番目に出てくる
簡素で分かりやすい記事のほうがアクセスを集めやすいのかもしれません。

3.タイトルや内容は大雑把なキーワードを入れる

アクセス数の多い記事を見てみると、


「java.sql.SQLException: クローズされた接続です。」


といったエンジニアから見ると明らかに原因が
複数考えられる記事が上位に上がっています。


そのまま上司に聞くと「それだけじゃわかるわけ無いだろ!」
なんて怒られそうな内容ですね(笑)


しかし、すでにハマってしまった状態にあるひとを考えると、
詳細なキーワードで検索をできる状態ではないことが考えられます。


そうなると、プログラムの例外情報のような
知っているor見えるキーワードをそのまま検索する」と
いった行動が多くなるのかもしれません。


書き手にとっては原因となった詳細な情報を書くことに
目が行きがちですが、そこまで行き着いていない読み手にとっては
大雑把な現象や内容がしっかりと書かれていたほうが嬉しいと思われます。

4.モバイルで記事を確認する

f:id:stayyou:20141129164409j:plain
正直面倒くさいのであまり見ることがないため
説得力がありませんが、かなり重要なことだと思います。


今やパソコンユーザからのアクセスよりもスマホユーザからの
アクセスのほうが多くなっているのが、現状だと思います。


スマホユーザの増加率

スマートフォンからのネット利用者は直近1年間で1,100万人増加 ~ニールセン、2013年度(2013年4月~2014年3月)のネット利用動向を発表~ | ニュースリリース | ニールセン デジタル株式会社



そういった状況の中で「スマホから見やすいようにする」と
いうことは非常に重要な事です。


レスポンシブデザインでスマホに最適化されたサイトの効果

Not Found



記事を書き終えた後にプレビュー機能で記事を見るだけでなく、
投稿後に実際にスマホで見ることで文章が変に
改行されているなど、見づらくなっていることに気づくはずです。


「モバイルファースト」という言葉があるくらいですから、
常にモバイルからの見え方を考えるようにしましょう。

5.文章だけでなく、図や絵を使う

このブログで図や絵を使っていることはないのですが、
やはりどんどん使っている方がいいと思います。

というのも、他のブログを見ていると読み終わった後の
理解度が全く違うからです。

プログラミングやネットワークなど、
直接目で確認できないことについて図や絵を使うことは
非常に効果的です。

実際図を書くことで、ブログでの説明も
やりやすくなっていることを考えると、
読み手だけでなく書き手にもメリットがあります。

コンテンツとしての長い目で見ると、
手間はかかってしまいますが需要はあると思います。

まとめ

そこそこ長くブログをやっていましたが、
記事数や記事の内容がまだまだ少ないと感じます。


「ブログで少しでも副収入がほしい(笑)」
と思っている割には、「ネタあったら記事を書く」という
意識が足りないのでしょう。
※技術力の向上を目的としているブログです(笑)


月間PV100という節目で今までの分析ができたところで、
これからどんどん書いていこうと思います。

最後に

本ブログを見てくれている方々、
本当に有難うございます。


今後とも宜しくお願い致します!

あなたはResultSetをmodelに入れていませんか?CachedRowSetという強い味方。

あなたはResultSetをmodelに入れていませんか?
実はCachedRowSetという強い味方がいるんです。


CachedRowSetって何?という方。
まずは下記のリファレンスを読みましょう。

http://docs.oracle.com/javase/7/docs/api/javax/sql/rowset/CachedRowSet.html

英語です。
読む気になりません。

こちらの記事のほうが良いでしょう。

オフラインのResultSetとしてCachedRowSetを使う方法
http://d.hatena.ne.jp/seraphy/20140202

つまりデータベースから取得したデータを
そのまま保持できるというわけです。
ものすごく便利ですよね?

ResultSetの結果をmodelに入れなおして、
その変数を使用するといった実装をする方が多いと思います。

しかし、CashedRowSetを使うことで下記のように
スマートにメモリに保持することができます。

   // CachedRowSetを作成
   RowSetFactory rowSetFactory = RowSetProvider.newFactory();
   CachedRowSet rowSet = rowSetFactory.createCachedRowSet();

   // データベースのクエリ結果のResultSetをCachedRowSetに設定する.
   try (Connection conn = ds.getConnection()) {
       try (PreparedStatement stm = conn.prepareStatement("select col1, col2, col3 from hogehoge");
            ResultSet rs = stm.executeQuery()) {
           rowSet.populate(rs);
       }
   }

「〜(全角チルダ)」という悪魔のお話

「〜」

よく打つことありますよね?

「全角チルダ」「から」「波線」「にょろにょろ」
なんていっぱい名前があると思います。

そんな文字を私は「悪魔」と読んでます。(嘘です)

Linux + JavaのWebアプリケーションで開発していたところ、
変換できずエラー発生!

UTF-8でもOSによって、
文字コードに違いがあるらしいです。

参考サイト
http://space.geocities.jp/nequomame/java/mojibake/mojibake_01.html

変換処理を参考に修正しました。
たかが一文字ですが、されど一文字です。

Linuxのtmpフォルダにファイルを置いた結果・・・

「あれ?ファイルがない!」

プログラムが動くために必要なファイルを置いていたが、
いつの間にか消えていた。

誰か消したのかと思ったが、お客さんに確認しても削除しないとのこと。

どうしてだろうと思い、調べたところ、以下の記事を発見。

/tmpと/var/tmpの仁義無き戦い
http://qiita.com/kuni-nakaji/items/f29be14be578b5a19d4b

今回は/tmpを使用していたが、
どうやら「再起動するとすべて中身が削除される」らしい。

まったく知らなかったorz

対策としては、単純にファイルの場所を変えて対応。

かなり初歩的なミスをしてしまったが、いい勉強になった。
(tmpフォルダの下にしたのは自分ではないがw)


バージョンアップによるフォーマッティング関数の指定違い

PostgreSQLを8.1→8.4にバージョンアップした際、
エラーが発生するようになった。

エラーの原因を調査すると、
フォーマッティング関数を使用しているところで、
12時間制のフォーマットなのに24時間制の値を渡していたからであった。

時間の指定文字列が"HH"から"HH24"に変わった模様。
"HH"で指定していた部分をすべて修正することによって、
エラー解消。

参考サイト
http://www.postgresql.jp/document/7.3/user/functions-formatting.html

PostgreSQLで外部アクセスを有効にする方法

PostgreSQLで外部アクセスを有効したい場合、
postgresql.confを以下のように修正する必要がある。

修正前

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128               trust

修正後

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host all all 0.0.0.0/0 trust
# IPv6 local connections:
host    all         all         ::1/128               trust

上記のように"0.0.0.0/0"と書き換えることによって、
すべてのホストからアクセス可能となる。

例はすべてのホストからアクセスできるようにしたが、
"192.168.1.0/24"のようにIPアドレスの範囲をして許可することも可能。

セキュリティも考えれば、
あまり範囲を広げたくないところ。
1系2系用意する場合、以下のように2つ定義を行えば、
切り替えた後もアクセス可能となる。

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host all all 192.168.1.0/24 trust
host all all 192.168.2.0/24 trust
# IPv6 local connections:
host    all         all         ::1/128               trust


実践PostgreSQL

Google Chromeの印刷でテーブルの枠線が二重に表示される件

こんにちは。

今日はGoogle Chromeの印刷で
テーブルの枠線が二重に表示される件について。

まずは状況。
Google Chromeで印刷プレビューを表示し、印刷を行う。
そのときに1ページに収まらず、複数ページになった場合、
ちょうど行が2ページにまたがると、テーブルの枠線が二重に表示される。
(印刷プレビュー時点で二重に表示され、印刷してもそのまま)

調査したところ、
widthの%指定が良くなかった模様。

解決策としてはwidthをpx指定するように変更。

以降、現象は見られなくなった。

Google Chromeのバグなのかはわからないが、
はまってしまった。

jspで「java.sql.SQLException: クローズされた接続です。」その原因は?

こんばんは。

タイトル通り、こんなエラーが発生。

原因を調べてみると・・・
クラス変数のConnectionが取得してから使用する前に閉じれていた。

サーブレットは同一のインスタンスを使用しており、
複数クライアントからのアクセスを受けたとき、
上書きされてしまうことがあるそう。

参考サイト
http://www.pgmanual.net/cake/basic/details/c_id:2/basic_id:44

そのため、クラス変数をローカル変数にして処理を行うよう、実装。
エラーは起きなくなった。

そもそも、ローカル変数で実装できるものをクラス変数にしてるのは
スコープ的にどうかと思うのだが、とりあえず無事修正できて良かった。

Java Smack APIをインストールする

【自分用にメモ】

実践テスト駆動開発にて使用

Java Smack APIのダウンロード参考サイト
https://sites.google.com/site/chobimemo/xmpp/java-smack-api

zipのダウンロード先、ドキュメント、サンプルコード等あり