2012年9月16日日曜日

playframework1.2のJobでハマったところ

playframework1系は、リクエスト・ジョブ単位でトランザクションを管理している。 シングルトランザクションで業務処理を行う場合は、分かりやすいのだが、マルチトランザクションを用いないと実現できない場合は、かなり面倒なことになる。 
個人的には、playframework2.0系であれば、プログラマが自由にトランザクション範囲を定義することができるため、今後は2.0を使っていきたいが、1系のアプリケーションをメンテする必要がある場合は、マルチトランザクションを実装しないといけない場合があるだろう。 playframework1系でハマったところを備忘録としてメモっておく。 

今回、playframework1系で実現したい機能は以下である。 playframeworkのJob機能を使って、複数のバッチジョブを順に実行したり並行して実行するために、ジョブ制御テーブルをDBにもち、各バッチジョブの開始、終了時にジョブ制御テーブルを更新する。


まずは、playframeworkのJobクラスを拡張する。

トランザクションがネストしていないので、トランザクション境界にはJPAPlugin.startTx(false)とJPAPlugin.closeTx(false)を用いることがポイントだ。

業務ロジック用のJobはコンストラクタに設定してあげればよい。

public class JobInvoker() extends Job{

    /**
     * 業務処理をするJobクラス
     */
    private Job<JobResult> job = null;
    
    /**
     * コンストラクタ、業務処理するJobクラスを設定する。
     * @param job
     */
    public JobInvoker(Job<JobResult> job){
        this.job = job; 
    }    

    /**
     * Jobの実行状況を制御するJobStatusManagerを用いてステータスを変更する。 
     * @see play.jobs.Job#doJob()
     */
    @Override
    public void doJob() throws Exception {
        //この段階で既にトランザクションが開始されている。
        JobStatusManager manager = new JobStatusManager("JobA");
        try {
            
            if (manager.isExecutable()) {
                            //DBのテーブルにあるステータスの値を「実行前」から「実行中」に更新する。
                     manager.startJobStatus();
                     manager.commit();
                            //ここでcloseTxするか、DB.getConnection().commit()しないとDBに値が更新されない。
                     JPAPlugin.closeTx(false);

                            //ここから業務処理用のジョブの開始
                            //業務処理用に新たにトランザクションを開始する。
                            //doTask()メソッドがコンストラクタに設定したJobを呼び出す。
                     { 
                     JPAPlugin.startTx(false);
                            doTask();
                     JPAPlugin.closeTx(false);
                     }

                            //ステータス更新のためのトランザクションを開始する。
                     JPAPlugin.startTx(false);
                            //DBのテーブルにあるステータスを「実行中」から「完了」に更新する。
                     manager.completeJobStatus();
                     manager.commit();
            }

        } catch (Exception e) {
       //異常時はDBのテーブルにあるステータスを「実行中」から「異常終了」に更新する。
            manager.failJobStatus();
            manager.commit();
            Logger.error(e, "%s failed !", this.getClass().getName());

        } finally { 
         manager.close();
      if(JPA.isInsideTransaction()){
             JPAPlugin.closeTx(false);
      }
        }

    }

    /**
     * コンストラクタに設定したジョブを呼び出して結果を取得する。
     * @throws ExecutionException 
     * @throws InterruptedException 
     */
    protected void doTask() throws Exception {
        
        Promise<jobresult> promise = job.now();
        
        if(!promise.get().isSuccess()){
            Logger.error(promise.get().getException(), "Error", null);
            throw promise.get().getException();
        }
    }
}

また、上記のように実装した場合、設定ファイルのapplication.confもいくつか追記しないといけない。


  1. db.pool.maxIdleTimeExcessConnectionsを記述しないとDBのコネクションが解放されずに増え続け、一定時間後にPersistanceExceptionが発生する。
  2. db.pool.minSizeは、play.jobs.poolよりも多く設定しておく。そうしないとコネクションがタイムアウトしましたというPersistanceExceptionが発生する。


#Jobに割り当てる最大スレッド数の設定
play.jobs.pool=10

#DBの設定
db.pool.timeout=10000
db.pool.maxSize=40
db.pool.minSize=20
db.pool.maxIdleTimeExcessConnections=10

やはり仕事で使う場合は、マルチトランザクションは必要だ。また、常駐ジョブは一定期間の安定テストを行う必要がある。playframeworkでマルチトランザクションでバッチを起動するなら上記設定内容だけは覚えておきたい。

2012年8月25日土曜日

クラウド温泉3.0 に参加して(2)

<プログラマのための代数入門2 Monadへの道>

 

中村(@nakayoshix)さんに、Monadを説明していただきました。

といっても1時間でMonadの説明までたどり着くのは無理があるらしく、その前の群の説明が中心でした。特にルービックキューブを使った「逆元」「非可換」の概念は分かりやすかった。

Monadに関しては、日本語のWikiでは、十分な説明がないことが分かりました。

ただ、それをプログラムで実現する場合、IOとか外部の環境を考慮に入れる必要がある。IOなどの環境を包括してくれるモナドがどこまで使い物になるのだろうか。そこは、自分で検証する必要があると感じた1時間でした。

 

<「基礎から見直すTX処理〜A Critique of ANSI SQL Isolation Levelsを再読する」>

@okachimachiorz1 さんの発表。今回のクラウド温泉で最もインパクトが高い発表でした。

トランザクションについて、ANSIのSQL規格ではまだ不十分。理想とするトランザクションがコンピュータで実現された状態を100とすれば、現在はまだ40くらいだそうだ。(根拠はないけど)

私は、ANSIで定義したトランザクション分離レベル(これの理解も中途半端)が常識だと思っていたので、しょっぱなから頭をうたれた。

発表は、「A Critique of ANSI SQL Isolation Levels」を読むための前提知識と左記論文の概要を説明していただきました。

もっとも大事なことは一貫性(consistency)であり、それを実現するため、原子性(atomicity)、独立性(isolation)が存在すると解釈しました。

トランザクション実行後の「何が正しいのか」という基準を明確にする必要があります。

当発表では「isolationはserialisableになればよい」「semantic violationでないこと」を正しいと定義していました。ただ、「serialisable」と「serialised」を誤解する人が多いそうです。(私もそうでした。)「serializable」とは、トランザクションが「serialised」された状態と同じ状態を意味的に最適化したものを意味します。

「serializable」にするために、どうやってrockしたり、snapshotをとったりするのがよいのかまでは理解できませんでした。「Transactional Information Systems」を読めば分かるそうです。(といっても敷居が高い)

ぼちぼち勉強していこうと思っています。

 

<本当は怖いDNSの話>

鈴木(@tss_ontap)さんの発表。

あまり詳しく書くことはできないが、DNSの仕組みが不十分で、あるドメインが乗っ取られることがあった事例を発表していただきました。SSLなどドメインを取得してアプリケーションを構築する場合、セキュリティとしてこんなリスクもあるということを抑える必要があると思いました。

 

その後、小樽商大の教室をお借りして、ディスカッションをしました。

浅海さんの発表をベースに、OOPと関数型を使ったアーキテクチャ、モデリングについて議論しました。業務寄りの部分は今まで通りOOPを使い、基盤よりの部分に関数型を利用すると上手く構築できるのではという内容でした。サーバのコア数が増え、C10K問題を考えると、並列プログラミングをするためには、関数型を使って並列処理が可能な基盤部分のアーキテクチャを構築できる人が重要になってくると実感しました。

自分としても、このような基盤構築に関わっていきたいし、このような基盤を使ったソフトウェア、システムを構築したいと思える2日間でした。今後の仕事には、まずscalaを使ってパイプラインプログラミングが実際に使いモノになるのか検証できたらなぁと思っています。

 

最後に、中村さんをはじめ、発表していただいたみなさま、参加者のみなさま、ありがとうございました。今後ともよろしくお願いします。

 

 

 

2012年8月22日水曜日

クラウド温泉3.0 に参加して(1)

8/18,19と @nakayoshix さん主催の「クラウド温泉3.0」に参加しました。

本来であれば、何らかのアウトプットを出さないとなぁと思っていたのですが、転職して間もないこともあり、アウトプットを出すことは諦めました。

この勉強会に参加する一番の理由は、コストパフォーマンスの高さです。東京でこのレベルの勉強会をやろうとしても、人が集まりすぎて、参加者間のコミュニケーションがとれないからです。

各セッションごとの感想を書きます。

 

<Monadicプログラミング・マニアックス>

@asami224 さんの発表。これからのハードウェア、ネットワーク環境の変化に伴い、scalaなどの新しい関数型言語の長所を活かすポイントが分かりやすく書かれています。

 

「関数型言語を使うと何が便利になるのか」、自分の答えは、さまざまな処理を「並列」で動かすための仕組み(パイプライン)が揃っているからだと考えます。

今まで、WEBなどの画面から非同期でジョブネットを実行して結果を返すプログラムを作る場合、各ジョブの状態をスレッドセーフにしたりデッドロックとかを考慮する必要があるため、非常に難しい実装になります。一方で、WEBから大量の非同期処理をキックした場合、JP1のようなジョブスケジューラソフトで制御できるものではありません。

それらを埋めてくれるのが、パイプラインプログラミングだと考えます。近頃は、APIなど外部システムの情報をマッシュアップするケースが増えてきています。これらの集計をWEBから効率よく実行するためには、パイプラインプログラミングが必須になってくると考えています。

 

<業務システムで使う型クラス>

@zenzengood さんの発表。 業務システムの上流工程で型クラスを使用してプログラミングして検証しましょうといった内容です。振舞や構造の変更部分に型クラスを使ってみれば、シナリオベースで検証できるからよいといった内容でした。ただし、オブジェクト指向のモデリングと比較して型クラスの何がメリットとなるのか、私には理解できませんでした。ただ、ワークフローの部分を型クラスとして、それ以外の概念は今まで通りオブジェクト指向のモデリングで対応すればよいのではないかと思いました。

 

<ぶいてく流スケーラブルアプリの作り方 2012>

@stakezakiさんの発表 RDBとKVSの長所を活かして、RDBだけでは捌ききれないデータの参照、更新に対応するための一つの案を示していただきました。KVSにはBarkleyDBを採用していました。また、RestなAPIでこれらのデータを参照、更新しています。これからの時代のサーバ構成、ミドルウェアの選択に関して考えさせられる発表でした。

 

一日目の感想は以上です。

二日目の感想は、また今度...

 

 

 

 

2012年7月16日月曜日

転職しても仕事の本質は変わらない

転職して、2週間が経った。

先週末、部署で歓迎会をしていただき、これで新入社員気分も吹き飛んだと思う。

 

30代半ば。今までの経験を見込まれての入社だ。以前の転職では、若さとポテンシャルを期待されていたが、さすがにこの歳になるとそうはいかない。

前職との最大の違いは、やはり「スピード」だ。7年ぶりに感じるベンチャーのやり方についていくのは大変だが、何とか食らいついているのではと自負している。

 

今回は、転職して感じる下記二点について書きたいと思う。

 

1. 「SIerからSaaSの会社に転職して自分の仕事内容が変わったか。」

2. 「自分のやりたい仕事ができているか。」

 

1.「SIerからSaaSの会社に転職して自分の仕事内容が変わったか。」と言われれば、答えは「No」だ。

アジャイル開発、Excelで設計書を書かない、リリース期間が短い...細かい違いを挙げればいくらでもあります。

ただ、「お客さまに価値ある仕組みを提案、提供する」という観点では、これっぽっちも変わっていない。一方、「社内関係者、チームメンバーと協力してソフトウェアを開発する」ということも変わっていない。お客さまのやりたいことを限られた期間、予算内で遂行するために徹底的に考えて提案する。ゴールを決めたら関係者に納得して動いていただく、という泥臭いことの繰り返し。これらは一切変わっていない。

だからこそ、「SIerでは言われたものを作るだけだけど、WEB系とかネット系で企画から携われるから転職したい」という理由で転職することは危険だと考える。まず、「SIerは、言われたものを作るだけ」という間違った認識が蔓延している。(これは、転職サイトとか人材紹介会社のプロパガンダのような気がする)お客さまのシステムを作るのに「要求仕様書に従って作ればいいんです」なんて言っているようでは、SIer失格だと思う。要求仕様書に対して提案するのもSIerの大事な役割だ。

 

2.「自分のやりたい仕事ができているか。」と言われれば、答えは「Yes」。

私にとって、「自分のやりたいこと」とは「お客さまに全うなシステムを提供したい」ということだ。

逆に言えば、どのようなシステム開発でも自社の都合(例えば、「内部統制で数回の社内の契約レビューをする必要がある」「ソースコードだと分からないから、決まったフォーマットで設計書を書いてレビューしなければならない」「バグ密度が○○/kstepsで基準に達していないから、強化試験を実施しなければならない」)といったお客さまの要望を無視した開発は勘弁してほしい。

お客さまを無視した自社都合な組織はいずれ衰退する。

お客さまの要望(納期、予算、品質)に合った手法を考え、最善の手段を用いてシステムを開発する。「多少のリスクがあっても新しい技術が何らかのメリットがあるなら、積極的に挑戦する」という文化で仕事ができることは満足している。ただ、それに見合った結果を出す厳しさはあるけれど。

 

SIerからWEB系の転職を考えている人は、WEB系企業はバラ色だと思い込まない方がいい。WEB系企業も人材が増え、SIerのような組織化は避けられない。今年は、スピードとそれにマッチした組織を創れる人(これが真のマネージャだろう)が必要とされる時代だ。WEB系企業への挑戦は、SIerで自分のゴールを達成してからでも遅くはない。逆に、SIerで厳しいゴールを達成した人と一緒に働きたいなぁ、と思う今日この頃である。

 

2012年7月1日日曜日

退職、みなさまに感謝!

昨日、某システム受託開発会社を退職しました。

退職にあたり、みなさまから気持ちよく送り出していただきました。

送別会も2回していただきました。

 

やはり、前回大赤字だったプロジェクトを今回は黒字にできたという貴重な経験をしたことは自分にとって非常に貴重な経験でした。昨日、部署全員の前で退職の挨拶、送別会に参加する中、このプロジェクトは様々な方のご支援、ご協力があってこそ、目標を達成できたのだと実感しました。

また、プロジェクトの雰囲気も少しずつ「やればできるんじゃないか」というポジティブな状況になってきていると思います。一度黒字化しても、継続して利益を上げるという次に繋がる仕組みを構築できないと仕事をする上で意味がないと思っています。

お客さまも、見積もり、上流工程を順序立てたプロセスで進めることで、受入試験の手間が減ることを実感していただけたのではないかと思います。ただ、まだお客さまの要望に100%応えられる組織になっているか、といえば、契約、開発プロセスだけをとってみてもまだまだ改善の余地があります。

 

転職する理由は、新しいことにスピーディーにチャレンジしたいことと既存のSIerのビジネスモデルに限界を感じていることです。多くのSIerのビジネスモデル、一括請負のビジネスモデル、協力会社の社員を使って利益率を上げるビジネスモデルは、曲がり角に来ているのではないかと考えます。

では、多くのSIerは、なぜ変われないのか。人月商売という慣習を変えられないのではありません。SIerの経営者もそこまでバカではないと思います。SIerの経営者が従業員の年齢構成に頭を抱えているからです。古くから存在するSIを業とする企業は、40代の社員&管理職が多く、20代が少ない。つまり、人員管理、外注マネジメント、社内調整がメインとなってしまい、お客さまの業務課題を解決するという企業にとって本来生産的な業務を遂行することができません。簡単に言えば、現場から遠ざかっているため、リスク管理、進捗管理(ただ、進捗表を見て確認するといったレベルは除く)ができない人が多いのです。実際問題があっても、現場で通用しない解決策を提示されたり、そもそも起こりうる問題すら指摘できないことが多い。

管理職が多いことで、管理職1人あたりの部下の数が少なくなり、予算や利益目標を達成するためには、協力会社の人員を多くして稼ぐしか会社として成長できなくなります。実際、コアな部分を協力会社のあるメンバーに依存しているプロジェクトは少なくありません。保守契約でお客さまからお金をいただけなくなり、そのメンバーをリリースせざるを得ず、引き継いだ社員が大変な思いしています。システム開発において丸投げをせずに外注管理をするならば、非常に高いマネジメントスキル、技術スキルが要求されます。しかし、そのようなスキルを持った社員はほとんどいません。

 

SIerのやり方が悪いというより、従業員の高齢化、管理職の割合が多くなっていることが問題の根源です。40代以上の社員の意識、行動を変えることは非常に大変です。実際、日本で元気なIT企業の平均年齢は30代前半以下です。計画から実行へ移すスピードが違う。自分もこのスピード感のある企業で働いてみたいと思ったのが、転職する理由の1つです。

転職するにあたってもう一つ重視したのは、組織として成長できる仕組みを経営者が意識しているかどうか。自組織の価値を説明できるかどうか。目先の利益額を増やすために安易に外注していないかどうか。後輩、後継者を育成する仕組みを経営者が意識しているかどうか。

今までの経験を活かして、来月から組織が継続的に成長する仕組み、後輩、後継者を育成する仕組みを創り上げていきたいと考えています。

 

改めて、様々な貴重な経験をさせていただいた前職関係者のみなさま、お世話になりました。

これからもよろしくお願いいたします。

2012年6月24日日曜日

先週、ちょっと嬉しかったこと

先月、無事にプロジェクトの検収印をいただき、前回赤字だったプロジェクトを黒字にできたわけだが、利益という数字以上に定性的な効果があった。

 

お客さま先に常駐している自社の先輩社員が、お客さまのキーパーソンに自発的に働きかけ電話会議を調整していただいたのだ。

今までは、受け身でお客さまの言われたことだけをする人だった。開発側から何度もお願いをしていたが、危機感を持ったのか積極的に動くようになったと思う。打ち合わせの進め方には、まだまだ改善点が多いが大きな一歩だ。

やはり、組織の雰囲気はリーダの継続的な一貫した姿勢と絶えず相手に一貫した行動をとることが大事だと実感した。お客さまに対して妥協しない姿勢、それは自組織にとってより妥協できない姿勢を絶えず実行することがこのような結果をもたらした。

 

お客さまとの仕事の進め方も、この1年で確実に良い方向に向かっている。この状態で自分が離れても、この組織の雰囲気、姿勢を続けていただければ、継続して利益を出すプロジェクトになると信じている。

 

些細な出来事だが、この半年の成果を実感できる出来事であった。

2012年6月3日日曜日

プロジェクト完了!損失ゼロ達成!

先月、お客さまから検収印をいただいた。

これで、数ヶ月に渡るプロジェクトの採算という意味では成功した。

「採算という意味では」と書いたのは、実はお客さまの都合で仕様変更が発生し、今月中に仕上げる必要があるからだ。お客さまのビジネスの成功をゴールとする私にとっては、まだ気は抜けない。

 

このプロジェクトが始まる前に、会社の上層部からさまざまな厳しい言葉をいただいた。いや、厳しい言葉というより、嫌味だった。見積もり時に何度もシミュレーションしたが、採算をとるシミュレーションができなかった。一方、「何としてでも、ある時期までに受注しろ!」という司令を受けていたため、安値での受注になるリスクを孕んでいた。

 

実際、同じお客さまの1つ前、2つ前のプロジェクトでは、膨大な赤字を計上した。実際に製造原価(90人月)とほぼ同じ額の赤字を計上した。2つのプロジェクトの尻拭いをした自分の中に、様々な悔しい思い、上層部への怒りがあった。今でも、その気持ちが消え去ったかといえば、消えていない。ただ、ネガティブな気持ちをそのまま引きずっていても何も改善しない。「自分で改善できるところから改善しよう、できる限りのベストは尽くそう」そう思って今回のプロジェクトに臨んだ。

 

自分の中の目標は

「損失ゼロ!」

「利益ゼロ」ではなく、「損失ゼロ!」だ。(プロジェクトの目標は、利益がゼロに近い◯◯円だけど...)

 

なぜ、「利益ゼロ」ではなく、「損失ゼロ」なのか。

二つの意味がある。

 

一つは、「無駄なことを無くす」という意味合いを持たせたかった。その場合、「損失◯◯円→損失ゼロ円」というように「損失」にフォーカスをあてた方が自分の中でしっくりきたからだ。

もう一つは、今回のプロジェクトには、「お客さまに説明できる自社のエンジニアの付加価値はない」ことを肝に銘じておきたかったからだ。契約時にお客さまから「高い!」と言われ、お客さまに高い理由を納得していただけなかった。

 

実際は、無駄だと思うこと、優先度を下げてもよいものを着手しないようにした。

開発の最前線に立っていない人々(上司含む)の意見はスルーした。「何様だと思っているんだ」と思う人もいるかもしれないが、反省点をベースに、自分が信じているやり方、自分が考えぬいたやり方を最優先にして仕事を組み立てた。

お客さまからいただいた要求仕様書にも徹底的に噛み付いた。お客さまにとって無駄だと思えること、曖昧だと思えることには、その理由を主張し改善した。

改めて、システム開発が失敗する理由は、契約までの準備不足だ。

自分の結論は、準備不足は「当事者意識」からおこる。特に、管理職であればあるほどその傾向が強い。管理職は仕事の責任範囲が広いため、そのような傾向に陥りやすいのは理解できるが、丸投げする姿勢を見せた瞬間、部下からの信頼は一気に崩れる。

少なくても、開発メンバーには、そのような姿勢は出さないようにした。

自分に問題がある場合は、すぐに謝ってメンバーに動いていただく。誤って指示を出さないだろうか、失敗しないだろうかなんて考えない。言い訳なんてもってのほか。その時間が勿体ない。

 

「損失ゼロ」にするために、何が必要か。

私の結論は、「当事者意識」と「先手を打った行動(PDCA)」だ。

これを徹底するだけで、「損失ゼロ」の大部分は防げると思う。各自の役割に沿って徹底的に考え、行動する。上の立場であればあるほど、この行動ができないと組織として膨大な損失を被ることを身にしみている。

 

今回も、開発メンバーの方には大きな負担をかけた。ただ、前回、前々回と比較して、開発メンバーの方に休日出勤をほとんどしていただかずに済んだこと、私も1回も徹夜して仕事せずに済んだことは非常に良かったことだ。

 

 

さて、次の目標は...

といいますと、その前に今月で今の会社を退職します。

来月から別の会社で勤務します。

社内の関係者には、既に報告済みであり、現在後任者への引き継ぎを並行して進めています。

転職理由は、「自分の得意とするスキルを必要としてくれる組織で働きたいから」です。

今の会社のキャリアパスでは、現状そのようなキャリアパスを用意されておらず、それを変えるには膨大なエネルギーと時間を要すると思ったからです。

いわゆる伝統的なSI(システムインテグレーション)のビジネスモデルでない企業に転職します。

 

Facebook、twitterなどでお付き合いのあるみなさまと、お仕事で一緒に関わる機会が増えると思いますので、今後も何卒よろしくお願いいたします。

2012年5月3日木曜日

組織とソフトウェア開発

最近は、アジャイル開発がSIerの中でもブームになっているが、開発手法だけ真似ても効果が出ないことはソフトウェア開発に携わった人なら何となく感じていると思う。

日本的な組織のSIerが、短納期でソフトウェアを開発するには、ビジネスモデルの変革と、組織改革が必要になる。

個人的には世の中のスピードに対応するために、製造業で起こったようにベルトコンベア式からセル生産方式に変わっていくと思っているし、実際そのようになっている。

システム開発でいういわゆる「上流工程」「下流工程」を別の人が担当する場合、伝達コストと伝達ミスのリスクが発生する。以前のように、長時間かけて業務効率化のための大規模なシステムを開発する場合では、工程ごとの分業制がベストだったのかもしれない。上流工程で要件と、アーキテクチャを凍結した上で、ITゼネコンのトップ企業(以下、プライム企業と定義)が「下流工程を単純化しよう」と考えた仕組みだ。この多重請負の仕組は、プライム企業にとっては最も継続的に利益が入るすばらしい仕組みだった。

ただし、リーマンショックをきっかけに、ユーザ企業のシステム予算が削減されたことをきっかけに、この仕組が機能しなくなった。

あまりにも、多重請負の仕組がうまく回っていたものだから、プライム企業は人の管理と、案件獲得のための営業を専門とする人ばかりになってしまったのだ。しかも、ほぼ全ての人が管理職。組織の高齢化が実務作業をする人ではなく、人を管理する人ばかりになってしまった。

つまり、アジャイル開発をしようにも、実務経験から遠ざかっている人ばかりの組織、および管理職ばかりの組織では、システム開発の実務ができないのだ。結果、協力会社の人材を使わざるを得ない。ただし、案件が継続的にあるわけではない。協力会社の人材は、資金がなくなったらリリースしなければならない。これでは、自社にスキルが蓄積されない。

IT受託開発の売上が減っているため、SIerの組織も縮小せざるを得ない。日本的な組織のSIerが復活するには、管理職の多くの役職を廃止し、システム開発において管理と実務双方を実行するようにする必要がある。経営陣が思い切ってこれをすすめることができるか、それに日本のSIerの将来がかかっている。

「サービスを早く提供すること」「アジャイル開発をすること」は、管理だけする人を減らして、自分も手を動かしながらメンバーを教育していく人材が必要だ。ただ、管理職の多くは、自分で手を動かせない人がほとんどだ。ここに日本的SIerの最大の課題だと思う。このまま放置していると、新興企業に負けて会社が倒産することも現実的になってくる。

 

ネット通販のサイトについて

日経新聞で、リアル店舗の流通企業の王者、セブン&アイとヤマダ電機がネット販売に本腰を入れると伝えている。

ネット販売の売上を上げて、シェアを拡大したいと考えているみたいだ。

「システム開発も内製化する」と書かれている。SEを増やすのだろうか。

「システム開発の内製化≠SEを増やす」という訳ではないが、今のサイトを拝見するとスキルを持ったエンジニアをスカウトしないと難しいのではないかと思う。

 

アマゾン楽天、とセブン&アイヤマダ電機の一番の違い。

それは、パーソナライズ化だと思う。

上記サイトは、多種多様な品目を扱っている。アマゾン楽天は、レコメンドと商品検索がトップに出てくるが、セブン&アイヤマダ電機はキャンペーン内容がまず目に入る。

サイトの作りからして利用者の立場に立っていない。

仮に、サイトを作りなおしても他に何か武器がなければ、アマゾンと楽天には勝てないだろう。

対策の一つがソーシャルだと思う。

例えば、トップページに近くのテンポの店員さんのtwitterがお客さまと対話している姿を表示するといった人の繋がりを感じさせるための何かが必要だ。

 

商売って、結局は人と人の繋がりだ。twitterという周りの人が見ている中での対話は、実店舗で商品について問い合わせている姿に近くなるのではないか。この温もり感をネットと隙間時間を使って相手に伝える商売はまだまだ開拓の余地があると思う。

 

2012年4月15日日曜日

自分のやりたいことを確認する方法

悩み事ですが、結論が出ました。いただいたチャンスは、受け止めようと決めました。

私は、SNSには、普段自分が思ったこと、感じていることを徒然と書いています。

自分が過去、SNSに投稿した内容と矛盾していなければ、自分のやりたいことがここにあると考えてよいと判断しました。

自分の過去の気持ち、記憶なんてすぐに忘れます。特に、成功したけど実際は直前までヒヤヒヤしたことはすぐに忘れます。

私がSNSに記録するのは、他の人に読んでいただきたいものではなく、自分が過去にやってきたこと、とくに失敗したことを確認するためです。

些細なことですが、それを積み重ねることで、反省、改善の材料となるからです。私は、ノートに過去にやったこと記録しても、あまりそれを見直すことってしません。でも、SNSに記録しておけば、移動時間など隙間時間に記録したり確認することが簡単です。

しばらくは、SNSをこの方法で使っていこうと思います。

2012年4月14日土曜日

プロジェクトがもうすぐ終わる前の振り返り

今日は、今回経験したプロジェクトの成果を徒然と書いてみようと思う。

 

2011年11月からこのプロジェクトが始まった。

私にとっては、前回のプロジェクトと同じお客さまでこのお客様とは2回プロジェクトを経験している。このお客様のプロジェクトは、大概、予算・品質の面で問題を起こし、社内でも悪い意味で有名なプロジェクトとなっている。いわゆる「デスマーチ」に属するプロジェクトだ。

 

今回も要件定義工程から一括請負で契約した非常に厳しいプロジェクトとなっている。

このような厳しい契約で受注しなければならないのは、自社の強み、営業力がなく、社員を維持するために受託開発で食いつないでいるからだ。(多くの同業者もこのような状態だと思われる。)

 

SI業界の構造的な課題は置いといて、与えられた予算、納期でお客さまの要求に応えられるシステムを構築しなければならない。

プロジェクトの規模は、約50人月。自分以外は、協力会社から人を集めないといけない。

最近は、少し景気が上向いてきたからか、プロジェクトメンバーを首都圏で集めることができずに、地方にある会社に詳細設計工程以降一括発注することになった。(直前まで猛反対したが、コストダウンしたいという上層部の考えを変えることができず、泣く泣く受諾した。)

 

メンバーが入った後に最も気をつけないといけないところは、自分がボトルネックにならないこと。これだけだ。

しかし、詳細設計工程以降一括発注したことで、自分がボトルネックになってしまった。

お客さまと調整したことを、資料にまとめてメールで送り、電話する。実際の詳細設計は自分でやっていたようなものだ。

今回のプロジェクトでは、一括発注する部分と自社で開発する部分があった。

自社で開発する部分は、基本設計から機能単体の試験まですべて1人の担当者に任せた。

お客さまからの細かい要求の変更が頻発するため、1機能1担当者とした方が工数が最小となり、品質もよくなるからだ。

 

一方、詳細設計工程から外注したところは、お客さまとの調整結果を外注会社に伝える工数が非常にかかった。外注会社の担当がお客さまの業務を知らなかった(また知ろうとしなかった)ため、お客さまの要望を詳細設計レベルにまで落とし込んで外注会社の担当に伝える必要があったからだ。

実際、外注会社に発注した機能の品質は自社で開発した機能と比較して、非常に悪く、自社で故障を修正するという事態になっている。外注会社のエンジニアのプログラミングスキル自体には問題ない。問題なのは、お客さま、およびお客さまの業務を理解しようという姿勢が足りず、それが無駄なコード、意図しないコードを作ってしまっている。作業の手戻りなんて軽いものではない。技術的な負債だ。

 

スピードとシステムリリース後の持続性が求められる今のシステム開発に、工程分業制の開発スタイルはふさわしくない。プログラムは工業製品と違って大量生産するものではない。ベルトコンベア型の大量生産のように工程ごとに分業すると工程間のコミュニケーションコストがかかり、伝達ミスによって品質が低下する。工程分業制によってシステム開発のコストが約2倍に跳ね上がっていることが自分の作業実績を記録することで分かった。

 

これからは、お客さま単位で、要件から運用まで一貫してシステムサービスを提供することのできるエンジニアの組織体制を組める会社が成長するだろうと思う。