無料ブログはココログ

« 2015年10月 | トップページ | 2015年12月 »

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

redmine.tokyo 第9回勉強会で発表させていただきました。

今回の勉強会は入門的な内容だったこともあり、80名を超える方に参加していただけました。そのうち初めての方の比率が高く、懇親会には約1/3の方が参加されました。

以前、Redmineはキャズムを超える - redmine.tokyoに参加して -と書きましたが、本当に裾野が広がってきた様に思います。

これまではRedmineの利用方法にはAsIsとToBeの2つのの進め方があると説明してきましたが、講演をしていると導入時点で失敗している相談を受ける事が多くありました。そこで、プロセス改善やPDCAサイクルと管理者・開発者の利益の視点から導入方法のヒントを説明しました。

うなずいてくださる方も多かったのですが、Tweetでの反応で予想外のものもありました。「ピンチはチャンス」というタイトルでプロジェクトが大変でどうしようもない時に導入すると良いと説明したのですが、「無理だ」という反応がありました。

プロセス改善は効果が見込めるから実施するもので、効果がないなら導入してはいけません。みんなが頑張る方が効率的に乗り切れるなら、そうすべきです。

ピンチのときにチケット駆動開発をして効果があるのは、何をすべきか見えていないので気付いた事を共有するとか、混乱の原因がコミュニケーションや情報共有にある場合です。そのような問題をチーム全体で共有して、負担よりもメリットが大きい場合のみ導入すべきです。

そのような注意書きがなかったので、嫌な経験をした方には納得できなかったのでしょう(もし、私の過去の発表がきっかけになっていたらごめんなさい)。

なお、スライド中で参照している乗松さんのスライドのPDFはここ(Jaspic)です。

追加でお話しした日本Redmineユーザグループ発起人会のスライドのPDFはここに置きました。

これまでも東京はredmine.tokyoと大阪にはRxTstudyというコミュニティがありましたが、日本全体のユーザの場をつくりたいと思っています。Facebookのグループや、地方での普及協力、開発者への支援など夢は広がりますが、先ずは有志で集まりませんか?というお話をしました。

ご興味のある方はPDFをご覧の上、Twitter (@sakaba37) などでご連絡ください。

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


反復型開発の混乱 - 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つの混乱があるので、特に注意して使いたいと思います。

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


AWSの不気味さとDDDブーム

AWSが破壊的に成長しているというのは、誰もが認めるところです。こんな記事もありましたね。

アマゾンのドル箱となったAWSがこれほど破壊的である理由 http://japan.zdnet.com/article/35072527/

しかし、もっと大きな、不気味な流れを感じるのは私だけでしょうか?

エコシステムとしてのAWS

AWSの初期は、初期コストに注目されました。規模の予想が難しいビジネスの立ち上げ時に、過剰な初期コストを必要とせず、必要に応じて規模の拡大ができると、スモールスタートの施策の一つとして注目されました。

このようなスケールの自由度は、年度末やキャンペーンCMの時だけ増大する様な業務に置いても好都合でした。ピーク時だけサーバの数を増やせば良いからです。

また、運用コストの面でも注目されました。一定のサービスレベルを維持するにはそれなりのコストが必要でしたが、アプリ用サーバだけでなくDBサーバも運用付きで切り売りしてもらえるので、低コストの運用が可能です。

技術基盤としてのAWS

AWSには、システムのアーキテクチャを構成する技術的な基盤があります。ネットワーク周りだけでなく、分散処理や機会学習、KVS、キュー、DevOpsなど、自分たちで導入するには、技術や運用の評価が必要なものです。

このようにAWSでサポートされるものは、顧客のニーズもあるでしょうが、アマゾンの本業で必要とされる最先端の技術という側面があります。アマゾン自信でドッグフーディングされた技術基盤なので、安心して導入できます(安心しすぎると危ないですが、、)。

ソフト産業をフルマネージドサービスで浸食するAWS

AWSを不気味に思うのは、AWSがアマゾンの本業でない点です。自分たちが使っているものをお裾分けしているだけなので、AWSのユーザがどのようなビジネスをしていようと良いものなら出してくる事です。

Lambdaが出てきた時はCPUの時間貸しをイメージしていましたが、どうも違う様です。アマゾンの運用の最適化を進めていたら、便利なものができたので公開しているようです。最近では定期処理やS3に置いたファイルの種類に合わせて処理をするという事が、設定だけでできてしまいます。

勉強会ではインフラエンジニアの方がAPI Gatewayで仕事がなくなると言われていましたが、ソフトウェア開発の分野もどんどん浸食されている様です。しかも、フルマネージドサービスの中にバージョンの概念なども加えられ、これまでの自動化で学んだ内容がそのままでは活かせなくなりそうです。

SOAとマイクロサービスを複合設計に当てはめると見えるもので書いた複合設計の分割法にAWSを当てはめると、上位のトランザクション分割の部分がAPI GatewayやS3-Lambdaで埋められた感じです。

共通処理は順次増えていて、あとは処理の中心のSTS(源泉、変換、吸収)の部分だけです。しかもSTSのSの部分、プログラムのつなぎになるキューやストレージはすでにあります。

最近ではサーバだけでなく、スマホの開発の支援やテストの支援まで簡単にできる様になっています。残るマーケットはどこなのかと思ってしまいます。

オープン&汎用な世界からハイブリッド&個別な世界へ

アジャイル開発が注目されて「SIerオワコン」などと言われても、マーケットの比率が変わるだけだと気にも留めませんでした。しかし、AWSによる技術革新と市場の縮小は恐怖さえ覚えます。

ホストによる集中・寡占の時代から分散・オープン&汎用の流れの中で多数のフレームワークが登場し、アルゴリズムを力づくで開発する産業からシステムアーキテクチャと面倒臭い仕事を多人数で行う産業になりました。

しかしAWSやその他のSaaSなどクラウドの発展によって「オープン&汎用な世界」から、さらに「ハイブリッド&個別な世界」に移ろうとしている様に思えます。

クラウド業者が汎用的な部分を担う事で、これまでのボリュームに頼る仕事は少なくなるでしょう。そして、オープンな技術を使いつつもクラウドにロックインされて、ソフトウェア開発は個別要件の実装しか残らないのではないかと思います。

最近、DDDがブームになっている様です。その背景にはこのような流れが影響しているのではないかと思いました。

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


リーダーはゴールのためなら何でもする - ドクター先輩の個人指導 -

後輩:すると、メンバーを注意してはいけないと?

ドクター先輩
:そうは言っておらん。感情的に怒るなと言っておる。そもそもうまくいかなかったのはプロセス問題があったからじゃ。

後輩:プロセス問題ですか?

ドクター先輩:そうじゃ、プロジェクトがおかしくなってしまったのではなく、リーダーがおかしくしてしまったのじゃ。ふりかえってみるが良い。リリースまでにチェックはしていたのか?指導はしていたのか?作業の確認はしておったのか?

後輩:リーダーにも反省点があったのですね。

ドクター先輩:そうじゃ、「怒るな教えろ」じゃ。

後輩:何度言っても直らない場合でもですか?

ドクター先輩:そうじゃ、自分の気持ちは関係ない。受け入れやすい様にするのじゃ。変な誤解を与えられたり(田中一夫さんを偲ぶ)、嫌みを言われなければ怒る必要はないのじゃ。

後輩:リーダーは大変な仕事なのですね。

ドクター先輩:そうじゃ、リーダーはゴールのためなら何でもするのじゃ。

後輩:具体的にはどのように行動するのですか?

ドクター先輩:常にチームが最大の能力を発揮できる様に行動するのじゃ。感情に任せて怒っても反発するだけじゃが、教育的な視点で指導すれば、より能力を発揮できるじゃろ。

後輩:なるほど。他にはどういうところに注意すれば良いのでしょう?

ドクター先輩:リーダー自身がボトルネックにならないことじゃ。リーダーは情報の入り口じゃから、リーダーがまわらなくなるとプロジェクト全体が止まるのじゃ。

後輩:でも、みんな頑張って残業していますよ。

ドクター先輩: 何を言っておる!表面的な事だけを見てはいかんのじゃ。進捗は止まっておるじゃろ。手戻り作業が多すぎないか?仕様変更が伝わってない、レビューやテスト方法を先に伝えていないなど、そこにもプロセス問題が多発しているじゃろ。

後輩:なるほど、リーダーがボトルネックになって、プロセス問題が色々と起きていたのですね。

ドクター先輩:そうじゃ、 無駄にする時間などないのじゃ。リーダーは 自分のスタイルを押し通す余裕はもちろんの事、 迷って判断を遅らせる暇や、メンバーを怒って落ち込ませる暇などないのじゃ。問題を常に整理してゴールに向けて、必要な事はなんでもするのじゃ。

参考:セレンディピティを阻害する3要素=リーダの成長を阻害する3要素

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

セレンディピティを阻害する3要素=リーダの成長を阻害する3要素

セレンディピティとは「偶然からモノを見つけ出す能力」「当てにしないしていないものを偶然にうまく発見する能力」あるいは「偶然または聡明さによって、予期しない幸運に出会う能力」などと呼ばれます。

セレンディピティに注目した理由

ノーベル賞を取るような大発明をした多くの人は目的としない事象、すなわち失敗の中から大きな発見をしています。このような発見は、セレンディピティを発揮したからと考えられます。

セレンディピティの語源は「スリランカ(セレンディップ)の3人の王子たち」という寓話から来ています(詳しくはリンク先をお読みください)。また、同名の映画「セレンディピティ」(Yahoo!映画)では、初めての出会いから偶然をたぐり寄せて再会に至るまでの様子が描かれています。

セレンディピティについて書こうと思ったのは、プロジェクトの運営がうまくいかない人の問題は戦略(効果的に対策を打つための5つの戦略)の問題だと思っていましたが、実際は現状を洞察できない、つまり想定外のことから問題点という宝物を発見できず、戦略的に考えられないのではないかと思ったからです。

リーダの成長を阻害する3要素=セレンディピティを阻害する3要素

そこで、なぜ現状を洞察できないかを考えてみました。すると、それはセレンディピティを阻害する内容そのもので、そのことによってリーダの成長をも阻害しているようでした。

散らかっている

トヨタ生産方式の基本は整理整頓と言います。これは、チリ一つない状況であれば、ネジが落ちていればすぐにわかるからです。

これと同じ様にわからない情報がたくさんある中でそれをを放置していたなら、普通じゃない(異常な)状況になっても、問題がどこにあるかわからなくなってしまいます。

できる人を観察して勝負するに書いた様に常に情報を整理しておけば、問題が起きればすぐに発見する事ができるでしょう(計算量でも説明できますね)。

興味がない

もし、イヤイヤやっているならプロジェクトの現状に興味が持てません。こんなもんだと思ってしまうでしょう。

また、少し気になったとしても、その内容にまでは踏み込まないでしょう。プロフェッショナルは本物で確認するに書いた様に、常に興味を持って状況を把握するようにしたなら、問題点を具体的に知る事ができるでしょう。

別のものにこだわっている

仕事のやり方はどんどん改善すれば良いのですが、自分のスタイル、いわゆる俺流にこだわっていると、目の前にあるヒントを活かせません。こだわる場合とこだわらない場合の注意点に書いた様に、ピンポイントでこだわるとうまくいきません。

また、恥ずかしがって聞かない人も、自分のプライドにこだわっているのでしょう。情報を得るには Give & Giveなのですから、積極的に情報発信しないと情報を得る事はできません。

おわりに

ここに挙げた内容は、偶然の中から幸運を見つけ出す場合にも、あるいは、問題点を見いだす場合にも共通の内容です。

問題を見つけだすことができれば、戦略的に攻略できます。ピンチはチャンスと言いますから、きっと幸せな出来事も見つける事ができるでしょう。

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


[#benkyoenkai] DDD(ドメイン駆動設計)と道具と他流試合

「すっきりしました。今まで学んできた事が一つになりました!」と言ったのは、今や同僚のSさん。分厚い見た目に負けて読めなかったDDD本を読んでみたいと言われたのでお貸しして、感想を聞きました(いわゆる手抜き)。

言ってる事は理解できたのですが、これまでいくつものDDDの講演を聞いた中でそのようなイメージを抱く事がなかったので、「そんな感想もあるんですね」と思っていました。

今回、IT勉強宴会で杉本さんの講演を聞いて、ようやくイメージがわきました。

共に開発するDDD

杉本さんによれば、“ドメイン駆動設計(※)とは、オブジェクト指向ベースの知識体系を受け入れつつも、エンジニアの関心を、プログラムのテクニカルな構造に留まらず情報処理モデルそれ自体の構築に向けようとする試みである(私見)”とのこと。「これだ!」と思いました。

アジャイル開発には、似ている言葉がたくさんありました。

これらはソフトウェア開発に必要なある一面を示していましたが、なにかゴールそのものでない、少しモヤモヤしたものを感じていました。

今回の杉本さんのお話で、我々が開発しているのはお客様の情報処理モデルそれ自体であると再認識しました。そのための道具が、ユビキタス言語であり、ドメインのパターン、DSL、ドメイン特化基盤(DSP)なのでしょう。

道具と思考

杉本さんがDDDはドメインの解決領域を対象にするとされたのに対して、2番目の佐野さんの発表では解決領域の手法やツールが問題領域に制限を与えるとのお話でした。

たとえば「指定されたファイルをソートする」という課題が与えられたとき、その解決法に依って、引数のファイル名をオープンして、stdinで、sortコマンドで、エクセルで、と課題の置かれた状況が変質していきます(注:言い換えてます)。

たしかにそうなのですが、DDDにおけるユビキタス言語は、概念を整理してより前向きに開発を進めるためのものではないかと思いました。

杉本さんが紹介されたfusion_placeにも問題のあり方を決めてしまう側面があります。しかしDSPとして考えると、ドメインの基本的な解決パターンを提供する事でその詳細に対する考慮を不要にして、より大切なことに力を割く事ができます。

これは、Rubyのまつもとさんが言われた「ある種の制約は自由を増やす」の一例ではないかと思いました。

ドメインを極めたあと

最後の渡辺さんの講演では、ドメインには階層性があって抽象度の高いドメインによってより具体的なサブドメインの実現を容易にする。まずは、興味があって、今後も期待できるドメインを決めて、極めなさいとのこと。

何か得意なプログラミング言語があれば、それが自分の強みになります。それを基に仕事をしていく事がエンジニアの道なのでしょう。

でも渡辺さんがスゴいのは、販売管理のドメインに詳しいだけではなく、他の業務にも詳しくて、その上位の抽象度の高いドメインを極められているからだと思いました。

まずはドメインを決めて、その後に幅を広げる事が大事だと思いました。

おわりに

業務系のお話が多いIT勉強宴会に何度も参加させていただいていますが、実はあまり関係のない開発をしています。いわば他流試合です。

他分野の情報はとても刺激的で、今までの知識を見直すきっかけになっています。そういった刺激をいつも受ける事ができて、とても感謝しています。

今回のDDDに関しても業務の目を通した意見をうかがう事で、業務ドメインを考える際に技術者の知識やパターンが活かされていて、ツールや手法という形で制約や自由を与えられている事を理解する事ができました。ありがとうございました。

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


こだわる場合とこだわらない場合の注意点

ソフトウェア業界にはこだわる方が多いですね。その一方で、あり得ない夢を抱いたり、なぜそこにこだわるのか、なんて思うこともあります。

家を探す場合から、こだわりについて考えて見たいと思います。

家を探す場合を考える

予算は〇〇円、会社までは〇時間〇〇分以内、〇〇線、〇〇停車駅、駅から〇〇分、〇〇駅、〇〇学区、条件を付ければ付けるほど、選択肢は少なくなります。

「そんなんがあったら、私が住みたいですわ」なんて言われる条件で探しても無理です。予算にあった候補を示されても、納得できるものはないでしょう。

逆に、本当は大してこだわりがないはずなのに、雑誌やTVの影響で作られた価値観を正しいと思い込んでしまい、ついつい選択してしまっている方もあるでしょう。

雑誌にある通りに選んだのにどうもしっくりこない。孟母三遷ではないですが、3度くらい引っ越して、ようやく自分のこだわりがわかるのかも知れません。

家を買う場合のこだわりに関して考えましたが、これらには一般的な注意点が隠れていると思います。

こだわる場合の注意点

  • あり得ない条件は無理
  • 条件を減らすと候補が増える
  • 優先順位を決めておくと決定が容易になる

大切なのは成功確率を高める努力をすることです。住宅なら近くに引っ越して、チラシや空き地の状況等の情報にアンテナを張ることで、成功確率が上がります。

ソフトウェアの世界なら自ら情報発信する事が、成功に近づく事になると思います(情報を得るには Give & Give - 発表のモチベーション -)。

こだわらない場合の注意点

  • わからないままにこだわらないで色々試す
  • こだわらない間は勉強期間と割り切る
  • 優先順位が見えればこだわる

せっかくフリーなポジションにいるのに、周囲の声やマスコミに流されていたのではもったいないです。自分なりの優先順位ができるまでは、メタな情報を含めて幅広い情報を得ると良いと思います。

情報を得るには独学のほか、多くの経験者に効く事が実践的な情報に触れる近道でしょう(技術者には「場」が必要 - 勉強会に行く理由 -

おわりに

技術者たるもの何らかのこだわりを持って仕事をしていると思います。しかし、こだわりには、良いこだわりと良くないこだわりがあると思います。

良いこだわりは技術的な指針を示して中長期の未来を切り開くものです。一方の良くないこだわりは自分の行動を制限して未来の可能性をつぶしてしまいます。

一度、自分のこだわりを棚卸しして、優先順位を付けると良いと思います。大切なこだわりに絞り込んで行動すれば、これまでうまくいかなかった事も前に進み出すかもしれません。

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

効果的に対策を打つための5つの戦略

複数の問題がある場合。対策のとり方には2種類あります。全体の問題をよく考えてから効果的な対策を取る方法と、大まかにターゲットを決めて素早く対策をとる方法です。

真面目な方は、よく考えてから取りかかった方が良いと思われるでしょう。しかし、検討している間にも問題は大きくなり、時間が経てば経つほど実施可能な対策は少なくなってしまいます。

完璧なプロジェクトなんてないのです。現実的な方法はポイントを絞って素早く対策を打つ事です。そこでは以下のような戦略が役に立つでしょう。

パレートの法則

「8割の問題は2割の原因から生じる」いわゆる2割8割の法則です。問題の影響を見極めて、放置しておくと影響が大きくなるようなリスクの高い問題の解決に集中します。

対策をとるべき問題の影響は8割もありますので、どんぶり勘定で十分です。細かく予測するよりは、素早く判断します。

ナップサック問題とグリーディーアルゴリズム

ナップサックに荷物をなるべく多く詰めようとすると、何度も入れ直すはめになって時間がかかってしまいます。これが計算量の問題として有名な「ナップサック問題」で、全ての組合せを検討すると時間がかかる事が知られています。

現実的な解決法としては、グリーディーアルゴリズムが有名です。大きなものから貪欲(greedy)に詰め込むと、程々に効率の良い結果が得られます。パレートの法則の様に8割に相当する問題が見つからなければ、リスクの高いものから優先的に対策を実施します。比例尺度でなく順序尺度で判断します(メトリクスの特性からアジャイル開発を考える)。

孫子の兵法

そのほかの問題はどうするのかと、気になる人もいるでしょう。でも、防衛線を築くには多くの兵力(工数)が必要で、203高地のような苦戦を強いられます。

兵力が十分でないなら、分散してはいけません。まずは優先度が高く、間違いなく攻略できる問題に対策を打ちます。

北辰一刀流の教え

状況は日々変化します。気が焦るばかりで、冷静に判断ができないかも知れません。 しかし、北辰一刀流の教えにある様に「いまだ!」というタイミングを見計らって、一気に攻めましょう。

「気は早く、心は静か、 身は軽く、技は激しく」これは、司馬遼太郎さんの「竜馬がゆく」に出てくる言葉です。早めに準備をして、冷静に判断し、その時がくれば素早く、効果的な対策を実施します。

千里の道も一歩から

ただし、効果がわからないまま対策を打ってはいけません。やってみないとわからない事もありますので、実際にやってみる必要があります。現地現物という言葉がある様に、プロフェッショナルは本物で確認しないといけません。

品質保証にも探針といって部分的な評価をする方法があります。確認作業を部分的に前倒しすることで、ムダな作業を減らす事ができます。必要に応じて、スモールスタートで実践しましょう。

まとめ

問題の対策を効果的に打つための5つの戦略を説明しました。リーンや アジャイル開発にも通じる考え方です。

ポイントは、大事なことを見極めて、優先順位をつけて、 ポイントを絞って、タイミングを見計らって、 少しずつ実践することです。

ここに挙げた5つの戦略は、様々な物事に通じる一般的な戦略です。実は5つの戦略は、Agile Tour Osaka 2012 のライトニングトークでお話した内容です([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)。図で説明していますので、リンク先にあるスライドも是非ご覧下さい。

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


« 2015年10月 | トップページ | 2015年12月 »