2024年初頭に思うこと

 10年ぶりに、ここに投稿します。
10年前は、現職に転職したばかりの状態でした。

10年前の私の投稿を見て、変わったところ2割、変わっていないところ8割という感想を持ちました。

変わったところは、主に2つ。

• 団塊世代の引退などで働き手が減った。さらに、優秀な人材が受託開発から自社サービスに流れている。
• 公共系、金融系のシステム開発でも、クラウドを検討することが当たり前となった。

変わっていないところは、たくさん...

• 公共系、金融系などは、10年前と同じプロジェクトマネジメントで進めているところが多い。
• まだまだ一括請負で億単位の案件を請け負うSIerおよびその下請けは存在する。
• 優秀な（若手）人材がSIerから流出しているため、大規模一括請負の受託開発の現場で厳しい。

SEという言葉も死語になりつつある。

ただ、相変わらず、技術も理解した上で、お客様やビジネスサイドと話ができる人材は少ない。さらに英語で話ができる、となると希少です。

そして、多くのソフトウェアエンジニアが、お客様やビジネスサイドと話をすることを嫌がる一方、プロジェクトマネージャ・ITコンサルタントと呼ばれる40代50代の人は技術を理解せずに、エンジニアに丸投げする。

仕事をする上で、分業する必要は避けられないが、自分の担当している前後の工程を勉強・理解できる人材が不足している。

特に、日本では労働者が高齢化していて、管理作業がメインとなっている人が増え、生産性が落ちると思われる。

一方、管理者の割合が大きい職場は、金銭的な労働条件が良くても、若者に敬遠されるであろう。

条件が悪い職場で働くソフトウェアエンジニアは、条件のよいところに転職してほしい。

そうしないと、悪い条件、環境で働くのが当然となり、所得も上がらない。

40代以上のエンジニアも、今、話題になっている技術を1つでも少しかじってみて、これから流行するのか、自分なりに考察することが大事ですね。

現状維持は、悪い条件の職場でしか働けなくなります。現状維持は、衰退するだけです。

2014年を振り返って

2014年を振り返ってみると、歴史は繰り返されるというか、予想どおりそうなったなぁと思った。

個人的なキーワードは、「システム連携」「好景気」である。

まず、システム連携について。

クラウドが普及したとはいえ、「システム連携」のノウハウは必要だし、そこにかかるコストは以前と変わらない。10年くらい前のEA・SOAブームのときも同様だ。基幹システムをはじめとした既存システムとの連携ノウハウは、関係部署との進め方含めて一朝一夕で身につくものではない。多くの日本の大企業にとって、ただSaaS含むパッケージソフトを提供したところで、彼らの課題は解決しない。結局、既存システムおよび新規パッケージ双方を熟知したSEが必要となる。こういう連携案件ができるSEは、2014年現在いくらでも仕事あります。単価は高くはないですが、仕事に困ることはありません。そういう意味では、10年前と仕事内容は、全く変わってないんですよね。（単価は下がってますが...）
GUIで連携を設定するEAIツールとかありますが、SaaSとか使っていると、パフォーマンスの制約があったりするので、結局はコーディングした方が、維持管理コストが少なくて済む場合が多い。そういう意味では、AWSはニーズを捉えていると思います。個人的には、システム連携する 担当者は、プログラムを組めるスキルのある人でないと無理だと考えてます。

一方、中小企業は予算がないので、ベンダーからすれば、パッケージを大量に売って利益を稼ぐしかない。まぁ、そもそもシステム連携の必要性がない場合が多いので、それはそれでよいかと思う。


次に好景気について。

リーマンショック前も、SE不足だった。多くの大手企業で大規模（大人数）な案件の開発が進み、デスマーチもたくさんあった。
2014年もその傾向が始まったと感じている。この一年で株価も上がってますし、みずほ銀行、マイナンバーなどの大規模案件の影響で受託開発するSEの人手不足が出ている。
2015年は、このような大規模案件で人がとられる影響もあり、クラウド連携するSE不足もより顕著になると思う。そうなると、程度の差はあれ、連携して出来上がったシステムの品質問題が出始めるのではないか。単にシステム連携が問題なのに、
クラウドはダメだといった論評が出てしまうのではないかと懸念している。
極論かもしれないが、そうならないことを願っています。

曖昧性との...

最近は、技術的なことにあまり時間をとっておらず、プロジェクトマネジメントに関することに時間を割くことが多い。
プロジェクトマネジメントといっても、最近ブームになっているスクラム・アジャイル・リーンいったものではなく、昔からある開発手法（ウォーターフォール）だ。

現在、ITエンジニアは人手不足で、10年前と比較するとシステム受託開発の単価も下がっている。パッケージ導入担当者（コンサルタントという肩書きの人もいる）含めて少人数で効率的にITシステムを構築する必要が出てくる。
パッケージ導入含む受託開発の場合、原価を押さえるための一番の要因は、プロジェクトマネジメントだ。お客様をスムーズにディレクションし、必要最小限のメンバーと開発を進める。少数精鋭でプロダクトを組み合わせたアーキテクチャを提案し、一人あたりの単価を上げるという方法でしか生き残る道はない。

曖昧性とのたたかい―体験的プロジェクトマネジメント論 

曖昧性との共存

この2つの書籍は読んでいて「そうそう。そうだよなぁ。」と納得することが多い。
また、実際に開発に携わっているとき、「ここ注意しないとなぁ」とチェックリストとしても使える。

この本は、あと20年経っても色褪せないだろうなぁ。

2013年を振り返って

今日で、2013年もおしまいです。
自分の関わっている業界で感じたことを中心にこの1年を振り返ります。
今年は、プロダクトの開発に関わるのかなぁ、と思っていましたが、諸事情あり結局SIの1年間となってしまいました。

この1年で、クラウドは普及というより、当然の選択肢となったと感じています。
また、お客様から単一のサービス（やパッケージ）を導入すれば何とかなるレベルのものではなく、様々なサービス（オンプレミスだろうがクラウドだろうが関係ない）を組み合わせるケースが増えてきました。

2014年、確実に言えることは「導入がより複雑になる」ということです。

プログラミングするための設計よりも、様々なサービス・プロダクトを連携した場合の図を描くことができる人がより必要になっているのではないでしょうか。
大手企業であれば、既存のシステムと連携することが必須です。ここでいう連携とは、システム的に連携する必要があるということではなく、システム的に連携する価値があるかどうかという観点からお客様にベストな方式を提案できることが大事です。

特に、連携するサービス間で何からのインシデントが起きたときの設計は、担当者のスキルがもっとも現れるところではないでしょうか。
「一見、サービスインしました」といって、インシデント・オペレーションについて、何も考慮せずにシステム連携した場合の現場の悲惨さは簡単に想像できるでしょう。

また、プロダクト・サービスの淘汰も来年から顕著になってくると思われます。
特に大企業向けのプロダクトは、勝ち組、負け組がはっきりしてくるかと。

以上、2013年年末時点での記録です。
みなさま、2014年もよろしくお願いします。

AWS S3に画像をサムネイル表示するプログラムをscalaで作ってみた

最近は、お客様と打ち合わせすることが多く、コーディングから遠ざかっている。

コーディングしないと、お客様への提案内容（特に技術的に可能かどうか）や見積もりのカンが鈍る。技術は日進月歩で、何もしないとお客様にまともな提案ができない。

今回のS3に画像をサムネイル表示する件も、あるお客様との打ち合わせがきっかけだ。
AWS S3に画像をアップロードしたときに、何でS3にこんな機能ないんだろう？って思った。

当初はscalaまで使ってコード書くつもりはなかったんです。
pythonのs3cmdと、アルバム作成するソフトを組み合わせれば、シェルを組めば実現できると思う。あとrubyを使ってもいいですね。
ただ、アルバム作成ソフトって、IE6に対応してないんです。JavaScriptがもうIE8以上しかダメ。お客様社内の端末はIE6なので、シンプルなHTMLでUIを作った方がいいと思った。（別にJavaScript凝ってもいいけど）

ってことで、早速深夜作業の待ち時間に作成してみた。
環境は以下の通り

• scala 2.10.2
• sbt 0.12.3

クラス構成とか考えてません。main関数にベタ書きです。

ソースの説明です。
まず、AWS SDK JavaのAWS S3クライアントを作成する。

//create AmazonS3Client instance
    val s3 = new AmazonS3Client(new ClasspathPropertiesFileCredentialsProvider);
    val region = Region.getRegion(Regions.AP_NORTHEAST_1);
    s3 setRegion region

次に、AWS S3のバケッド名を設定する。
（ここでは、バケット名をkzsampleとしている。）

//Get Objects in a bucket
    val bucketName = "kzsample";
    val objectListing = s3 listObjects(new ListObjectsRequest withBucketName bucketName)

S3のバケットからJPEG画像のパスをリストで取得する。
（scalaだとここが非常にシンプルなロジックでいいですよね。）

//Set Jpeg Files in jpegList
    val jpegList = new java.util.ArrayList[String]
    objectListing.getObjectSummaries().filter(p => p.getKey().endsWith(".jpg")).foreach(q => jpegList.add(q.getKey()))

VelocityテンプレートにS3から取得したパスを埋め込む。
テンプレートのパスは、templates/order.vmとしています。

//Velocity
    Velocity.init()
    val context = new VelocityContext()
    context put("jpegList", jpegList)
    val sw = new StringWriter()
    Velocity getTemplate("templates/order.vm", "UTF-8") merge(context, sw)

テンプレートのサンプルはこんな感じ。

VelocityでparseしたHTMLをS3にアップロードするオブジェクトに変換する。

val is = new StringInputStream(sw.toString())
    val metadata = new ObjectMetadata()
    metadata setContentEncoding "UTF-8"
    metadata setContentType "text/html"

最後に公開権限をつけて、S3にアップロードする。

val is = new StringInputStream(sw.toString())
//Upload html file to S3
    val putRequest = new PutObjectRequest(bucketName, "html/sample.html", is, metadata)
    putRequest setCannedAcl CannedAccessControlList.PublicRead
    s3 putObject putRequest

ということで、できたサンプルがこれです。

テンプレートのHTMLのデザインをもっと格好よくすれば、応用が効きますね。
HTML5とか....

参考までに、ソースはこちら

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でマルチトランザクションでバッチを起動するなら上記設定内容だけは覚えておきたい。

クラウド温泉3.0 に参加して(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問題を考えると、並列プログラミングをするためには、関数型を使って並列処理が可能な基盤部分のアーキテクチャを構築できる人が重要になってくると実感しました。

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

 

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

 

 

 

クラウド温泉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でこれらのデータを参照、更新しています。これからの時代のサーバ構成、ミドルウェアの選択に関して考えさせられる発表でした。

 

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

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

 

 

 

 

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

転職して、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で厳しいゴールを達成した人と一緒に働きたいなぁ、と思う今日この頃である。

 

退職、みなさまに感謝！

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

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

 

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

 

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

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

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

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

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

 

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

 

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

 

自分の中の目標は

「損失ゼロ！」

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

 

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

二つの意味がある。

 

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

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

 

 

さて、次の目標は...

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

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

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

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

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

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

 

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

組織とソフトウェア開発

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

 

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

 

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

 

第二回 #Playframework 勉強会 in Tokyo #play_ja に参加させていただきました

第二回 #Playframework 勉強会 in Tokyo #play_ja
に参加しました。

勉強会の要約は下記を参照いただければと思います。

• 第二回 Playframework 勉強会 in Tokyo やりました #play_ja – 複雑系スパゲティソース(はてな版) 
• Playframework勉強会#2まとめ（スライド）

Playframework勉強会に参加したきっかけ

自分自身、普段はJavaの受託開発をしています。JavaEEは使わず、Webの部分のフレームワークは、Struts＋Spring＋iBatisを使用しています。（他にバッチのフレームワークもあります...）

近頃は受託開発ビジネスの規模が縮小し、現場でも生産性向上をしないと採算が取れない状況になっています。

生産性向上といっても、必ずしもフレームワークを使用すれば生産性が向上するわけではありませんが、開発環境および基盤（共通部分のプログラム、実装方式）を構築する工数は馬鹿になりません。工数以上に、開発環境構築というのは、開発のボトルネックとなりやすい部分でここで時間がかかったりすると、損失コストが「エンジニアの単価」×「人数」となってしまいます。（ここでいう開発環境は、実装、単体試験、ビルド・デプロイまでを意味しています。）

開発環境を構築するときに一番難しいのは、フレームワークの組み合わせです。
限られた時間内にフレームワークを組み合わせて開発環境を構築する作業自体が難易度が高い。
さらに、メンバーにフレームワークを使って構築した基盤を習得してもらう期間が無視できません。
プロダクトコードだけでなく、テストコードもメンバーに習得してもらうとなると、慣れるころには、プロジェクトが終わっている...といっても過言ではありません。


今後、こんな面倒なことを解消する方法って何かないのかなぁ、と思っていたときに出会ったのがplayframework scalaでした。


playframeworkの勉強会をやっていないか検索したら、上記勉強会があるということを知りました。申込時は、キャンセル待ちで「playframeworkってこんなに人気があるのか。」と改めて、Java開発者がWEB開発に現状不満をもっていて、playframeworkに期待していることを実感しました。



playframeworkの魅力


playframeworkの魅力は以下３点だと思います。

• 環境設定ファイルがシンプルであること（xml地獄にならないこと）
• 様々なフレームワークを組み合わせる必要がないこと
• 実装、単体試験、ビルド・デプロイがセットになっていること

個人的には、playframework 2.0のscalaに期待です。

scalaでDBを参照、更新するサンプルコードを動かしてみたのですが、ゼロからはじめて半日で動かし、テストコードも書いて検証することができたのは、playframeworkが初めてでした。

WEBとバッチ双方でModelを共有できればなぁと思っています。

あと、メーリングリスト（英語）の投稿数が半端じゃないです。１日に数十通メールが飛んでいます。

特にscalaの内容が多いと思います。playframework scalaの今後に期待です。

playframeworkのSpringFrameworkモジュールを使用した感想

勉強会で、さまざまなmoduleを組み込むことができますと教えていただいたので、SpringFrameworkモジュールを組み込んで、遊んでみました。

DI自体は簡単にできましたが、playframeworkのspringモジュールは、単純なJavaのロジックのDIしかできません。DBのデータソースやトランザクション管理のモジュールは入っていません。トDBのデータソースやランザクション管理の必要性がないからでしょう。（私は、DBのデータソースやトランザクション管理のモジュールをlib以下に組み込んで使用してみましたが、大したメリットはないです。）

Springを使用するのは、ビジネスロジックをDIしたい場合だけでしょう。

最後に

勉強会を開いていただいた @ikeike443 さん、スポンサーとなっていただいたイージフさま、シャノンさま、ありがとうございます。セミナー、および懇親会で様々な方と情報交換をさせていただき、自分にとって大きな刺激になりました。

システム開発の基礎的なところでつまずいている

昨夜から今日にかけて、ある一冊の本を読んだ。

「ITアーキテクトのためのシステム設計実践ガイドVOL.3」

 

お恥ずかしい。この本に書いてある大事なことを何一つできていなかった。

正直、上記のことを守れたとしてプロジェクトの予算、納期を考慮するとQCD全て満たせたかは分からない。

今回特に失敗したところを以下に挙げておく。

 

1.各工程で作るべき成果物、作業、そして完了基準が明確でない

1.1 要件定義（私がプロジェクトに参画する前）

お客さまからいただいたRFPに基づき先行作業をしていたが、なぜか基本設計書の執筆になっていた。なぜ作成すべきもの、タスク（WBS）を整理していないのか。情報収集していたが、情報収集した結果をドキュメントで整理していなかった。当然、収集した情報を整理・分析できていない。 今思えば、この時点でプロジェクトが破綻するのは当然だ。

1.2 基本設計以降

その成果物を何の目的で作成するのか、共有できていない。 つまり、目的がないということは当然完了基準が明確にならない。 何も考えずウォーターフォールで作成する成果物を作成している。

特にユーザIFまわりの確認、合意は重要だ

 

2.ユーザの要件をプロトタイプで確認していない。その結果、納品後にユーザからの不満が次々と出る。

今回、新しいフレームワークを使用することとなった。 納品前までは、設計書、モックアップ(HTML)だけでユーザと確認していた。

下記、ユーザが重視するところをプロトタイプを作成して確認してもらっていなかった。

• バッチ系のプログラムのパラメータの入力チェックエラー時のコンソール出力
• 画面のエラーメッセージ
• ログ出力

プロトタイプを見せることによってユーザが気づいていなかった要求を洗い出すことができる。要求を早めに洗い出せば対処もしやすくなる。

何でもかんでもプロトタイプを作ればよいというわけではない。プロトタイプの目的とスコープを明確にしないとユーザからの要望が噴出し、プロジェクトが前に進まない。

3.見積もり前提が不明確

見積もりの前提がWBSを起こすには不明確だった。PMの「一括請負」という契約 = 「何でもやる」という雰囲気がプロジェクト内に蔓延していた。PM自身が、これに対応したら対応できる人とどれくらいの工数がかかるのか把握できていないためだ。全体のWBSを洗いだしていないため、工数がどれくらいかかるのか把握できていない問題がこういった結果を生み出す。一括請負だからこそ、契約でWBSに落とせる範囲まで決めないと全て請け負った側の責任となってしまう。見積時のメンバーではWBSを洗い出す力もないから結果お客さまに説明できず一方的に値切られてしまう。

4.WikiなどWEB上での情報共有の仕組みを作っていなかった。

メンバーに周知することをWikiなどで情報共有する仕組みを考えておらず、口頭での周知になってしまった。口頭で周知することも非常に大事だが、そのための準備を怠ったため、開発現場が混乱した。一番の問題は、そのような情報共有の仕組みをWBSに計画していなかったこと、責任分担を曖昧にしていたことだ。リソースにも含まれておらず自分自身が非常にしんどい思いをした。今後はそのようなことがないようにWBSを作成したい。

5.性能の問題のため高度なスキルを持った人が不足

性能問題を解決できるスキルを持った人をアサインしていなかった。問題となる機能を洗い出し、早い段階で製造して問題がある場合は、対策を打つようにしないとまずい。今回、性能に問題があった場合も自分で対処することになった。結果、他の重要なタスクを後回しにせざるを得なくなってしまった。

6.実装・テスト工程は、メンバーを増員した場合の対処を準備しておく

プロジェクトの後半になって、問題が表面化してリカバリするためにメンバーを増員することがある。こんな場合も想定して、機能分割、構成管理の運用方法を準備しておく必要がある。特に、共通ファイルの取り扱いを明確にしていないと開発現場が混乱する。

7.新規フレームワークを採用する場合は、効果を早い段階で検証する

プロトタイプを作成して、開発前にサンプルコードを作成しておく。平均的なプログラマは、機能を0から実装することはできない。同じようなプログラムを参考にして実装する。彼らのフレームワークに対する学習効果を想定してスケジュールを組まないと、実装時の生産性が上がらない。そのためには、自組織が調達できるエンジニアのレベルを把握することも重要である。

8.大規模開発では、ある程度の重複を受け入れる

何でもかんでも共通化をしてしまうと、定数、共通ロジックの追加・削除の申請に手間がかかってしまい生産性を下げる原因になる。

どこまで共通化してどこから分割するのか現場経験豊富なリーダが決めて周知する必要がある。

9.各テスト（特に単体テスト）の定義を明確にする

各試験で、何をどこまで試験するか、チームの主要メンバーで決める必要がある。

特に単体テストの定義は重要。オブジェクト思考開発を経験した人とそうでない人では、単体テストの定義が違うことが多い。

ましてや、JUnitを使って下さい、といった場合、スケジュール(WBS)を立てる場合、「メソッド単位」なのか「クラス単位」なのか、あるいは「機能単位」なのか決めてからでないと意味のないスケジュールとなってしまう。当然、「メソッド単位」での単体試験を実施する場合のほうが工数がかかる。更に問題なのは、仮に単体テストを「クラス単位」に試験と定義した場合、「機能単位」での試験項目は、「単体試験」となるのか「結合試験」となるのか明確にしていない場合が多いのである。ありふれた用語を理解せずに使用すると、後工程になってから問題が表面化し、取り返しのつかないことになる。

10.テストの自動化は、テスト結果の検証も自動化しないと効果がない

テストをJUnitなどのツールで自動化するには、テスト結果の検証も自動化する必要がある。

テスト結果の検証を自動化しないとテストの工数はそれほど変わらない、むしろツールの使い方で悩んだり手間がかかってしまうので工数がかかる。検証項目が多い場合は、ツールに設定すること自体時間がかかってしまうので、Excelを使った方が早い場合もある。

そこを考慮した上でテストツールの採用を決めることが重要である。

 

P.S.改めて画面のレイアウトの検証でツールを使うのは難しいなぁと感じる。

 

他にも失敗したところが多々あるが、まとめると以下３点になる。

• 目的を考えて仕事をしていない（既存のテンプレートに沿って作業している）
• 見積もり時に前提となる必要なタスク(WBS)を洗い出せていない
• 各メンバーの役割が不明確

 

本当に情けない限りだが、次回からはこの失敗談を伝えることで、対処方法などの説得力が増すはずだ。

これから改善する点を更に整理する。

 

要求仕様書を作るのはいいけれど...

何か、お客さまと自社双方で無駄なことをやっているのではないかと思う。
システムを受託開発する場合、RFPなり要求仕様書を作成する。
通常は、要求仕様書をベースに開発する。

出来上がったシステムをお客さまに検収していただく基準は、要求仕様書となる。

一方、最近のシステムは、以前のシステム+αといった案件が多い。当然だ。それなりの規模の企業は、既にシステムを持っているか、または現場でツールを使用している。
要求仕様書は、そのシステムの造りに応じて書かれていることが多いのだ。

つまり、お客さまはわざわざ、システムの中身をほじくりかえして要求仕様書を作成している。プログラムのロジックを自然言語にすることでどうしても、曖昧さが出てしまう。
業務改善が目的であれば、業務の分析をした上で、要求仕様書を書くことは非常に意味のあることだ。

しかし、現行と同じ部分は、その部分のソースを解析した方が、下手に細かい条件まで要求仕様書に記述して貰うよりは、曖昧さがなくなって良いと思う。

お客さまも検収時に、いろいろ調査せずに済むし、自然言語というのはやはり曖昧さが残る。
現行と同じであるなら、曖昧さを排除した方が、お互いコミュニケーションのロスが無くなる。
これによって、うん百万もお互い損失を出しているのがアホらしく感じる。

開発効率化についていろいろ考えてみたが...

開発効率化についていろいろ考えてみたが、工数を50%短縮するには、不要なタスクを削るしかない。

 

不要なタスクって何か。

まずは、必要なものを考える。

 

・ ソースコード：これがないとシステムではない。

・ 設計書：これはいくつか分類できる。

1. お客さまと意識合わせをするために必要な設計書

・ 業務フロー

・ データ項目一覧および関係（DBのER図やテーブル定義書）

・ 外部IF

・ 画面

など

 

2. 開発ベンダーが保守する上で必要な設計書

・ 設計ポリシー（アーキテクチャ）

・ 各機能での処理

など

 

正直、開発ベンダーが保守する上で必要な設計書は、最小限にとどめたい。

アーキテクチャを決めた後であれば、システムの規模が大きくない（～50ksteps）レベルの開発ならお客さまと直接ヒアリングした結果をドキュメントではなく直接コードに落としてお客さまに見せた方が明らかに早いし、お客さま自身も早く検証できる。

このスピードで進めていかないと、今後受託開発で生き残っていけないだろう。

設計者と実装者が違う、或いは実装工程を外注するといったことをしていると現場が疲弊する。

 

10人で1,000万かかるシステムを、5人で800万で開発する。

そのためには、社内のコミュニケーションコストをなるべく低くするのがよい。

いたづらに人を増やすとコストがかかる。お客さまから直接話を聞いて、コードを書き、作成したものをお客さまに説明できる人。

このような人、チームを創り上げていきたい。

自組織の方針と違うかもしれないけど、そうしないと会社が潰れる。