へなちょこSEの考察

0x22歳のへなちょこSEが、日々思うことを考察します。自社内、金融系を経て現在法人系PKG開発に従事。

■

Oracleの分析関数とWITH句を同時に使えない

Oracleで分析関数（Rank）とWith句を同時に使用しようとしたら、
SELECTを実行するだけで
「ソケットから読み込むデータはこれ以上ありません。」
とか言われて接続が切れてしまった。

ググってみてもあまり情報が出てこないし、なんなんだ・・・。
とりあえず、分析関数とWITH句が相性が良くないのではないかと思うので、
使わずに済む方法を考えます。

何かご存知でしたら教えて下さい。

iPhoneの「iPhoneのロック解除パスコードを○分以内に変更してください」問題

今日、突如としてiPhoneにこんなメッセージが。
「iPhoneのロック解除パスコードを60分以内に変更してください」

何この怪しさバツグンのメッセージ。
即座にネットで調べてみると、どうにも対処法が出てない。
参考にしたのはここ

http://unsolublesugar.com/20160508/213844/

読んでみたけど、結局これを書いた人も原因は不明だったらしい。
でもなんか「MDM」がどうとか書かれてて、あれこれはもしやと思って、思い当たるところをいじってみた。

直った。

会社でiPhoneアプリの開発をしていて、開発用のプロファイルを自分のiPhoneにも入れてました。
なんかそれが怪しいなと思ったので、削除してみると、以後メッセージは表示されなくなりました。
なんでそれで直るのかは不明だけど、とりあえず直ったから良いか。
プロファイルなんか入れてねーよって方はまた別の原因なのでしょう・・・。

iBatisのDynamicタグを使う際の注意点

iBatisのDynamicタグを使う際の注意点

iBatisなんて使ってる人いないかもですし、
MyBatisもそうなのか知りませんが、
今日つまずいたのでメモ。

isNotEmptyのprependを使った

WHERE句の直後に来るかもしれないところで、
必要だったのでprependを使いました。

SELECT a,b,c from sagyoTable
<Dynamic prepend="WHERE">
  <isNotEmpty prepend="AND" property="ymdFrom">
    sagyoYmd >= #ymdFrom#
  </isNotEmpty>
  <isNotEmpty prepend="AND" property="ymdTo">
    sagyoYmd <= #ymdTo#
  </isNotEmpty>
</Dynamic>

まぁ、よくある使い方だと思います。
これで実行すると、WHEREはつくけど何故かANDが付かない。
書き方が悪いのかと思っていろいろ書き換えてみましたが、それでもうまくいかない。
なぜだ、なぜなんだ・・・・。

おや、他のとこでも同じプロパティを使ってるぞ・・・

よくよく見ると、同じプロパティを別のとこでも使ってる。
それも、使い方が違う。
具体的には、こんな感じ。

 SELECT a,b,c from sagyoTable WHERE A = B
  <isNotEmpty property="ymdFrom">
    AND sagyoYmd >= #ymdFrom#
  </isNotEmpty>
  <isNotEmpty property="ymdTo">
    AND sagyoYmd <= #ymdTo#
  </isNotEmpty>
  ～～～

まさか、これに引きずられているのではあるまいか・・・。
そんなまさかと思いつつ、別の場所の書き方を変える。

 SELECT a,b,c from sagyoTable WHERE A = B
  <isNotEmpty prepend="AND" property="ymdFrom">
    sagyoYmd >= #ymdFrom#
  </isNotEmpty>
  <isNotEmpty prepend="AND" property="ymdTo">
    sagyoYmd <= #ymdTo#
  </isNotEmpty>
  ～～～

動いた・・・

結論としては、同じプロパティを見るタグは同一のPrependを指定しておかないと、
別の場所の記述に引っ張られる可能性があるらしい。
ただ、どんなときに引っ張られるのかまでは検証できてない。
そもそも、iBatisなんてもう使うなよ的な話かもしれませんが・・・。

「アジャイル開発とスクラム」を読んで

考察

「アジャイル開発とスクラム」という本を読みました。


アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント


アジャイル開発にはちょっと前から興味を持っていて、できるところから、CI（継続的インテグレーション）やBTS（バグ・トラッキング・システム）を導入して下地を作り、そろそろ本格的に始めてみたいなと思っていたところでした。
その中でも特にスクラムに興味を持っていたのですが、いかんせん経験がないのでちょっとビビっていたところで、この本に出会いました。


書いている内容は、スクラムの基本的な紹介と、それを実践した日本の事例とインタビューが中心。
何より良かったのは、日本の事例で、日本特有の問題に直面しながら解決していった先人たちの、「想い」が書かれていたこと。
技術的なことや、対策的なことも重要なんですが、それより何より、「なぜそうまでしてアジャイルを取り入れたのか」を読めたことで、自分の中でも想いが強くなっていきました。


やらなきゃいけないことも、課題もたくさんありますが、ちょっとモチベーションは上がりました。
システム開発に携わっている人なら、とりあえず読んでみて損はない一冊だと思います。

要件定義についての幻想

考察
仕事の話。

最近お客さんのところに行っていて思うことは、要件定義で用件が固められるなんて幻想は抱いてはいけないということ。
これはやり方の問題ではなく、「不可能」だと認識する必要がある。
8割も決められれば御の字、実際には6〜7割程度しか決めることなんて出来ない。

決めることが出来ないのだから、変わる可能性があると認識しておかなければならない。
それは当然リスクな訳だけど、決まったと決めつけて進めるよりは百倍良い。

しかしそうなると、お金をどうするかと言うことになる。
お客さんとは、要件定義の段階で出てきた分のお金しか見積もってない。
でも、追加機能のために追加料金が必要。
当然、追加で支払ってもらうべきだが、なかなかうんと言ってくれないお客さんもいる。

あとは、要件として上がってはいたけど、細かい仕様で追加が必要になってしまった場合。
これはさらに請求しづらい。
向こうが言ってないとも言えるけど、こちらが聞き漏れてるとも言える。
業務のプロは向こうだが、システムのプロはこちら。
どちらのせいとも言い難い。

結局どれも、要件定義で要件が確定できないリスク分を見積もりに見込んでなくて、追加はその都度ってことをなぁなぁに進めると問題になりやすい気がする。
さらに言うなら、そもそも要件定義で確定した分を見積もって作るって形が難しくて、何か確定可能なものをベースに要件やシステムの開発範囲を柔軟にする方が良いのではないだろうか。

たとえば、上限金額を決めてしまって、その中で出来ることしかやらないとか、毎月の金額を決めて、毎月一定量の開発を行うとか（納品のない受託開発として最近有名かな）。
なんにせよ、複雑化してるシステム開発において、ウォーターフォール型の開発はいろいろと無理がありすぎる。
同時に、ウォーターフォール型の受注（という表現が適切かはわからないが）も無理があるので、違う契約の仕方、開発の進め方を考えなければならないのではないか。

それが、今の会社にいて出来るかどうかは、また別の話だけど。

就職活動の問題点

就職活動は、インターネットの登場で大きく様変わりしました。
就職情報サイトに登録し、気になる企業にエントリーし、履歴書を送ったりWEBテストを受けていく。
面接を受けていくスタイルは変わらないと思いますが、それを同時に何社もこなしていくという形は昔は考えられないことでした。


インターネットの登場によるメリットは、とにかく多くの情報を得ることができるようになったこと。
十数年前では知り得なかった企業と出会うことができ、自分の可能性を広げることができるようになったと言えるでしょう。
また企業の側も、広く全国から人を集めることが容易になったため、より優れた人材が集まる可能性を高めることができます。


ただ、逆に情報が増えたことによって、問題点も多くなりました。
簡単に情報が手に入ることによって、情報の取捨選択をこれまで以上にしなければならなくなりました。
たくさんエントリーできることによって、たくさん選考を受けなければならなくなりました。
企業側もたくさん呼べることによって、選ぶ手間が増えました。
競合する企業の数も増えたため、簡単には入社してくれなくなりました。


なにより最大の問題は、無駄が多くなりました。


100社のエントリーは当たり前、ということは、100社分のエントリーシートを書く時間が無駄です。
そのうち面接を何社受けるのかは分かりませんが、入らない会社の面接は極端に言えば無駄です。
企業側も、受からない人に対する面接などの時間を作ることは無駄です。
内定出しても辞退されてしまったらそれも当然無駄。


とうぜん、必要な無駄もあります。
何社か受けるのは、保険のために必要だったり、落とす前提でも何人か選考するのは、よりよい人材を集める上で重要です。
ただ、それが度を過ぎてしまっていないでしょうか。


就職活動の理想は、企業と学生が一対一でマッチすること。
現実には多少のロスは発生するでしょうが、その形を目指していく方が、企業にも学生にもいいのだろうと思います。
そういう意味では、いい意味での「コネ入社」というのをやった方がいいのかも。
または転職市場と同じように、新卒採用の現場でもエージェント的な人が学生を吟味して、企業はそのエージェントを信用して採用を行うとか。
そういう形を取った方が、お互いの無駄を省けて生産的な気がします。


学業に力を入れさせるために就職活動の時期を変えるのではなくて、そもそも就活のやり方を変えて行くべきなのでは、と思う今日この頃です。

iBatisで同じSQLを流用する際の問題

iBatisが変な動きをした。※正確には、TERASOLUNA
一つのリクエストの中で、同様のSQLを二回発行する必要があったので、二度使った。

SelectDAO seDao1 = new SelectDAO();
seDAO1.setXxxCd("aaa");

SelectResult [] result = query.executeForObjectArray("select1",seDAO1,SelectResult.class);

SelectDAO seDao2 = new SelectDAO();
seDAO2.setXxxCd("aaa");

SelectResult [] result2 = query.executeForObjectArray("select1",seDAO2,.class);


一回目は数件取得され、二回目は通常は一件取得されるようになっている。
一回目の動作は正しいのだけど、二回目がどうしても取得件数が多い。
中身をよく見てみたら、どうも一回目の時の取得結果が残ってしまっているらしい。
二回目で取得した件数が一回目の件数を下回っていると、後ろのほうが上書かれずに残る？


ちょっと想定外の動きすぎて困った。
とりあえず、一回目と二回目では微妙にSQLは異なるので、別のSQLとすることで問題は解消。
でも、なんか釈然としない。