無料ブログはココログ

« 2016年5月 | トップページ | 2016年7月 »

日本は遅れているのではなくやられている - いつ追いつくねん! -

古くから日本は米国に5〜10年遅れていると言われていました。現在もその差は縮まった様には思えません。しかし、よく考えると遅れてるのではなくて負けている、いや、やられているのではないでしょうか?

日本は遅れているか

ここ20年ぐらいを振り返ってみると、CMMブームやアジャイルブームなどがありましたが、CMMが出てきた時は日本のある企業がだいたいレベル3だと記事を書かれていましたし、スクラムやリーン等は日本の技術を参考にしたと言われています。

日本ではそれぞれの企業文化があったにも拘らず、まじめにレベルを1つずつ2−3年かけて上がろうとして、いわゆるレベル3の壁にぶちあたり、企業文化もつぶしてしまいました。

その間にインドは数年でレベル5を達成し、オフショアビジネスが成功しました。アジャイルの源流になった日本の技術や、アジャイルとの向き合い方も同じようにやられている感じがします。

むかしは国際会議でも日本企業の品質管理は高い評価を得ていました。ただ、日本の技術は企業内での技術にとどまり、世界に向けてアピールや標準化、技術をビジネスに活かすのが下手だったと思います。

「ソフトを他人に作らせる日本、 自分で作る米国」を読んでという記事のスライドにあるように、 ハンフリーさんの「ソフトウェアでビジネスに勝つ 」にはリリース済みのソフトウェアが、20欠陥/KLOCだったとされています。50行ごとにバグがあるソフトをリリースするなんて日本ではあり得ないと思います。

アジャイル開発の比率が低いのは遅れているのか

アジャイル開発しか考えられない人には遅れている様に感じるかも知れませんが、

米国IT業界に過去あった多重下請構造、それが破壊された理由 - プロマネブログ

にあるように、英語圏ではCMMブームの後にオフショアブームがあって、プロセスの品質が保証できる海外に従来型のビジネスが流れました。結果的にオフショアが困難なビジネス直結型の開発が残ったと言えるでしょう。

遅れているとすればオフショアですね。

なぜやられているのか?

CMMの時はこれまでのやり方は古い、標準プロセスで組織全体を改善してレベル達成だ!と頑張った企業も多かったので、すぐにカイゼン文化を捨ててしまいました。そうこうするうちにCMMIになって段階的でなくて良いなどと言われ、仕切り直し。ブームには良い点もありましたが、日本の企業はかなり疲弊した様に思います。

真面目に頑張っても、オリンピックのようにルールを変えられます。スクラムガイドも初めは優先順で、書籍「アジャイルと規律」にある他のアジャイル開発法のようにリスクベースでないと使えないと思っていたら、次の版では表現が変わりました。どうやって優先順で開発するのか頑張らなくて良かったと思いました。

日本人は真面目なので、良いものと言われると「守破離」よろしく、まずは完全に実施しようとします。でも、ビジネスにレベル5が必要だからそれを達成すると割り切れば、インドよりも早くレベル5を達成できたのではないかと思います。

このように振り回されない方法は、ルールを決める側に立つことです。すでに多くの日本企業が規格委員会に入るなどされていますが、もっと多方面でアピールする必要があると思います。

可能な戦略

とはいえ、多勢に無勢だったり、ビジネスとのつながりや、リソースの問題もあって正攻法が正解とは限りません。やられないには工夫が必要です。

【別の道を進む】
同じ土俵にたたない方法です。遅れていると言われようがビジネスが成り立つなら、それはそれで勝者です。トコトン極めて最後に残れば、誰にも負けない存在に慣れるでしょう。希少価値が出るかも知れません。今さらCOBOLと言われていたのに、2000年問題ではかなり儲けた方もおられるのではないでしょうか。

【使えそうなところを取り込む】
技術には想定する対象がありますので、そのままでは使えないなら、必要な所だけを取り込めば良いと思います。デザインパターンや組織パターンでさえもパタンランゲージ([#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -)の考え方の一部を利用したものである事を知ってから、特にそう思う様になりました。

【追いつき追い越せ】
とはいえ流行りの技術には、最新の技術が集まります。そのまま適用できるなら部分的でなくしっかり使うのも良いでしょう。ただし、受け身にならないで得意分野だけでも貢献すべきだと思います。情報発信すれば情報は集まります(情報を得るには Give & Give - 発表のモチベーション -)。いずれ追い越す事も可能でしょう。

おわりに

遅れているからやらないといけない。なぜなんでしょうね。変わらないといけないのは問題がある時です。そうでなければ、少しずつ改善すれば良いのではないでしょうか。

人が存在価値を発揮するは、その人の能力を発揮した時です。ブームに乗っても能力が発揮できないなら、意味がありません。社会貢献(ビジネスを含む)ができる得意分野があるなら、そこで能力を発揮して楽しめば良いと思います。

これ以上やられちゃったら嫌なので、、

このエントリーをはてなブックマークに追加


WFかアジャイルではなく、将来のソフトウェア開発を考えてみた

未だにネットワークの世界では、アジャイル開発だとかウォーターフォール(WF)開発だとか騒がれていますが、プロセスはそんな単純なものではありません。

それぞれに得意分野があり、現在の多くのプロジェクトに効果的な選択ができるでしょう。 それぞれでどんな工夫をしているかはとても参考になりますが、どちらで成功しているから他方はだめだとか、どちらで自分が不幸なのかを語っても他の分野では役立ちません。

そこで、ソフトウェア開発の流れを考えて、未来の予想をしてみます。今の現場にとってふさわしいプロセスは、将来のソフトウェア開発にふさわしいとは限りません。でも、将来に向けて今から検討しておけば、いつか役に立つと思います。

厳格なウォーターフォール(WF)開発

そもそものWFは、大規模なソフトウェアを開発する方法として生まれました。大規模なソフトウェアでは全体が混乱したり、仕様変更により肥大化しがちで、予定の期日や予算で完成しなかったからです。

そこで、計画を重視して進捗を見える化しました。工程という考え方を導入して分割統治が図られ、各工程でのドキュメントを中心とした成果物や、信頼性を中心とした品質のメトリクスを管理する事で下流工程での混乱を防ごうとしました。

批判対象になっているWFはこのようなプロセスだと思いますが、巨大な一つのシステムを開発する際には一定の成果をあげてきました。

アジャイル開発の登場

20世紀末になるころには、計算機の性能向上、ネットワーク機能、オブジェクト指向を中心としたソフトウェア開発技術の向上によって、短期間、多機能、広い意味の分散処理、多様なシステムが実現可能になりました。

開発の環境や対象が変わるに伴い、従来の様に一度に大きなものを作る事が避けられる様になりました([#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう)。

ボトムアップに実装を積み上げていくアジャイル開発は、リスクを低減する方法として、自社開発企業やユーザビリティを重視する一般ユーザ向けソフトウェア開発に利用されました。

現実的なWF開発

アジャイル開発が生まれる遥か前から、厳格なWF開発が実施不可能な現場では、最適化が行われました。具体的には、工程の完了の前に次工程を開始する、仕様変更の管理を柔軟にする、プロトタイピングによりリスクを低減する、段階リリースする、などです。

このように現実に最適化された開発は、スコープを可変にするアジャイル開発になかなか移行できません。特に決められた期限までに最低限必要な「一式」の機能を実現しないといけない業務システムではその傾向があると思います。

現実的なWF開発では仕様変更に柔軟に対応するほか、請負開発ですので請負側が瑕疵担保責任を持つ事で、発注側のリスクを減らすことができます。決められた期間に必要な「一式」の機能を実装するには有利な方法です。

その反面、納期が迫ってからの仕様変更には残業や増員による対応が必要で、開発者の負担は大きくなります。批判は当然ですが、このような開発が少なくなる事はあっても、発注側にメリットがある間は無くなりはしないでしょう。

近未来の小規模ソフトウェア開発

近未来の小規模ソフトウェア開発は、以下を想定しています。

  • 生産性が高く、高機能なソフトウェアを少ない工数で開発できる
  • 少人数でチームが構成され、開発期間も短い
  • 高度に自動化され、短時間でデプロイできる

生産性が極端に高くなると継続的にバージョンアップする環境に追随する事が難しくなり、アルゴリズムを「どのように実現するか」と考える時間よりも、最新の環境で「実現できるか」を確認する時間の方が長くなります。

リスクが高くなると請負では高価になりすぎるので、顧客にとって準委任契約の方が安価に望みのソフトウェアを得られる可能性が高くなります。準委任契約だと発注側と受注側で契約範囲の議論は少なくなり、要望を満たせる良いソフトウェアについて前向きな議論が容易になるでしょう。

その一方で準委任契約だったとしても、従来のプロセスと前提が異なるので見直しが必要になります。

近未来の大規模ソフトウェア開発

一方でこれまで規模や予算の関係で実現できなかった大規模開発も行われる様になります。クラウドで支援されたアーキテクチャを利用して、システムのスケーラビリティや分割統治が実現できる様になります。

しかし、それは管理的視点での分割ではなく、技術的視点、つまりアーキテクチャー中心の分割になります。アーキテクチャ設計が先行して行われますので、実装プロセスはともかく、プロセス全体では段階的(WF型)になります。

このような開発の特徴は「一式」の機能を一度に揃える事です。しかし、実装時のリスクはドンドン高まりますので、ある程度は実装を優先した開発になってくるでしょう。

近未来はスクラムが難しくなる

準委任開発が増えるならアジャイル開発、今ならスクラムの導入が増えそうなものですが、アジャイル開発の「考え方」と「やり方」は利用するもののアジャイル開発とは似て非なるものになると思います。

私もNode-REDの開発をして近未来感を感じていますが、新規性の高い開発ではアジャイル、特にスクラムはうまくいかないと感じています。具体的には以下のような理由です。

変更を早く反映したい:アジャイル開発では開発者が集中を維持するために、イテレーションやスプリントと呼ばれる繰り返し開発のタイムボックス中の仕様変更から守られています。しかし、技術的な問題は関連する作業の継続を難しくしますし、短期間・少人数の開発では問題は即座に解決する必要があります。

ロールモデルよりも関係者の協調が必要になる:少人数での開発では小さな問題が全体に影響します。ロールを分けて開発メンバーを守るよりも、お互いに協力して知恵をだしあうことが求められます。また、そもそもロールを兼務するようでは組織パターンを利用している意味はあまりありません。

増員も時には必要:チームビルディグは重要ですが、期限の限られた仕事では増員が必要な事や、フェーズによって減員が必要な事もあります。そこでチーム単独でなく、同じ分野のチーム間で人をプールしたり、情報共有する仕組みが必要になります。

近未来のソフトウェア開発の難しさ

近未来のソフトウェア開発を考えると、厳格なWFもアジャイル開発も厳しいものがあります。開発者に負担にはなりますが、現実的なWFが今あるなかでは柔軟にさえ思えます。

そもそもWFは肥大化しない様に外側から束縛し、アジャイルは骨組みを作って肉付けをチームビルディングに任せている事から、現実の問題にプロセスで対応することを直接支援していません。

小規模開発は工数増加による被害も小さいので、これまであまり注目されてきませんでした。しかし、近未来には実装の単位がドンドン小さくなり、品質を維持しながら現実の問題を解決できる実施方法が必要となるでしょう。
(参考:クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

近未来のソフトウェアプロセス

建築の世界では大規模で無機質な開発の後に、無秩序な小規模開発が増えて、魅力的な街づくりが難しくなりました。そこでパターンランゲージが注目され、関係者が集まって現実の問題回避に必要な具体的な解決パターンを導き出し、それらと実際の制約を元に現実的なプロジェクトランゲージを構成し、魅力的な街づくりをする方法がとられています。

ソフトウェア開発もこれまでの様に良いプラクティスを全てやるのではなく、関係者で現実をふりかえり、品質を維持するための制約、チームビルディング、開発対象の実現方法、リーズナブルな運用の方法をパターン化し、より良いプロセスを構築することで、現実問題を解決できるプロセスが構築できると思います([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。

そして、その具体的な情報の収集源としてチケットが有効だと思います。

【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。

第65回 SEA関西プロセス分科会&RxTStudy #15
チケット管理システムによるプロセス支援と今後の課題」 (07月30日)

このエントリーをはてなブックマークに追加


MacBook Air に3,180円で64GB増設 - 安いSDアダプタ発見! -

MacBook Air(MBA)の13インチは今にすれば若干重めですが、画面が広く、SSDなのでとても快適です。しかし、ディスクの空き容量が減ってくると急にご機嫌が悪くなります。

そこで、SDにあまり使わないデータを移して空きスペースを広げる事にしました。しかし、MBAのSDスロットは奥行きが浅く普通のアダプタでは飛び出してしまいます。

調べてみるとMBAのサイズに合わせたアダプタが700円台から3,000円位まで色々ある様です。安いものは全機種共通、高いものは機種専用で出っ張りが無い様です。

古い機種にお金をつぎ込むのももったいないので、安い中でも出っ張りに不満の少ないものを選びました(proの人は不満な様です)。2011年版 MacBook Airの写真を貼っておきます。

Img_4940


SDカードも色々あって、高速なものはすぐに壊れたり、偽物があったりするようです。速度が遅くても信頼性が高いと評価されている東芝製を検討しましたが、この春にロット不良があったとの書き込みをみつけました。そこで、偽物との不満が出ていないショップを探して買いました。

いまのところ不満はありません。ただ、念のためバックアップを取ってから消そうと思っていますので、導入効果はそれほど出ていませんw

ご注意

ノートパソコンに出っ張ったカードを入れたままの移動は危険です。私もPCMCIAの通信カードを入れた状態で移動していた時に、肩にかけてきたカバンのバンドの金具が壊れてマザーボードを交換する事になりました。ノードパソコンのカードソケットの多くはマザーボードに直結していますので、カードに大きな力がかかると基盤のパターンごと奥に押し込む事になるからです。ですので移動時はカードが出ていない状態が一番安全です。今回のカードの出っ張りは1mm程度ですので、机の角にあてない限り大丈夫だと判断しました。カードを指した状態で移動される場合は、カードの出っ張りは危険である事を認識いただいた上、個人の責任で使ってください。

このエントリーをはてなブックマークに追加

SS2016に未来を見た - 生産性が高くなると手戻り工数が減る -

今回のソフトウェアシンポジウム2016も色々と得るものがありました。その中でも新しい気付きを得られたのがサイバーリンクス 松山さんらの経験論文「情報システム開発におけるソフトウェア資産の上流シフトへの対応」です。

新世代のアプリケーション自動生成ツールGeneXusを使った際の経験を発表されました。超高速開発などではすぐに作れる所が主張されがちですが、この発表では手戻り工数も少なくなる点が説明されて「なるほど」と思いました。

新規の開発であれば生産性の向上は短期開発を実現し、商機を逃さないといったところが目的でしょう。しかし実際は、開発中はもちろんのこと、リリース以降も障害の対応やバージョンアップで多くの修正が加えられ、その際も高い生産性が役立つ事になります。

この実感はあまり理解されないかも知れません。でも最近、GUIでモジュールの組合せでプログラミングするNode-REDの開発をする中で、同じような事を考えていました。

Node-REDを使っていると生産性が高く、1日10回どころか1時間10回ぐらいのデプロイも平気です。そんな環境を使っていると、開発も手戻りも一瞬で、実現可能性の検討や全体の設計等がほとんどの時間になります。

(具体的に言うと公開されているモジュール(ノード)を探してインタフェースを確認、動作確認後に前提を構成、動作確認、がほとんどの時間の様に思います。たまにはロジックでもはまりますが、、)

GeneXusやNode-REDような生産性の高い仕組みが全ての分野をカバーできるとは限りません。しかし、将来ソフトウェアの生産性の格段に高くなり、DevOpsというまでもなく、デプロイや運用までが自動化されたなら、多くの時間が上流に割かれる事になる。そんな未来があるかもしれない。そう思いました。

もちろん従来型のプログラミングが無くなる訳ではありません。同じような議論は、開発の中心がアセンブリ言語から高級言語に移った際もありました。

ある言語が中心でなくなっても、存在がなくなる事はありません。比率が変わるだけです。もちろん、どちらが儲かるか、失業し易いかも人それぞれの立場や能力によって様々でしょう。

このような環境を前提に考えると、プロセスも必然的に変わってくると思います。そのお話はまたいずれ、、

このエントリーをはてなブックマークに追加


« 2016年5月 | トップページ | 2016年7月 »