無料ブログはココログ

「深層学習の概要とドメインモデル」に参加してエモーションチップを考える

もっとも印象的だったのは、以下の言葉です。

適切に学習すれば、有限個のニューロンで任意の連続関数を近似できる
(universal approximation)

いつもお世話になっているIT勉強宴会で深層学習(ディープラーニング)のお話を聞いてきました(幹事の佐野さんが深層学習の概要とドメインモデル<第53回IT勉強宴会>に詳しくまとめられています)。ここでは、個人的な感想をまとめます。

ニューロンは判断するもの

深層学習の基本であるニューラルネットはは多層のニューロンから構成されます。このニューロンというのは「脳神経系における情報伝達を模した数学モデル」で、しきい値を超えると発火する、いわば入力に対する判断機構です。

ニューロンは20世紀からある技術で、ソフトウェア障害の有無などの判断をする論文などもありました。しかし、他の統計的手法がよく使われているのは、ご存じの通りです。

多層化による能力向上

その後、技術の発展や計算機能力の向上などでニューラルネットを多層化できる様になりました。ここで出てきたのが、初めに挙げた言葉です。

ニューロンを組み合わせれば何でも判断できる。そんな夢が広がりました。しかし、現実は厳しく、精度があまり上がりませんでした。

フレームワークの発展

近年の深層学習の話題を見ているとスゴいものばかりで、なぜだろうと思っていました。それらは、ニューラルネットの層に意味を持たせたり、途中で分岐したりと、より人間の脳に近づく事で精度が上がったそうです。

SF好きの私などは、より人間の脳に近づけばいつか人間の様に意識を持つのかと期待してしまいます。しかし、そこで障壁となるのが最初の言葉です。あくまで近似なのです。

機械学習あるいはデータ少尉の限界

新スタートレック(TNG)に出てくるデータ少尉を見ていると、機械学習の限界を感じさせます。人間と共に宇宙船の士官として働き、頭脳明晰、記憶や情報検索にすぐれ、技術を組み合わせた新しい提案や、過去の音楽家の味付けをして演奏する事が可能です。

しかし、友人がいても、悲しみや喜び、愛情を感じる事はありません。大切な人を失っても「何かが抜けたような」認識を持つだけです。仲間を作ったり、敵と戦うなど、本能的な能力が必要なのでしょう。

実はデータ少尉には兄がいてエモーションチップによる感情を持っています。しかし、性格が悪く失敗した様です。

おわりに

深層学習の発展によって人間の能力を超えるものが作られるかも知れません。しかし、それは人間が求めるゴールを実現するためのもので、ゴールを設定して深層学習の構造を作るのは人間です。

深層学習が話題になり出した頃、データを大量に突っ込めば答えを出してくれる様に勘違いしていました。でも、そんなうまい話は無く、良いものにするには人間の力が必要です。

エモーションチップが実現できるかどうかはわかりませんが、システムを作るのは常に人間です(今のところ)。ソフトウェアに関わるものとして、深層学習を野次馬的に眺めたり、変に恐れたりせず、ふさわしい場面があれば、ぜひ利用したいと思いました。

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

ランチェスターの法則にソフトウェア開発を学ぶ

はじめに

ランチェスターの法則(Wikipedia)はオペレーションズ・リサーチの数理モデルの一つで戦闘を2つのモデルで表現したものです。

この法則はランチェスター経営やグー・パー・チョキ理論などで知られていて、導入期などで力を一点に集中させる弱者戦略(グー)、 成長期の後半で多様な展開(ボリューム)で勝負する強者戦略(パー)、伸びが鈍化し衰退しだすと多様化を整理する(チョキ)。

ソフトウェア産業で考える

これはソフトウェア産業にもあてはまります。自分たちの立ち位置と世の中の情勢で戦略を考えます。

立ち位置は会社の規模ではありません。マーケットに対して強者であるか、弱者であるかの判断が必要です。

ソフトウェア産業は顧客の経営状況に影響を受けます。従来は新しい予算の切り替わるまでの期間が長く、半年から1年ほど遅れて影響が出ていました。

近年は世の中の情勢に応じて予算が変更される様になりましたので、これにあわせて利益重視(グー)、売り上げ重視(パー)、縮小(チョキ)を変更しないといけません。

参考:ランチェスターの法則と売り上げ、利益、利益率

ソフトウェア開発を考える

ソフトウェア開発においても同じような状況があります。プロジェクトの開始時期は、コミュニケーションや構成管理の基盤を作る、横展開の元になるひな形の開発し品質を向上させる、自動化を進めて手作業を減らす、など効率化を狙った施策を取ります(グー)。

やがて効率化の施策がすすむと、ガンガン開発するフェーズに入ります(パー)。しかし想定外の事象が起きた場合は見極めが必要です。

上司の視点で見ると、ついつい人を投入したくなると思いますが、状況をきちんと見極める必要があります。場合によっては戦略を転換して、必要に応じてスパイクやプロトタイピングといった「グー」戦略も必要でしょう。

ソフトウェア開発でも「チョキ」の戦略が最も難しいでしょう。プロジェクトが収束に向かう時、人を減らす必要もあるでしょう。あらかじめどのように引き継ぐか、誰を育てるかを考えて開発を進める必要があります。いわゆる「段取り8分」です。

参考:実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション -

状況を把握するには

いかにアンテナを張るかが重要です。顧客とのちょっとした会話が重要です。信頼を得て、関係を良好に保ち、時にはストレートに話して理解していただくと良いでしょう。

開発者の状況もよく見ておく必要があります。出勤時間や退勤時間、休み時間の過ごし方など、ちょっとしたことから、前向きに取り組めているか、負担になっていないか、を見極めます。

「現地現物」と言いますが、ほんの少しの時間であっても直に接して、状況を感じ取る事が重要です。

参考:[#TiDD] プロフェッショナルは本物で確認する

おわりに

ソフトウェア開発と戦略的な考え方は共通点があると思っていました。ランチェスターの法則を見直すと、そこにも戦略的な要素がありました。

グー・パー・チョキの分類はわかり易いので、今の状況を考える際にがどれに当てはまるか考えてみてください。色々と見えてくるかも知れません。

もし、上司がおかしいと思っても、それを愚痴のネタだけで終わらせないで下さい。あなたには、説得する、異動・降格を待つ、昇進して追い越す、転職する、といった選択肢があります。

ランチェスターの法則は様々なものに当てはめる事が可能です。現在のポジションと状況に応じて未来を選択してください。

参考:[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

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

口説くか、待つか、勧めるか、それとも聞くか - 求められる適性とオブジェクト指向 -

GWのタイムラインに気になるツイートが2つ流れてきました。

どちらも根本は同じで、「業務の違い」だと思っています。

口説くか、待つか、勧めるか、それとも聞くか

あなたに好きな女性がいたらどうしますか?

自分についてこいな人は口説くでしょう、女性に積極性を期待する人は待つでしょう、様子を見ていてあなたに必要なものはこれでしょうと理解者になろうとする人もいるでしょう。

でもさっぱりわからない不思議ちゃんには聞かないとわかりません。つきあい始めてもやっぱり不思議で、いつも聞いては理解を深める必要があるかも知れません。

実は

この話題、実はソフトウェア開発と同じだと思っています。パッケージなら口説くでしょうし、お客さんが主導権を持たいなら説明を待つでしょう。業務システムならある程度お客様のお話を聞いて提案するでしょう。

でも、組み込みの様に特殊な業務なら、納得いくまでとことん聞いて、設計するごとに発生する疑問もどんどん聞くでしょう。

もちろん開発者の個性もあると思いますが、業務によって開発スタイルが変わるのではないかと思っています。

オブジェクト指向前夜

オブジェクト指向の前の時代、いくつかの開発法がありました。

DB、データ構造、機能、状態遷移やシーケンスなど、どれを中心にするかは開発対象の業務によって違いました。それぞれに良し悪しがありましたので、適材適所で使われていました。

やがて、複雑で大規模なシステムの要求やWHATとHOWの断絶が少ないことからオブジェクト指向が注目される様になりました。

オブジェクト指向いろいろ

オブジェクト指向と言ってもモジュール化、モデリング、コードの効率や再利用性、記法など、それぞれの注目している視点で語られました。クラスとインスタンスの関係を表のカラム構成と行で説明している本もありました。

やがて、UML(統一モデリング言語)に記法が統一されほか、デザインパターンが登場しました。この頃にソフトウェア開発を始めた方は、これらこそがオブジェクト指向だと思われているかも知れませんね。

ということで

ソフトウェアの業務にあわせて色々な手法が生まれたのち、比較的オールマイティな言語としてオブジェクト指向が普及してきました。

オブジェクト指向には様々な技術が統合され、記法も統合されました。ある業務だけに注目すれば、全ての技術や記法は必要ありません。それぞれにふさわしいものを使えば良いと思います。

議論は尖った表現の方が盛り上がりますが、他を否定するよりは多様性を楽しみたいと思います。

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

考えろ、理解しろ、整理しろ

渡辺幸三さんのブログ:設計者の発言を読んでいて感じたこと。

日々の仕事をする中で口うるさいと思われても、年長者の務めなのできっかけを見つけては指導している。色々と言っているが、だいたい以下の3つに集約できるだろう。

考えろ

指示されたままに仕事をしたり、いつも通りで良いと思っていないだろうか。

渡辺さんの「論理削除」ではなく「無効化」をスタンプ属性や更新履歴テーブルの無駄っぽさを読んでいると、習慣ではなく考えて仕事をすることの重要性を感じる。

より良い方向を考えても、全体との調和の問題で実施できないかもしれない。しかし、きちんと考えてシステムを作り上げることはとても重要だ。次の仕事に活かせるからだ。

なぜかを理解しろ

学部の恩師の言葉で忘れられないのが「職人になるな勉強を続けなさい」という言葉(社内勉強会より社外の勉強会)。知っているだけではなく、きちんと理解していなければ技術者とは言えない。

人に聞いてわかったつもりで仕事に使い、うまくいったらそれでおしまい。それは技術者でも職人でもない。ただの人工(にんく)に過ぎない。

ものごとの原理は何なのか、その人はどうやって情報を知ったのか、広い目で深く理解していれば、自己流ではないより良い方法が選択できるだろう。

整理しろ

世の中のできる人を見ていると、常に考えて仕事をし、より深く理解しているだけでなく、情報を整理してコンパクトに理解している(できる人を観察して勝負する

得た知識はそのままにしておけば忘れてしまうし、量が増えれば大変になる。知識を活かしてステップアップするには、これまでの知識との関連を整理しておく必要がある。

体系化できていればすべてを覚えておく必要はない。どの資料に書いてあるかを知っていれば、いつでも確認できるからだ。経験のインデックスを作るのだ。

おわりに

世の中には新しい情報があふれているが、実は似たような議論を繰り返していることも多い。

渡辺さんの議論も、コードクローン(リンク先は阪大井上研)は全て悪か、より良いバランスはあるのか、と言う議論に見えなくもない(普及しているオープンソースには一定のコードクローンが存在するらしい)。このようにマッピングできるのは、ものごとを考え、理解し、整理しているからである。

ここに挙げた内容は技術者にとって基本的なことであるが、実践は難しい。自分のことはともかく、若者の可能性を信じて意見するのが年長者の務めだと思っている。

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


[#TiDD] ビジョンとコミットメントがチケット駆動開発を成功させる

Redmineを導入すれば問題は解決するのでしょうか?それだけではうまくいきません。では、チケット駆動開発を導入すれば良いのでしょうか?それだけでもうまくいきません。ビジョンとコミットメントがチケット駆動開発を成功させるのです!

うまくいく場合もある

いやいや、Redmineを入れるだけ、チケット駆動開発を導入するだけでうまくいく場合もあるでしょう。それは現状の問題が共通認識になっていて、ツール以外の問題やタスク管理以外の問題がない場合です。

たとえば、すでにアジャイル開発をしていて、拠点が分かれたのでタスクボードの代わりにRedmineを導入する場合など。あるいは、障害管理がうまくまわっている組織が新しい分野にチャレンジする場合に、気付いたことを効率よく共有できる様に補完型チケット駆動開発を導入する。といった場合です。

このように問題点が明確な場合は、チーム全体がチケットを中心にまわり、チケットで情報共有が進み、作業が効率化されます。

うなくいかない場合

反対にうまくいかない場合は以下のような状況がある様です。

  • 協力してくれない。チケットを行進してくれない。遅い
  • チケットと現状に差がある、適当。ごまかす
  • 期待した成果が出ない。勉強不足で効率が悪い

その背景には以下の問題が考えられます。

(1) 問題が共有されていない
そもそも何のためにRedmineやチケット駆動開発を導入するのか、目的がわかっていないのではないでしょうか。それがなぜ必要かもわからず、作業の負担増え、ただただやらされ感を感じさせているのではないでしょうか?

(2) 重要性が理解されていない
トレーサビリティやコミュニケーションの向上、あるいはデータ収集の効率化といった目的が共有されていても、その効果をフィードバックしていないなら徐々にいい加減になるでしょう。重要性を理解してもらうには、その効果を示す必要があります。

(3) 導入の段取りが悪い
ツールを導入する場合は新しい作業が負担にならない様に、レクチャーや指導が必要です。理解のないままに、いきなり高度な実施方法は負担が大きくなります。まずは障害管理から初めて、開発の道具になってからタスクの管理をはじめると良いでしょう。

違いはビジョンとコミットメント

コマンドコントロールにしろ、支援型のリーダーシップにしろ、新しい環境を導入する際にやらないといけないことは変わりません。それは、どのような改善がもたらされるか、ビジョンを示すことです。

状況によって、始まりは指示なのかお願いなのかわかりません。しかし、長く継続させるには、そのビジョンは理想のままではなく、結果で示さないといけません。

開発者が効果を実感できるか、明確なフィードバックがなければ、それは余分な作業が増えただけです。

フィードバックは定量的でなくても構いません。「障害対応が早くなったような気がする」「管理作業が楽になった」という感想が聞ければ、それは無駄な作業ではなくなります。前向きな協力が得られるかも知れません。

そして、何よりもコミットメントを得る事が大切です。やらされ感だけの作業は、いい加減になりがちです。

無理な導入は行わず、必要な教育を実施した上で、開発者にメリットのあるところから段階的に実施します。そして、その後も支援や適切なフィードバックを行いましょう。

まとめ

Redmineやチケット駆動開発に限らず、これまでのプロセスを変更する際にはリーダーシップが求められます。それが如何に大切なことであるかビジョンを示し、理解を得ないといけません。

それはソフトウェアを作る場合と同じです。はじめに必要な勉強をした上で、必要に応じて修正やフィードバックを行いながら、より良いプロセスを作り上げていきます。

ゴールの達成にはリーダーは余計なプライドを捨て、チームに期待して、何でもしないといけません。チームを支援することが、リーダーの仕事をセクシーにするのです。

参考:

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ピグマリオン効果とリーダーシップとリーダーの心理 - マンガで分かる心療内科14 -

リーダーはショットガン・アクションでボトルネックをなくせ! - マンガで分かる心療内科14 その2 -

求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

支援者としてのリーダー - 「リーダーシップ3.0」を読んで -

チームを守り育てる - セクシーな中間管理職 -

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


リーダーはショットガン・アクションでボトルネックをなくせ! - マンガで分かる心療内科14 その2 -

マンガで分かる心療内科14巻を読んでいると、前回のピグマリオン効果以外にも色々と考えさせられます。特に時間に関する内容は心療内科というよりは戦略の話じゃないかと思いましたが、感情に振り回されずに合理的な選択をするということなのでしょう。

なぜリーダーはボトルネックになり易いか

リーダーは単一障害点(SPOF)ですし、複数人で並列に処理することも難しいです。しかも責任重大です。ついつい感情的になったり、落ち込んだり、悩んだりしてしまいます。

これに対して、 怒りを感じた時は6秒数えろ(13巻の引用)、反省も6秒まで、成功したいなら全部やれ、といった内容が参考になります。前2つは感情にとらわれるのではなく、前向きになるべし、時は金なりということでしょう。

3番目の「成功したいなら全部やれ」は下手な考え休むに似たりとでもいうべき方法で、ショット・ガンアクションとして紹介されています。

ショットガン・アクション

「成功したいなら全部やれ」のマンガは著者の病院のサイトで読むことができます。簡単に説明すると、問題点を人のせいにするのではなく自分の責任ととらえて、できることは全部やるべし。普通の銃では外れてもショットガンならあたる。大きな成功は小さな成功の積み重ねだとされています。

ボトルネックになっているリーダーを見ていると、野獣が現れてどうやって倒そうかと考えているうちにたくさんの野獣に囲まれ、それでも普通のピストルで1頭ずつ倒そうと躍起になっているように思えます。

とはいえ、本当になんでも実施すれば良いかと言うと、そうでもないでしょう。 ショットガン・アクションから学ぶべきは、考えを制限しない、考えすぎないということで、さらに無駄にしないという考え方が必要だと思います。

考えを制限しない

責任感が強いのか、プライドが高いのか、とにかく自分で解決しようとするリーダーがいます。でも、どんな解決法でも誰かが先にやっていたり、何かを参考にしたのですから、恥ずかしがらずに色々な人に相談すべきだと思います。そして、どうやってそれを学んだかを聞いておくことが、今後成長する助けになるでしょう。

部下、協力会社、あるいは顧客など、その立場に関係なくステークホルダー(利害関係者)は基本的にプロジェクトの成功を願っています。恥ずかしいとか、かっこわるいとか、今更聞けないなどと考えずに協力してもらえば良いと思います。格好つけてプロジェクトが失敗することほど恰好悪いことはありません。

考えすぎない

時間は限られているのに悩んでいる暇はありません。調整や根回しが必要なら電話でもメールでもなんでも利用できます。

計画など検討に時間が必要なら、期限を決めて考えるとよいでしょう。ボトルネックがあって難しいなら、ほかの人に相談したり、打診すると良いでしょう。

無駄にしない

マンガでは何でもかんでもやれば良い様にも読めますが、個人ではないのでプロジェクト全体を考えて実施しないとまずいでしょう。実施が遅れることによるリスク、手戻りが生じるリスクや戻れなくなるリスク、を考えて実施順序を決める必要があります。

順序は合理的に決めないといけません。妙なこだわりや単にやり易いという理由ではなく、リスクを考慮して無駄がないように実施すればうまくいくでしょう。

まとめ

ショットガン・アクションをヒントにリーダーのボトルネックを無くす方法を整理しました。その方法は心理学的というよりは、心理的な罠に落ち入らない方法です。

リーダーに限らず、人の可能性を制限するのは自分自身です。心理的な罠に落ち入らないで合理的な判断ができれば、より良い方向に向かうでしょう。

結局のところ、「ゴールのためなら何でもする」という気持ちを持つことが、リーダーに求められているのです。

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


求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

なぜリーダーシップやプロセスのことに興味があるかを考えると、自分がうまくいったと思えるプロジェクトを説明したいからです。そんなモデルとして今回は、書籍「リーダーシップ3.0」にも載っていた羊飼い型リーダーシップを考えてみたいと思います。

とはいえ、昔からこのような仕事のやり方をしているかと言うと、必ずしもそうではありません。昔はどちらかと言うと外科医チーム的に隅々に目を行き渡らせてコマンドコントロールしていたように思います。しかし、様々な状況に合わせていくうちに羊飼い型リーダーシップにたどり着いたのです。

コマンドコントロールの限界:規模

実際のところ、うまくいく場合はコマンドコントロールの方が楽です。リーダが概ね予想できる時は、細かなところまで指示できますので、それを管理すれば良いからです。

しかし、規模が大きくなってくると一人では管理できません。そこで、サブチームに分けて、それぞれのサブリーダーに自分の代わりにコマンドコントロールを任せることになります。

こうなるとコマンドコントロールの良さは少なくなります。コマンドコントロールはリーダーの判断で直接コントロールできる機敏さがメリットだったのに、各チーム間で調整が必要になって、全体の動きが鈍くなるからです。

コマンドコントロールの限界:変化

また、あまりにも変化が激しい場合、コマンドコントロールには限界があります。リーダーによってコントロールされるので、リーダーの判断がチームの判断になるからです。

そこで、チャレンジングな仕事の場合は手分けをして調査をする必要がありますが、それをうまく集約できないとリーダーは判断できなくなります。

効率化するには権限を委譲して一定の判断をしてもらってから集約することになるのですが、ビジョンが明確でないとバラバラな結論になってしまいます。

コマンドコントロールの限界:カリスマ性

そこで、全体を調和させる目的でカリスマ性が求められます。その分野に長けた人がビジョンを示すことで、全体に一貫性を持たせるのです。

この方法はカリスマ的に活動できる間はうまくいくでしょう。成功のポイントは中長期の社会の変化に対して、適切に情報収集して対応できるかどうかということになります。

カリスマ性を発揮して豪腕を発揮すればするほど、下の人間は従順になりがちです。反対意見が通りにくいので意見が上がりにくくなり、世の中の変化に対応できなくなる可能性があります。

求められるリーダー像

ここまでの流れを考えると、リーダーがボトルネックになっていることがわかります。リーダーは負担を減らし、方向性を示すと共に、意見を集約しないといけません。

もちろん、規模や先進性、社会の動向などによって求められるリーダーシップ像は異なります。しかし、小規模で多機能なソフトウェアを技術の進歩が激しい基盤上で、社会の変化に対応させるには、従来のコマンドコントロールは難しくなっています。

そこで、求められるリーダーシップは以下のようなものです。

  • 権限を委譲して自律的な行動を促す
  • ビジョンを示してチームを導く
  • 意見を出し易くしてコミュニケーションをはかる

これは、経験的にうまくいくと思っています。ボトルネックになることなく、リーダーの能力を超えたプロジェクトを成功に導きます。そして、サーバントは革命の言葉。ビジョンを示せ! - サーバントリーダシップ私論 -に書いた様に、自分の思い通りのソフトウェアではありませんが、自分も含めてチームの持てる力を最大限に発揮して、大きな喜びが得られます。

これまで、このようなリーダーシップはサーバントリーダーシップだけだと思っていました。しかし、羊飼い型リーダーシップがより説明が容易だと思います。

羊飼い型リーダーシップ

羊飼いは羊を飼う仕事です。羊の群れをえさ場に連れて行ったり、柵の中に入れるには群れになる習性を利用して、先頭になる羊を後ろから行かせたい方向に導きます。

羊飼いは前面に立つことは少ないですが、その行動は積極的です。危険な状況では、杖で羊をつついたりもしますし(リーダーは背後から指揮をとり、 「集合天才」を活用せよ:要無料登録)、一人で導くことが難しい場合は、牧羊犬にあたるコンサルなども使います。

(羊飼い型リーダーシップの説明では書かれていませんが、実際の羊飼いは餌を持って先導することもある様です。なんでもするということでしょう。)

羊と羊飼い

羊というのは恐がりでまとまって行動しますが、山羊は行動的で木に登って樹皮を食べたりします。そのためか終末論では、神様が良い羊と悪い山羊に分けると言われています。

また善き羊飼いというたとえがあって、1匹の羊がはぐれたら、99匹の羊を置いて、命がけでその1匹を探し出すとされています。(参考:Wikipedia

つまり、羊飼い型リーダーシップには、性善説に基づいて、一人一人と向き合って導くイメージが暗黙のうちにあると思います。

おわりに

書籍「リーダーシップ3.0」(支援者としてのリーダー - 「リーダーシップ3.0」を読んで -)に示されている歴史を自分なりに書きました。この業界に入って以来、ソフトウェアはドンドン複雑に、かつ、小規模になり、技術や社会の変化も激しくなりました。そのような変化に対応できるのは、ビジョンを見据えつつも各人が成長し、それぞれの能力を最大限に発揮できる組織です。

羊飼い型リーダーシップは、チームにビジョンを示しつつ後方から導きます。チームが成長する様に支援するだけでなく、危険な状況では様々な手段を講じて羊を守ります。チームはビジョンと自律的な行動によって、ゴールを達成できるでしょう。

以前、サーバントの歴史を追いました(古くて新しいサーバントリーダシップ)が、羊飼いはなんと紀元前5000年からある様です。7000年間熟成されたリーダーシップが、きっと新しい時代を切り開いてくれると思います。

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


[#TiDD] チケット駆動開発のパタンランゲージを作りたい

あけましておめでとうございます。年初にあたって夢を書きたいと思います。

モチベーション

2009年からチケット駆動開発のブログ記事を書いていますが、未だに具体的な実施方法を体系的にお話ができません。

もちろん [#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」 の様な概念的なお話はできますし、書籍チケット駆動開発に書いたようなプロジェクトの状況にあわせたテーラリングの方法などは説明できます。

しかし、アジャイル開発ではタスクカードをチケットにするとか、ウォータフォール開発ではWBSをチケットにしたり、備忘録としてチケットを使う、というようにベースのプロセスが必要です。

このため、チケット駆動開発を実施するには、現状の問題点を明らかにした上で、その現場にふさわしい実施方法を決める必要がありました。

標準化の問題点

普通に考えれば、成功したプロジェクトを参考に標準プロセスを定める事になるでしょう。標準化すれば、そのプロセスを理解して、過去の問題を改善し、管理し、ツールによる実行や支援が可能になるでしょう。

その反面、教条主義に落ち入り易く、チームは考える事をやめて、ルールを守る事がゴールになってしまいます。底上げはできるものの、目指すべき自分たちで考えて改善する文化を育てにくくなってしまいます。

チケット駆動開発にはたくさんの利用方法があり、様々な問題が解決可能です。多くの人たちが、自分たちで考えて、工夫する事で、開発をよりよいものにしているのです。固定化を目的とした標準化はちょっと違う様に思いました。

プラクティスだけでもない

そこで、過去の経験に基づいてプラクティスを集めれば良いと考えました。“No ticket, No commit!”のようなプラクティスを揃えておけば、それらを組み合わせてソフトウェア開発が実践できるからです。

チケット駆動開発のプラクティスが示されることで、議論が容易になりました。「 “No ticket, No commit!”は実施してますが、 “No ticket, No work!”は実施していません。」といった感じです。

しかし、共通化してパターンを抜き出したものは参考になるものの、どのように自分たちのプロセスを構成すれば良いかは現場の工夫に任されたままでした。

パタンランゲージに期待するもの

そこで、パタンランゲージなら標準化と多様性のバランスが取れるのではないかと期待しています。

パターンというとあたり前の繰り返しの様に考えてしまいますが、心からの良い変革を示します(美しさは変化の中にある - パタンランゲージ - #agileto2015)。単調な建物が延々と並んでいると飽きてしまいますが、途中に講演があり、並木があり、木漏れ日があったなら、良い心地がするでしょう。そのような変革です。

それは単独で存在するのではなく、様々なレベルのパターンがあり、それらが組み合わさって、心地よい風景を表すものです。([#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -)。

このようにパタンランゲージがランゲージであるのは、心に響く様々な言葉を紡ぎ合わせて良い小説が構成される様に、様々な心地よいパタンを組み合わせて、全体が構成されるからです。

プロジェクトが始まろうとするとき、様々なイメージをするでしょう。ソフトウェアの事、お客様とのやり取り、チーム作り、メンバー間の情報共有、などなど、様々な視点と様々なレベルでプロジェクトを考えて、プロジェクトの準備を進めていきます。

単なるプラクティスとしてチケット駆動開発を利用するのではなく、心地よい変革としてチケット駆動開発を様々なレベルで取り入れ、それらをうまくつなぎ合わせる事でプロセスを構成していく。そんなことをはじめていきたいと思っています。

参考リンク

[#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである -
[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -
[#TiDD] プロセスプログラミング3(改) - ファシリテーション -
[#TiDD] プロセスプログラミング4 - チケット駆動開発 -

標準化のトレードオフ その1 -  標準化のパターン -

標準化のトレードオフ その2 - 本当に狼男ですか? -
標準化のトレードオフ その3 - 応用のできない習熟 -
標準化のトレードオフ その4 - 慣性の法則 -
標準化のトレードオフ その5 - 従来法と改善 -
標準化のトレードオフ その6 - スクラムの形式知が大切な理由 -
標準化のトレードオフ その7 - リーンソフトウェア開発の考える仕組み -
[#TiDD] 標準化のトレードオフ その8 - チケット駆動開発はソリューションライブラリ -

[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性
[#TiDD] プロセスモデリングの課題からチケット駆動開発を考える - きょうわたしたちに救い主が生まれた -
[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -
[#TiDD] チケット駆動開発の3要素
[#TiDD] アダプタブルな開発を実現するチケット駆動の3要素

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


[#プロセスプログラミング] 探索アルゴリズムとソフトウェア開発

アルゴリズムという言葉を初めて聞いたのは高校のとき、物理の先生と「図書館のレイアウト変更とか大変そうですね」と雑談していると「わしらは大学でアルゴリズムを学んだから効率よくできる」と言われていました。

オスターワイル(Leon J. Osterweil)氏が「ソフトウェアプロセスもソフトウェアである」とプロセスプログラミングを提唱して、ソフトウェア工学が大きく進歩しました。しかし、そもそもアルゴリズムは、現実世界の問題の解決法だったのです。

今回は探索アルゴリズムを基にソフトウェア開発を考えてみたいと思います。

ソフトウェア開発の可能性を探索する

ソフトウェアの実現方法には様々な可能性があり、開発を決めた時点をルートととし、実現する機能を横方向に、下に行くほど具体化する木構造で表す事ができるでしょう。

ソフトウェアの可能性を示す木構造からどのような実現方法が良いか探索するには、2つの基本的なアルゴリズムがあります。幅優先探索(Wikipedia)と深さ優先探索(Wikipedia)です。

幅優先探索は従来(ウォータフォール)型開発の他、アジャイル開発の初期に行われるアーキテクチャの決定、ストーリーの抽出、イテレーション0など、イテレーティブな開発にあたります。

深さ優先探索はアジャイル開発のような反復開発に置けるインクリメンタルな開発にあたり、機能やストーリー毎に実現していきます。

これらの2つの方法は木構造全体を探索する場合の効率は同じですが、途中で最適解が見つかる場合は深さ優先探索の方が効率的だと言われています。ウォータフォール型開発とアジャイル開発の関係ですね。

ボードゲームの判断

より効率的な探索法を参考に、効率的にソフトウェア開発する方法を考えてみます。

オセロのようなボードゲームでは状態の組合せが多いので、全ての手を計算して最適な答えを得る事が難しいとされています(すくなくとも昔は、、)。

次の手は一定時間内に打たないといけませんので、時間内に全数を探索できるような局面までは探索する手数を限定した上で、なるべく効率的に探索します。効率的な探索法としてアルファベータ法(何もないから何かみつかる: オセロゲーム開発 ~アルファベータ法(alpha-beta search)~)が有名です。

具体的には、今後の展開を時間内で計算可能な木構造で表現しておき、かどのマスを狙う、数を狙う、など局面に応じた評価関数に基づいて、負けそうな枝を削除(いわゆる枝刈り)して、より有効と思われる方法を実施します。

ここまでのアルゴリズムから学べる事は、全てを探索しない場合は幅優先探索よりも深さ優先の方が効率的と言われているものの、一定時間内に結果を得るには深みに入らない、局面に応じて判断や枝刈りをする、必要があるという事です。

では、ソフトウェア開発に当てはめて考えてみましょう。

深みに入らない

全体に影響を与えそうなアーキテクチャの決定や技術的な課題は早めに見通しを立てるべきです。深みに入らない様にプロトタイプやスパイクと呼ばれる技術検証を実施します。

少なくとも最低限価値が提供可能なMVP(minimum viable product)に至る重要成功要因(Critical Success Factor:IT用語辞典)の技術的課題は、確認しておくべきでしょう。

もちろん、従来型の開発におけるマイルストーン、アジャイル開発ではイテレーションのタイムボックスが守れるなら、正式な開発を実施する事も可能です。ユーザビリティの確認などがそれにあたります。ただし、全体に影響を当てる課題が残らない場合です。

局面に応じて判断や枝刈りをする

ゲームの評価関数は局面によって変わります。ソフトウェア開発においても、完了までの期間や業務、体制、使用する環境によって、判断を変えないといけません。

とはいえ、ゲームにおいてのゴールが、最終的なコマの数や王将の獲得など、局面によって変わらないように、ソフトウェア開発においても価値のある動くソフトウェアの実現である事は変わりません。そのゴールに至る可能性を高める、逆に言うとゴールを達成できないリスクを下げる判断が局面によって変わるのです。

ある事を実施するなら、その時間分だけ他の作業ができません。実現可能性が高まる様に、実施するリスクと実施しないリスク、ある方法と別の方法のリスクを見極めて、ゴールに向けてリスクが低減する様に判断や枝刈りをすべきでしょう。

つまり、その時点、その時点で、残りの工数と実施しない作業を考慮して、それぞれのリスクに対してどこまでリスク低減のための作業を深くまで実施して良いかを考えます。

木を小さくする

このようにプロジェクトの初期は難しい対応が求められます。これをより簡単にするには、自由度を下げて木を低くする、コードを減らして木を小さくするという方法があります。

自由度を下げる方法の一つは、いわゆる標準化です。確立された技術を用いる事で、考えないといけない事を減らします。お客様から与えられる制約も同じ様に自由度を減らして、検討する内容を減らす事ができます。

コードを減らせば実装範囲がへりますので、 木を小さくできます。ライブラリやフレームワーク、ミドルウェア、などが考えられます。もちろん、初めて利用する際は技術的な検証が欠かせません。

プロセスの特性も忘れずに

探索アルゴリズムで考えるとソフトウェア開発のポイントをうまく説明できますが、プロセスの特性も忘れてはいけません。プロセスを実行するのは人間ですので、情報や知識の共有、技術の習熟に時間がかかります。

開発中に得られた情報や知識は、その人数によって対面、レクチャ、文書などふさわしい方法で効率的に伝える必要があります。伝える人数は全体の規模のほか、増員タイミングや担当の割り当てなどによって変わります。

また、技術の習熟の考慮も必要です。顧客・開発者・技術共に経験者ばかりなら1度だけのリリースでもうまくいく可能性もあるかも知れません。しかし、未経験者や初めての要素があるなら、経験値が向上する様に複数回のリリースも検討すべきでしょう。

まとめ

探索アルゴリズムを基にソフトウェア開発プロセスを考えてみました。ソフトウェア開発は、業務、ソフトウェア、環境、納期、チームの構成、など、様々な要素の組合せがあり、ゲームで用いられる探索アルゴリズムも参考になるでしょう。

いわゆる90%シンドロームや動かないコンピュータなど、古くから語られる失敗プロジェクトは、 プロセスをきちんとプログラミングできないことから生じています。

たとえば進捗を管理しているから大丈夫と思っていても、リスクがコントロールされていなければうまくいきません。見た目の進捗を求めて、わかるところだけ深く探索しているかもしれないからです。

プロジェクト管理者に求められるプロセスプログラミングは、簡単ではありません。様々な要素を考慮しつつ、プロジェクトに関わる人たちが不幸にならない様に、より良い方向に導くセクシーな仕事なのです(参考:チームを守り育てる - セクシーな中間管理職 -)。

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


反復型開発の混乱 - Iterative and Incremental あるいは 繰り返し -

「反復型開発」混乱しやすい言葉です。

言葉の定義

「ああ、あの本ね」という方もおられるでしょう。Wikipediaによれば

反復型開発(はんぷくがたかいはつ、Iterative and Incremental Development)とは、より古典的なウォーターフォール・モデルの弱点を克服すべく開発されたソフトウェア開発工程の手法。反復型開発の中でもRADとDSDMは良く知られたフレームワークである。反復型開発はエクストリーム・プログラミングや他のアジャイルソフトウェア開発フレームワークの基本的要素でもある。

とされています。「えっ」と思われた方もおられるでしょう。混乱する理由には3つあり、順に説明します。

2つの言葉を1語で表す

反復型と言いながら、Iterative and Incrementalと2つの言葉を表しています。Iterativeだけでも、Incrementalだけでもありません。まず、これが混乱の元になっています。

広い定義と狭い定義がある

情報マネジメント用語辞典によると「狭義にはアジャイル開発と区別されるが、広義には含まれる。」とされています。狭義ではアジャイル開発以前の反復型開発を示すので、「アジャイル開発と反復開発の落とし穴 (1/3) - @IT」といった表現も成立してしまいます。

繰り返し型開発ともいう

スパイラルモデルのような反復型開発は「繰り返し型開発」と呼ばれることもあります。たとえばIPAの非ウォーターフォール型開発WG活動報告書(PDF)には「アジャイル以前の繰り返し型開発を、IID(Incremental and Iterative Development)と総称することもある」と書かれています(個人的にはこちらの方が聞き慣れています)。

おわりに

翻訳による混乱はfault (原因)とfailure(結果)が 欠陥と障害だったり、その逆に訳されるなど、昔からあって注意が必要です。反復型開発に関しては上に挙げた3つの混乱があるので、特に注意して使いたいと思います。

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


より以前の記事一覧