無料ブログはココログ

iPad mini 2(Retina) 充電不可(Lightning コネクタ故障)顛末記

iPad mini Retina(3が出たので2と呼ばれています。以下 iPad mini2 )で電子書籍を読む(電車でPDFが読める! iPad mini retinaモデル WiFi C?)だけではもったいないので、「ひかりTVどこでも」を見たり、「アマゾンプライムビデオ」をTVで見る際にも使っています。

トラブル発覚

先日、プライムビデオを見ようとHDMIアダプタを接続すると、反応がありません。他のケーブルをつないでみたりしましたが、反応がありません。

同じケーブルにiPhoneをつなげると反応しますので、どうもiPad mini2のコネクタが壊れた様です。

修理価格を調査

AppleCare+に入っていませんし、入っていても2年以上経っていますので、全額自費になります。調べてみると、iPad mini2 の修理費が表示されているのは、大阪市内のお店が12,000〜15,000円、東京なら郵送ですが1万円弱でありそうでした。

地元の京都は表記が無かったですし、会社が大阪なので大阪でも構わないのですが、すでに買い取り価格が 1万5千円程度なのに、郵送したり1万円以上かけるなら、中古のAirかKindleでも買った方が新しい経験ができて楽しいかも、と考えていました。

Smart Doctor PROFESSIONAL

たまたまスマートドクタープロ 京都河原町店の前を通ったので、冷やかし半分で聞いてみると9,800円。ただし、半田作業になるので、(これまではないが)最悪の場合は壊れることがあり、その際は使えなくなるが無料とのこと。

修理費が高いから捨てようとしていたので、それだったらと持ち込みました。1時間半ほどたって修理完了の電話で伝えられたのは、「クラック」だったので部品交換せずに済んだので、7,800円とのこと。予想外に安くつきました。

ただし、部品交換していないこと、コネクタは使い方次第なので修理後の保証期間はないとのこと。ただし、なにかあればチェックはしてくれるとの事ですので、良心的だと思います。

原因の考察

クラックということで、たぶん半田が浮いてきたのでしょう。思い当たるのは、アマゾンプライム再生機としてHDMIアダプタをずっと付けていた事です。

少しぶら下がるような状態だったので、負担になったのでしょう。今後は気をつけたいと思います。

おわりに

1万円以上も出すのだったらと捨てるつもりでしたが、現状なら中古で売っても差し引き7,000円のプラス。元々、気に入って買ったものですし、色々と使い道もありますので、本当に壊れるまで使っていきたいと思います。

今回、勉強になったのは、金額が表示されていなくても修理できる事があるという事です。部品の在庫まであったので不思議な感じがしますが、全国展開しているので難しい修理は相談してください。という事なのでしょう。

ということで、動く様になりました。よかった、よかった。

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

『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

Redmine実践ガイドの5章の終わりに「Tracユーザーから見たRedmine」というコラムを書きました。先日のRxTstudyに参加して、Redmineのチケット番号の一意性の優位点について書き忘れている事に気付きました。

具体的には、あきぴーさんの発表のスライドの「PJ分割ルールの効果」のところで、

「そんなの、1プロジェクトにバージョン管理ツールの1リポジトリがあたりまえじゃん!」(なぜか浜っ子風)と、思った時に気付きました。

Tracは1プロジェクトに1リポジトリが基本です。複数プロジェクトでリポジトリを共有する際は、リポジトリからTracへの参照にプトジェクトを示すプレフィックスが必要になります。

でも、Redmineではそんなのお構いなしで、一つのリポジトリを、親子であろうと無かろうと、複数のプロジェクトから参照できます。

このような違いが出るのは、Tracのチケット番号がプロジェクト毎に0から始まるのに対して、Redmineのチケット番号は全てのプロジェクトで通し番号になっているからです。常にチケット番号が一意に決まるので、リポジトリからの参照にプロジェクトのプレフィックスが不要になります。

機能的には同じですしツールを使っているなら大きな違いはありません。でも、Tracの場合はあらかじめプレフィックッスを付けて運用を始めないといけないので、同じプロジェクトでずっと運用する事になりがちです。

一方、Redmineの場合はとりあえず始めておくことができます。そして、予算等の管理単位や派生開発等で構成メンバーが異なるなど、1つのプロジェクトでやりにくくなった場合に別のプロジェクトや子プロジェクトに分ける事ができます。

Redmineはチケット番号が通し番号なので、見ていないチケットがあるかどうかがわかりにくいという面もありますが、プロジェクトが長期にわたったり、大きくなると有利な面があるのですね。

追記:

このような理解ができて、ようやく赤羽根さんが努力されている価値がわかりました。Redmineを複数立てない事がRedmineの活用につながると思います。

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


標準化やタイムボックス管理ではできない具体的な支援をするプロジェクトランゲージ - カレーの作り方から考える -

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で発表しました。

プロセスはモデリングすることで知識を 伝達、理解、改善、管理、 支援、自動化できますが、現状の扱われ方はカレーの作り方で言うなら、重量やカットした結果を測定したエビデンスを求める。あるいは、分担を決めたり、定期的な味見をする事が決められているだけです。



たとえば顧客向けのデモを実施する必要があった時も現場が考えることが求められるだけで、過去の経験を参照したり応用する方法は支援されていません([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。

建築分野などで用いられるパタンランゲージはそのドメインで解決が求められている(要求されている)問題とその解決策等を整理したカタログです。

プロジェクトランゲージはパタンランゲージを元に、ワーキングマスタープランを用いて、顧客と共に段階的なプロジェクトを構成していきます。そのドメインで求められているパタンを具体的な制約を踏まえて組み合わせるので、ノウハウを活用する事ができます。

このような方法をとるには、まずDDDのユビキタス言語にも似たパタン(=対象ドメインで求められているもの)の素(言葉)を集めないといけません。そこで、過去のチケットを分類して、チケットを活用できないかを考察してみました。

なお、スライド中の航空写真は奈良先端大(NAIST)付近の北大和住宅にある地区センター付近のものです。パタンランゲージとプロジェクトランゲージは当時の様子を回想して独自に考えたものです。

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

巨人の肩に乗るBABYMETALを輸入版ブルーレイでチープに楽しむ

BABYMETAL(リンク先はWikipedia)は、なぜこんなに人気なのでしょう。自分が好きな事を置いておいて、輸入版ブルーレイディスク(BD)を見ながら考えていました。

1枚目:武道館ライブx2

もともと、YoutubeとアマゾンのPrime Musicで楽しんでいましたが(BABYMETAL :「ブルーオーシャンは闇の中」あるいは「デカルチャー」)、やはりライブの雰囲気が知りたくなりました。

最初に買ったのは「LIVE AT BUDOKAN 〜RED NIGHT & BLACK NIGHT APOCALYPSE〜」です。アマゾンのimport盤には曲数が半分だけ載っていますが、コメントにある様に日本版と同じ28曲は言っています。

輸入版は国内・国外があります(輸入版販売リスト)。この時は、早く見たかったので国内で買いました。

このBDは2日連続で行われた RED NIGHT と BLACK NIGHT のコンサートの内容を収録したものです。 RED NIGHTの方はCDになっているからか、ちょっと音が良い気がします。

中身はバッチリです!1枚目の通常版アルバム曲+2曲を、日本らしい丁寧なライブ映像です。

2枚目:ロンドンライブx2

1枚目が良かったので、もう一枚買いました。

2枚目は「LIVE IN LONDON -BABYMETAL WORLD TOUR 2014-」で、1枚目の前にヨーロッパで武者修行した際の初めと終わりのライブです。ストーリーがこの後の武道館のライブに繋がっています。

さすがバリライトを初めて使ったジェネシスの国です。照明が激しく動き、点滅します。

会場もノリノリで観客の上を転がったり、持ち上げられたり、走り回ったりします。1本目の後半はちょっと多過ぎかと思うぐらいカメラが切り替わり、ライブ感がたっぷりです。2本目はカメラがやや引き気味ですが、3人の様子が良く分かって、これはこれで楽しめました。

驚くのは観客が日本語の歌詞で歌うことです。特に1本目は女性も含めたコアなファンが多いのか、意味が分からないと盛り上がれないのねだり大作戦の「天使の顔した悪魔のささやき」のところで、一部で盛り上がっているのにはびっくりしました。

このBDは輸入版販売リストで安いお店を探して買いました。発送が早かったのですが、中継が多いのか2週間以上かかりました。

なぜこんなに人気があるのか?

初めて見た時は「なぜこんなに人気があるのか?」と驚きました。でも、見ている間にお気に入りになりました。それには、いくつかのポイントがあると思います。

◎ 巨人の肩に乗る

論文を書く際に言われる「巨人の肩に乗る」という言葉がありますが、BABYMETALはこれを見事にやっています。アイドルの基本、パントマイム風のダンス、世界的に評価されている神バンド、など、基本を押さえた上でアイドルとヘビーメタルを融合した新しい世界を構築しています。

本格的だからこそ、安心してヘビーメタル好きも楽しめ、ヘビーメタルに興味の無かった人も興味を持てる様になるのでしょう。

◎ 遊び心

本格的とはいえ、遊び心もあります。コミカルなダンスのほか、なぜかレゲエが入っていたり、父親におねだりする歌があったり、「1たす1は2」等という歌詞があったりと、色々と楽しめます。初めは何をふざけているんだろうと思いましたが、海外でみんながノリノリで、走ったり、持ち上げられたり、転がったりしているのを見て、もっと単純に楽しめば良いと思い、より楽しめる様になりました。

ヘビーメタルの世界にはメロイック・サインというものがあります(ハルクホーガンのウィーの指サイン)。これをBABYMETALが教わった際に「キツネさんだー♪」と遊んでいたら、それが採用されたそうです。このユルさは、元々ユニットだったこともあるのでしょうけど、面白いですね。

◎ ピボット

元々は成長期限定アイドルグループさくら学院のクラブ活動である「重音部」として始まったそうで、最初の頃は学生服姿で歌っていたり、エレキギターを持たされたりしていた様です。しかし、どんどんピボット(方向転換)して、尖っていきました。海外で注目される様になってからは、能の舞台や日本的な節回しやかけ声、外人が好きそうなカッコいいコスチュームなど、どんどんピボットしています。

ももクロ(リーンを考える - 無駄と必要なアソビ -)もそうでしたが、マーケットや状況にあわせてピボットする事が、未来につながるのでしょう。

おわりに

本格的なファンならWeb会員になって独占販売の高価なBDも買うのでしょうけど、チープに楽しむのも良いかとまとめてみました。いかがでしょう。

今週末にWOWOWでもライブをする様です(BABYMETAL WORLD TOUR 2016 kicks off at THE SSE ARENA WEMBLEY)。WOWOWは1ヶ月2,300円しますが、ひかりTVの無料視聴ができたので、こちらもチープに楽しむ予定です。

「アチャチャチャ」ってなんやねん!と思われる方も、一度じっくり見てください。思いのほか楽しめると思います。

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


アジャイルのレフトウィングには壁がある - 自律的組織実現への考慮点 -

アジャイルには開発環境のライトウィングとチーム環境のレフトウィングがあると言われます(アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ)。

この中でも難しいのがレフトウィング、特に自己組織化されたチームです。アジャイル開発を始めたからといっても簡単には実現できません。自己組織化されたチームを実現するにはチームのメンバーの価値観を変える必要があるからです。

注:筆者はすでにイテレーションの実現あきらめていますが(ミーティングに同期するタイミングはあります)、それ以外のアジャイル開発の要素には重要な内容が含まれていてなるべく実現しています。特に自己組織化はマネージメントの重点であり、20世紀からネットワーク組織とか新しいリーダーシップ(支援者としてのリーダー - 「リーダーシップ3.0」を読んで -)として語られている重要成功要因です。

すでにアジャイル開発への壁は価値観の壁で、基本的な考えを書きましたが、今回は具体的にどう言う点に注意しているかを欠きたいと思います。

自己組織化され他チームは自律的であり、従順ではいけません。それぞれが考え、能力を発揮し、貢献することが求められています。そういったチームの実現には3点への考慮が必要です。

  • オープンな議論ができる
  • 互いにリスペクトできる
  • 話が噛み合うこと

それぞれにどのような注意点があり、どのように対応しているかを整理したいと思います。

オープンな議論ができる

基本は序列を気にしないで技術論を戦わせる事ができることでしょう。上の人はサーバントリーダーシップを心がけて、対等な関係を築かないといけません。

ピラミッド型の組織を経験した人は従順で自分の意見を言おうとしません。なぜそう考えるか、どうやると良いと思うか、と聞いてみると良いかも知れません。

時には最終判断を迫ってくるかもしれません。「聞いて答えたらそうするの?」と言った事もあります。まずは考えてもらい、議論する事が大事だと思います。

やらないとわからない事はやってみたら良いと思いますし、考えてないなら考える様にアプローチしないといけません。それは上に従うのではなくてチームで考え、みんなでゴールを達成し、共に喜ぶために必要な道のりです。

互いにリスペクトできる

偏差値教育の弊害でしょうか、それとも頑張れば神や仏になれるという宗教の影響でしょうか、日本では一つの基準で人が評価されがちです。立身出世という言葉からは昇進する事が成功で、できない人はダメという印象を受けます。

しかし、人それぞれに特長があり、存在価値があります。能力が低くても努力して貢献した人は賞賛すべきですし、能力があっても協調せず、貢献しない人は評価されるべきではありません。

アジャイル開発では多能工、いわゆるフルスタックなエンジニアが揃うとうまく回し易いでしょう。しかし、それぞれの特徴的な能力が生かせる環境も大切だと思います。

書籍SCRUM BOOT CAMP THE BOOKでは、それまで目立たなかったバッチ君が後から活躍します(日本でスクラムを実践するなら読んでおきたい本(SCRUM BOOT CAMP THE BOOK))。このバッチ君のように自分の能力を生かして貢献し、能力を生かせたことを共に喜ぶような価値観の焼き直しが必要だと思います(日本文化に仕立て直した実践書 - SCRUM BOOT CAMP THE BOOK の意義 -)。

人それぞれ、多様な価値感や経験、事情があります。それらを考慮してプロジェクトを運営し評価する必要があります。その多様な評価が、互いのリスペクトに繋がり、対等に議論できる環境の実現すると思います。

話が噛み合うこと

チームで意見を交換するには、全体のゴールを共有できている必要があります。もちろん個人の目的は違っうでしょうが、全体としては同じ方向を向かないと議論ができません。

時間精算だからサボったほうが売上が増えるとか、時間精算がないから変更はなるべく受けない、など自分勝手な基準ではなく、ゴールを把握した上で互いのビジネスモデルも理解してWin-Winになれないといけません(アジャイルかWFかの議論はやめよう。大切なのはWin-Winの実現)。

おわりに

アジャイル開発宣言はソフトウェア開発に必要な要素をまとめたものです([#Agile] アジャイル宣言と原則の私的まとめ)。なかでも自律的な組織に関してはソフトウェア開発だけでなく、変化の激しいビジネスでも必要とされているものです。

かつての追いつけ追い越せの時代は進む方向が明確でしたから、トップダウンにコマンドコントロールする事が効率的でした。しかし、すでにトップグループに入ってしまった日本は、変化する状況に追いつくだけでなく、日常的にイノベーションを起こせる自律的な組織が求められています。

今回は自律的組織の実現に必要な考慮点と取り組んでいる内容をまとめました。少しでも皆様の参考になれば幸いです(他に良い方法があれば教えてください)。

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


[#TiDD] パタンランゲージで経験を活かしたプロセスを構築する

プロセスが好きだと言うと若い人は怪訝そうに見られる。品質保証の人からは「SEPG(標準プロセスを制定するグループ)とかですか?」と聞かれる。アジャイルな人達は「プロセスやツールよりも個人と対話を」と言われる。

そんなことは無いはずです。一般に「プロセスはタスクの集合」と定義されるからです。つまり、ソフトウェア開発をしている人は皆、プロセスを実行しているからです。

モデリングの失敗

このようにプロセスが他人事の様に語られるのは、プロセスのモデリングに失敗しているからです。「ソフトウェアプロセスもソフトウェアである」と言われていますが、これまでのプロセスのモデルはプロセス特徴を表現できなかったからです。

そもそもプロセスモデリングは、プロセスの知識を伝達、理解、改善、管理、 支援、自動化するものです(参考:[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。しかし、ウォーターフォール(WF)の標準プロセスやスクラムは、メタなプロセスと汎用的なプラクティスを示したもので、過去の具体的な経験を伝え、そのノウハウをソフトウェア開発として活かす仕組みは、肥大化し易い標準プロセスによる管理や開発チームの習熟に依存しています。

例えばユーザデモ

たとえば「段取り8分」といわれるように段取りは重要ですが、例えばユーザデモをどのように調整するかといった基本的な事もうまく支援できません。

【標準プロセス】
仮に標準プロセスに実施方法を書いたなら、「うちはこのやり方です」と顧客に言ったり、何らかの事情でテーラリングしたくても制約を受けてしまう事があるでしょう。
逆に詳しく定義しなかった場合は、それぞれのプロジェクトでWBSなり線表に落としますが、どのような条件があってその計画にしたかがわかりません。このため、前回は顧客が用意してくれたので、デモ用のデータや会場の準備を忘れるかもしれません。
経験の少ないマネージャーなら、マイルストーンの設定だけで必要なタスクが漏れているかも知れません。

【スクラム】
スクラムではタスクの依存関係や期限をうまく管理しないいけませんが、タイムボックスからあふれて間に合わないなんてことが起きるかも知れません。
ベテラン揃いなら色々な工夫や調整を行うのでしょうが、それはプロセスで支援されるのではなく、開発に関わる人達の習熟に任されています。勉強会やコーチが必要な訳です。

どんなモデルなら支援できるか

これらのプロセスモデルをソフトウェアの概念に当てはめてみると、クラスや機能であって、段取りに必要な関連や状態概念が不足している様です。

【クラス指向】
WFの標準プロセスは抽象クラスの責務でモデル化されています。WBSに代表される様に細かな構造に分解してプロセスを定義します。インスタンスに相当する内容は自由だが責務だけは果たす様に求められています。CMMを提唱したハンフリー氏らはプロセスのスキップが最も大きな問題と考えていて、抜け漏れチェックが重視されています。ただし、このモデルに基づいてもインスタンス化する際に考慮が必要な内容は直接は支援されず、組織内で定義し、訓練によって実現しないといけません。

【機能指向】
スクラムのロールモデルは機能で分割され、ロール間やロール相互のコミュニケーションに必要なアーキテクチャ、具体的には外部との連絡、コンセンサスの共有、などの仕組みを持ちます。実現する順序はバックログで管理されますが、バックログの調整はオブジェクトである人に依存しています

このように プロマネ、リーダ、プロダクトオーナは苦労しています。それは具体的なプロセスで考えないといけない段取り、つまり状態があまり支援されていないからです。

【状態指向】
実際にプロジェクトを実施する際には、具体的な開発対象の状態が考慮されます。具体的には、いつまでに何を作るかを考えてそれに至る道筋を考えています。これがいわゆる段取りです。上記2つのモデルでは具体的な開発対象を直接扱いませんので支援が行えないのです。そこで開発対象の状態を考慮したプロセスが必要になります。

パタンランゲージ

そこでパタンランゲージです。開発の計画を立てる際は、ゴールや制約に合わせて、過去の経験した作業を当てはめ、必要に応じて作業を組み立て直します。まさにマネージャがしてる事です。

パタンランゲージを利用する際は、この工程をパタンランゲージとプロジェクトランゲージ2段階で行います。関係者からのインタビューで良いと思ったものをパタンランゲージとして整理し、制約を考慮して組み合わせてプロジェクトを段階的に構成していきます。

パタンランゲージはどのような問題(フォース)をどのように解決するかを集めた、いわゆるパターンの集合です。誤解を恐れずに言うと、そのドメインに特化したDDDのユビキタス言語に相当するものだと思います。

プロジェクトランゲージでは パタンランゲージを構造化・洗練したものを表の縦軸に、プロジェクト横軸に取った表を作成します。実施する交点につける印が多くなる様に、制約を考慮してプロジェクトの実施順序を決めます。ちょうどユーザーストーリーマッピングを左に回転させたようなイメージです。

(参考:本橋、中埜、羽生田、懸田、江渡、パタンランゲージからプロジェクトランゲージへ共創のプロセス(PDF),AsianPLoP 2011)

パタンランゲージで経験を活かしたプロセスを構築する

ここで先ほどのユーザデモを考えてみましょう。ユーザデモはパタンの一つですので、パタンランゲージに加えられるでしょう。

それだったら従来のプロセスでユーザデモを追加したのとあまり変わらないのではないかと思われるでしょう。実はこの時点で他のパタンと同列に並んでいる所が後で効いてきます。

プロジェクトランゲージを作成する際はセンターと呼ぶ概念や対象物を明確にします。ユーザデモがより重視されるならレビュー作業を中心的なものにするかも知れませんし、逆にユーザデモをキーマンに対してだけ実施するかも知れません。

従来だとユーザデモのような作業は足し算でしかなく、標準プロセスや元のフレームワークを変更する事はできません。パタンランゲージは関係者で協議して方向性を決める(センタリング)しますので、バランスの良いプロセスを再構築できるのです。

どこから始めるか

パタンランゲージのやり方は、小規模プロジェクトでよくやっている事です。示された制約と使えそうな経験を思い浮かべ、依存関係のあるまとまりでその実施順序を決めていきます。

ソフトウェア開発の規模が小さくなると実施できる事が限られます。関係者で議論する事でバランスの良いプロセスを構築して、顧客の要望に応えていたのです。

経験を集めてパタンランゲージを構築する方法は、チケット駆動開発で作成した過去の履歴を分類して活用できると考えています。

まずはチケットにどのような経験が蓄積されているかを調べ、その結果を次回のSEA関西&RxTstudyの勉強会で紹介するつもりです。

まとめ

具体的な計画をする際に現れる制約をモデル化せずにクラスを作ったり、枠組みを作っても上手くいきません。その状態で頑張れば頑張るほど、大事な事が個人に閉じてしまいます。

今回紹介したパタンランゲージのアイデアは、過去の経験を元にプロセスを構築する方法です。チケットをうまく利用する事で、プロジェクトに適したプロセスを構築できると思います。

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

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

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

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

古くから日本は米国に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というまでもなく、デプロイや運用までが自動化されたなら、多くの時間が上流に割かれる事になる。そんな未来があるかもしれない。そう思いました。

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

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

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

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


«BABYMETALに見るマネジメントの工夫