第二回 #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万で開発する。

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

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

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

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

 

何でもできるように...ってキツイ

今日は、お客さまのシステムのリリース日。
私は別の仕事をしながら、リリース時に問題があれば、対応することになっていた。

深夜にリリースが始まり、まぁ何事も無いだろうと思っていた矢先、昼休みにのんびりとご飯を食べていたときに、おとが起こった。

ソフトウェアの見積りについて

ソフトウェアの見積りは難しい。
なぜかというと、見積りの絶対的な基準が無いから。

ただし、それは開発ベンダーのことではない。見積りを査定するお客さまの方だ。
ベンダーが新しい見積り方法で、お客さまに提案した場合、算定方法が複雑だと、お客さまに納得していただけない。唯一納得する要素は、予算より見積り額が下回った場合だけだと思う。

もうひとつ厄介なことは、お客さまの決裁手順だ。決裁手順に即していない場合、新しい見積り方法では、何らかのメリットがないと受け入れられないだろう。
規模見積りが主流なのは、開発手法が変わっても、結局は人月商売だから変わらないよねってことなんだと思う。

従業員の高齢化＆管理職ばかり

最近、改めて感じること。

アーキテクチャを意識せずに見積もりをするのは勘弁して欲しい。見積もりの基準が規模なのは分かるが、完成までのイメージが全くできずに見積もったら、見積もりの精度が悪くなるのは当然だ。

人の管理ばかりで、プロジェクトマネジメントになっていない。開発のイメージが湧かない人間が見積もりをしていることに問題がある。人の管理しかできない比較的年齢の高い人間が多くなっていることがSIerの最大の問題だ。

簡単に言えば、管理ばかりで実際にモノが造れる人が少ないのである。管理職が多すぎる。企業の従業員の高齢化が非常に問題になっている。

歳をとってもスペシャリストとして管理職と同等かそれ以上に待遇を改善しないと、高齢化企業は衰退していくのではないかと思う。

 

既存の考えで凝り固まった組織を変えるには時間がかかる。新しいやり方なんて、大抵は失敗する。

というより、何もアイディアを出さない。新しいことにチャレンジしない。本当に情けない。

 

高齢化企業というのは、単に従業員構成が高齢化している以上に、高齢化した人達の考え、文化が組織内で支配的になっていることが問題だ。

それでも、重たい組織を変えるようがんばった方がいいのか、最近疑問に思う。

 

 

 

 

失敗プロジェクトが教えてくれるクラウド時代のヒント

この半年ちょっと、私は失敗プロジェクトに2つ関わった。いや、まだ関わっている。
2つのプロジェクトの見積り規模は、55ksteps。実際に開発した規模は、90ksteps。
当然、プロジェクトは赤字。見積り、契約の甘さがここまでの悲劇を招いた。

こんなヘボプロジェクトでも、成果はある。いや、こんなプロジェクトだからこそ成果がある。
一つは、途中から必要最低限のことしかやらなかったことだ。いや、できなかったことだ。
これによって、本当に必要なことが分かった。
開発中、誰も分からないような細々とした設計書を書くのは、アホらしいとおもった。
設計書を書かないと、コーディングする人が分からないという。
逆に言えば、コーディングする人は、プログラムのロジックの責任を設計者になすりつけている。
何も考えないでできる単純作業しかできないコーダーは要らない。
納期の長い10人を超えるプロジェクトなら、設計書をきっちり書いてレビューすることが必要だが、納期が半年未満のプロジェクトならお客さまの声を直接聞いて、ソースに反映したほうが、開発側もお客さまも楽できる。

もちろんそのためには、ビジネスのゴールとスコープを双方で合意していることが重要だ。
また、アーキテクチャ設計書を策定していることも重要だである。

もう一つは、大きな失敗をしたお陰で、従来の開発の考え方を上層部が変えてもよいのではないかと言ってくれたことだ。
組織が大きな失敗をすると、改善案が通りやすい。
個人的には、チャンスだと思う。

ということで、今日は改善策をまとめるための仕事をしにいきます。
少しでも組織が変わるきっかけになればいいなぁ。

やはりスピードが最も大事

お客さまから、声を聞くことができた。
品質も大事だが、それ以上にスピードが大事。
品質を上げる策より、どうやって早く開発するかが益々重要になってるいる。

クラウド時代は、スピードの時代だ。ネット企業のやり方は、５年前までは受け入れられることが少なかったが、今は受け入れられていると思う。
むしろ、中途半端に大きくて、社内の規定がうるさいところが、利益を出せなくなっている。
管理する人がやたらと多いのも、スピードが出ない要因のひとつだ。

Agile が読めない管理職がいた。情けなかった。深く考えもせずに社内の規定でダメだという。予算と納期が半分であるならば、今までのプロセスの無駄を省こうといった考え方ではダメだ。0ベースで、このタスクは必要か考える必要がある。
私は、マネジメントを否定するつもりはないが、マネジメントをする人は、2割以上居たら無駄なコストだと思う。
ただ、管理しかできない年寄りが多いことは、若手がマネジメントする機会も奪っていると思う。実際、一番必要とされているのは、プレイヤーとして充分な経験を持つマネージャだ。管理しか指示が出せないようでは、使い物にならないと思う。もちろん、少数の経営者は別ですが...

SIerのビジネスモデルが、スピードと高齢化で崩壊していくのが、手に取るように分かる。

できることとできないこと

昨日、blogで愚痴ってしまった。

このシステムをメンテできるのは、自分しかいないと書いたが、実際は社内でメンテできる人間は何人かいるだろう。謙虚さが足りなかった。

ただ昨日の、自分しかいないと思ったことは事実で、今後はこのような気持ちにならないためにはどうすればよいか、改善策を立てる必要がある。

一方、自分のやっていることが、お客さまに価値をもたらしていないことも事実である。
新しいことにチャレンジしたが、思った以上に工数がかかったことも事実である。

お客さまの要求を考えて、新しいことにチャレンジする必要があるかどうか判断する必要がある。リスクが生じるなら、その分を金額として上乗せしないとビジネスとして成り立たない。

最近は、自分で案件を取ってきたいと思っている。社内、社外に限らず。
そのためには、自分の成果をPRする。
それが、お客さまにとって価値のあるものであれば、そのスキルを使ってお客さまに貢献したい。

納品までこじつけたが...

３月から、ヘルプで入ったプロジェクト。
明後日納品。
複雑な気持ちで一杯だ。
リソースが明らかに足りない中、規模が見積りの2倍となってしまった中、上司の怒号が飛ぶ中、それらしいものは作り上げた。

先月末に退却プロさえた多くのメンバーの皆さまに感謝します。
設計書など情報が不足している中、厳しいスケジュールの中、モノとして仕上げていただいたことに感謝します。

ただ、上の対応には、疑問を持たざるを得ない。
コストの制限があるのは充分承知いているが、仕様策定の重要な箇所を協力会社のスキル、経験不足の人に任せるのは問題だ。
また、WBSの漏れも半端ではない。本当にプロジェクトを経験したのか、と思うくらい抜けがあった。というより、見て見ぬふりをしたのだろう。
問題が顕在化してから、慌てて上司に環境回りを振られ、情けない気持ちになった。
しかも引き継ぎ体制もずさんだ。
結局、すべての箇所を引き継ぐことになる。
問題を収束するには、お客さまと一歩一歩片付けていくしかないなぁと思う。

幸い他に対処できそうな人が居ないので、自分のペースで淡々と進めよう。
自分がダメなら代えてもらうにも、人が居ないのだから...

設計書みても分からない...

最近、非常に効率が悪いと思うこと。

お客さまが、作成した画面をみて「これでは分かりにくい」と言われること。

何故か...

 

設計書に書いてあるエラーメッセージが分かりにくいのだ。

確かに設計書の書き方に改善の余地はあるとおもう。

しかし、Sierの悪しき習慣がお客さま、開発者双方を悩ませているのではないかと改めて感じる。

 

最近のプロジェクトは、小規模化、短納期＆安価なものを求められる。

システムというものがコモディティ化しているためでもある。

最近は、お客さまのほうで画面を作成してから開発ベンダにその画面をもとにシステムを作成してくださいというケースも増えている。

しかし、保守的なお客さまは、未だに「基本設計」→「詳細設計」→…という工程で進めていく。

これを変えることはできないのか。

 

お客さまの受け入れ試験になって下記のようなやりとりはよくある話だ。

 

お客さま「ここ、こんなメッセージだと分からない。」

私「詳細設計レビュー時に合意したんですが...修正いたします。」

 

文書で書いても分からない。

チェックするメッセージの数が多すぎて、お客さまがいちいちメッセージの妥当性を理解する時間がかかって仕方がない。

実際、お客さまはチェックしない。そんな暇はないからだ。

 

だからこそ、基本設計書を書く前に画面の遷移および画面メッセージがわかるプロトタイプを作成してお客さまに見せて期限付きでフィードバックをいただくようにしたい。

これで、当事者同士の稼働を減らすことができる。

 

あとは、プログラムを知らない社内抵抗勢力にどう説明するかだ。

幸い前回のプロジェクトでシステムアーキテクチャ基盤を私が作成したため、プロトタイプを作成する環境は整っている。

このやり方をすると、障壁になる可能性のあることが３つある。

 

1.プログラムを書けない人をアサインされること

2.社内のお偉方の承認を得られないこと

3.お客さまのお偉方の承認を得られないこと（思ったより可能性が少ないのではないかと思う）

 

特に1.2.だなぁ。このため、今までこれだけコストがかかっている旨をまとめて納得していただけるように準備ですね。

最近、マネジメントも大事だが、管理項目ばかり増やしてどうするの？と思うことが多々あります。

やはり計画的に無理なのにすすめること自体が問題なんですよね。従業員を雇わないといけないというジレンマもあるので、正論ばかり唱えるわけにはいきませんが...

 

自分の価値

今日、久しぶりにお会いした方との会話。
お客さまに自分のやっていることの価値を認めていただこう、と思っていたが、常識的に考えて無理だということが分かった。
お客さまが儲からない限り、自分の価値を上げることはできない。
お客さまが儲かるって、今の仕事だとどんな状態なのか...
限られた予算のなかで、お互いが利益を出すにはどうすればよいのか。
売上、利益に直結する部門なら分かるのだが...

クラウド座談会に参加して

昨日は、八子知礼さんのクラウド座談会に参加した。

テーマは、震災とクラウド。
震災時に、被災者のためにクラウドサービスを立ち上げた企業のプレゼン。
本業がある中、自ら進んで、サービスを立ち上げたことがすばらしかった。

ただ、被災地の方にとって使えるものかと言われれば、問題山積だ。

今回の大地震が起きる前に、大地震が起きた時にあるといいクラウドサービスについて考えていた人は、どれくらいいるだろうか。

今回の大地震を教訓に、危機管理のマネジメントを含めて、あったらいいクラウドサービスを準備しておくといいのでは？と思った。

例えば、救援物資のSCM。
できるだけシンプルな形でデータを予め設計しておく。
大事なのは、「どこに何がどれくらい不足しているのか、どこから、何をどれくらい提供するのか。今、救援物資がどんな状態か。」
といったところか。
状態は、できるだけシンプルに分類する。状態遷移もできるだけシンプルに。

もう一つの課題は、紙からネットへの転記の問題。これは、クラウド以前からの問題だ。もし、紙をカメラで撮影し、クラウドソーシングで、データ入力する仕組みを作れればうまくいくのでは？と思った。問題は、現地からカメラで画像をネットで送れるのか…データ入力したら、現地が要求しているスピードに間に合うのかが分からない。

世界では一年に一回くらい大災害が起こっている。今回の大地震を教訓にこれをパッケージ化するのは、ありかもしれない。

被災地の復興に関しては、被災地の強みをまず考える。それを軸に復興計画を立てるのが良いのでは？と思った。
被災地の強みとして、真っ先に思いつくのは、農業、水産業。
これらを大規模化して集約する。
農業、漁業人口自体は少ないが、加工、販売まで含めると、それなりの数の雇用を生み出せるはず。
特に、漁業は衛星管理、保存技術などを上手く利用して海外に輸出する。最近の日本の冷凍技術は、人間の臓器を冷凍して移植できるレベルのものが量産可能だ。
世界中で健康志向が強まっている中、保存技術にブランドをかけて日本から販売する。
日本の大手企業が、企業イメージアップも考慮に入れた上で、その食品をネットなどのさまざまなメディアでプロモーションする。

正直、テーマが広大すぎて抽象的な話となってしまった感じは否めないが、自分ならこうするという真剣に考える訓練になったのでは？と思った。

最後に、参加された方、素晴らしい会をありがとうございました。

生産性の前提

今日、改めて、なぜ先日リリースしたシステムの生産性が悪かったのか、打ち合わせがあった。

お偉方はソースコードのSTEP数でしか判断できないので止むを得ないが、STEP数に含めるものの前提が違うのに、ある指標を使って生産性を測るのは勘弁して欲しい。
今回は、一部ソースコードを自動生成した。

今回のプロジェクトに限って、その分を規模として認めてもらえない。
自動生成すればする程、生産性が下がることになる。そんな馬鹿な話があるかと思ってしまう。

過去の指標を参考にするのは構わないが、前提が違うものを参考にされてはたまったもんじゃない。

クラウド時代は、システムで実現できることを基準とすべきで、ソースコードのSTEP数で、判断すべきでない。そもそも、生産性を計測すること自体、意味の無いことになっているのではないか。

プロダクトアウトの考え方で、システムを作るのはもう終わりにしたい。

チームでの振り返り結果

今月初めに納品したプロジェクトチームの振り返り。自分の考えを申し上げたが、情けない回答が返ってきた。

何が情けなかったか。

 

一点目は、「お客さまの言われたとおりのシステムを作っていればよい」ということを言われたことだ。確かに、お客さまの要望は大事だ。しかし、お客さまにも予算があり、何から何までお客さまのご要望に応えていたらビジネスとして成り立たない。

今回、自分がどうしても納得のいかない余分な機能があった。開発規模は少ないが、難易度は高い。試験パターンが複雑で工数が膨らむので、自組織としてはコストがかかる。お客さまの業務に必ずしも必要だとは思えない。しかも、この機能を開発することで品質が悪くなると確信できる。保守時にシステムを改変したい場合、余分なコストがかかる。

本当に、これがお客さまのためになるのか...

 

また、「見積もりに制約条件をつけたらどうか」という問いに対して、上司は「競合他社に取られる」と言う。確かに、競合他社を意識する必要はある。それ以上に、お客さまのシステムを知っている自社のアドバンテージを意識したい。私がお客さまの立場だったら、「何でもできます」という姿勢は、かえって何も考えていないのではないかと疑う。具体的な言葉で説明できないエンジニアでないと信用できない。

 

品質を上げるために「このドキュメントも必要だよね。」とか「このタスクも必要だよね。」とか、管理するために「この項目も必要だよね。」など、様々な意見が飛び交った。そりゃ、お金と時間が沢山あれば、先ほど書いたことも全部できるさ。でも、限られた時間で本当に、こんなことまでできるの？と言いたくなる。所詮、他人ごとなのだと思った。

 

もちろん、周りの意見を聞いて改善せきる点も多々あった。

ただ、コスト削減が中心で、新たに価値を提供するという観点では、何の改善もみられなかった。お客さまの業務改善まで踏み込まなくてよい、あるいは、そこまで踏み込む必要はないという上司の言葉に対し、非常に悔しく思った。これでは、永遠にお客さまの奴隷だ。だから悔しかった。こんな会社、組織のスタンスでお客さまと付き合いたくない。

もちろん、お客さまの業務改善まで踏み込むには、お客さまから信頼を得ていることが前提だ。今回は、私にとって初めてのお客さまであったため、まだ、業務改革案を出しても受け容れられないだろう。だが、お客さまに断られても提案はする。なぜ、この方法をとらないのですか？と。納得できる理由が無ければ、他に理由があるはずだ。

 

今回は、初めてお客さまのための自分の作品とよべるアーキテクチャを作成した。今どき、0ベースでスクラッチ開発するケースは少ない。フレームワークの選定から共通部分のアーキテクチャ、メンバーへの教育...さまざまなことを経験させていただいた。お客さまからの厳しい要求の中、納品できたことは、自分にとって次に繋がると確信が持てる。

 

次こそは、提案のチャンスをいただきたい。社内だろうが、社外だろうがどちらでもいい。自分を必要としてくれる人がいるなら、オファーをいただけるなら、ビジネスのゴールをヒアリングして、企画、アーキテクチャ策定段階から参画したい。

 

逆に、災害情報だけになってしまうtwitter

今回、自分のtwitterのタイムラインが災害の情報でほとんど埋まってしまい、他に必要な情報が得られないというちょっとツライ状況になっている人も多いのではないか。

今回、首都圏に住んでいる人で普段と同じように生活できている人も多い。もちろんそれは幸せなことであり感謝すべきことであるが、人それぞれ知りたいことがあるはずだ。

あらかじめ想像できたことだが、実際に体験してみると、自分が伝えたいことが地震関係のtweetでかき消されていうく感じがする。

だから、地震の話題が収まるまでtwitterを使用を控えます。使用したとしても、mentionくらいかなぁ。

 

今日も、仕事している私...いや、こんな時こそ、仕事が捗るからいい。そう思うようにしよう。

災害時のSocial Mediaの威力

昨日から、日本のインターネットのインフラは、改めて凄いと思った。 電話は通じなくても、ネットは通じる。 みな、携帯電話から情報を取得していた。 特に驚いたのが、twitterの情報伝播の速さだ。 災害時は、twitterをやっている人が、口頭で情報を伝える。twitterをやっていない人に驚く程伝わる。

日本人が冷静に行動できた理由の一つに、Social Mediaでうまく情報の取捨選択ができたことが挙げられるのではないか。

やりたいこと

プロジェクトが終わって、改めて自分がやりたいことを再確認した。

自分がやりたいことは、世の中に受け入れられるサービスを創りたい。
お客さまの要望を分析して自分で仕組みを考えて、新しいサービスを創りたい。
お客さまに喜んでいただくというより、無意識に当たり前のように使っていただけるものにしたい。

もう少し具体的に落とし込むと、お客さまの求めているモノを把握し、ソフトなりシステムに落とし込みたい。

今回のプロジェクトに参画して改めてそう思った。
また、現場のメンバーが新しい知恵を出し合って最高のモノを作りたいとも思った。

ただ、仕事をする以上、納期とコストという壁は、避けられない。
ただ、人月的な生活が送れなくなる状態だけは避けなければならない。

生産性とか人月商売、価格で勝負をする前に、価値で勝負したい。

恐らく、今週はプロジェクトの振り返りがあるだろう。
今の自分の軸と照らし合わせて、将来に向けて行動する。
振り返りが自分のターニングポイントだ。

プロジェクトをひと通り終えて

昨日、お客さまに納品した。ある意味、一区切りついた。
これから、お客さまが受け入れ試験を行うので正直油断はできないが、振り返りする上ではいいタイミングではないかと思った。

以下、気持ちを徒然と書いています。テクニカルな情報などは記載していませんので悪しからず。




今回のプロジェクトで自分の心に残った悔しい言葉がある。「生産性が悪い」という言葉だ。
プロダクトコードの規模の割には人手が掛かりすぎているという。
確かに数値だけ見れば、指摘の通り。
今回は、フレームワークや共通化を図って規模を少なくしてくださいというお客さまの要望があった。
共通化や抽象化をすることで、プログラムの難易度が上がる。
しかも、フレームワークを使用する、ソースコードを自動化するなどして規模を抑えた。
しかし、上司は自動化した部分も含めて規模として認めてくれなかった。
規模を減らすために努力した結果が「生産性が悪い」という言葉につながった。
非常に残念で悔しい。

規模を減らした結果、試験の工数が減るかどうかといったら何も工夫しなければ試験の工数は減らない。むしろ、単位規模あたりの試験工数は増える。
比較対象が、過去の非効率なたくさんのコードであるならなおさらだ。
徒競走する際に100メートル走と300メートル走でかかる時間が同じかどうか比較しているようなものだ。

規模が減ることに比例して工数を削減できるとは限らない。
開発現場を直視している人であれば理解してもらえるのだが、単純に集計した数字でしか物事を判断できないようでは、同じように社内で開発している人にとっては、先が思いやられる。
ただ、上から規模ではなく、工数を減らすための工夫を求められているのも確かだ。
工数を減らすために何をすべきか、これは自分にとっての新たな課題だ。

ただし、自分にとってたくさんの成果があったことも確かである。

・ リスクの高い新技術、アーキテクチャを採用したこと
その際にさまざまな数値を記録することができた。
新技術を導入する場合、何をどこまでする必要があるか分かった。

一番の成果は、自分にとってこのしんどいプロジェクトをやり遂げたこと。
そして、これからこの成果を元にさまざまなエンジニアの方と情報交換ができるのではないかと考えている。

これから、自分の策定したアーキテクチャを使用したプロジェクトの第二弾が始まる。
それは、今回リリースしたシステムとは別のプロジェクトだ。
ゴールデンウィークまでまた、家に帰らない日々が続く...