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

開発効率化についていろいろ考えてみたが、工数を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.だなぁ。このため、今までこれだけコストがかかっている旨をまとめて納得していただけるように準備ですね。

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

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

 

自分の価値

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