組織とソフトウェア開発

最近は、アジャイル開発が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なり要求仕様書を作成する。
通常は、要求仕様書をベースに開発する。

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

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

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

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

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