無料ブログはココログ

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

マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで -

マイクロサービスにしてもうまくいくとは限らない。そんな思いで前回の記事を書いたのは、 Martin FowlerさんのMonolithFirstを読んだからです。

マイクロサービスの提唱者の一人であるMartin Fowlerさんは、単に提唱するだけでなく、自動化など環境の必要性を説くなどされていますが、今度はモノシリックに一度作る戦略を説明されています。

その方法は2つで、モノシリックに作って徐々にマイクロサービスにするか、作ったものを捨ててマイクロサービスで作り直すかです。一度にマイクロサービス化すると構造の変更が難しくなるからでしょう。

このお話はプロダクトラインのコア資産と似ています。複数のラインアップを作るからと、共通に利用できるコア資産に多大な投資をしても完成が遅れ、会社が傾く事があると言われています。

理想を追いかけるとムダに工数がかかりやすく、その時点の予想が正しいかどうかを確認するまでに時間がかかってしまいます。また、開発中は利益を生み出ないですから、企業にとって大きな負担になります。

より良い戦略は汎用性を意識しながら開発したシステムからコア資産を作るか、システムを開発しながら最低限のコア資産に絞って開発するかでしょう。リーンスタートアップの様に価値を生み出しながら方向を見極める事が企業の存続には必要です。

マイクロサービスには多くのメリットがありますが、どのように作るのか、どの順番に作るのか、しっかり考えないといけないと思いました。

(とはいっても、ブームになると期間は短期間で一気にマイクロサービスで作れというようなお話が来ないかと、不安を抱いているのでした)

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

SOAとマイクロサービスを複合設計に当てはめると見えるもの

ざっくりと物事を考えると、案外見えてくる事もあるものです。細かな事は置いておいて、「昔は〇〇というのがあってな、、」と昭和のジジイらしく考えてみました。

SOA(Service-Oriented Architecture)

SOAを知ったとき、サービスの考え方がトランザクション分割の様だと思いました。

トランザクション分割というのは機能中心の設計法である複合設計で紹介されているプログラム分割法です。構造化設計の文献でご存じの方もあるでしょう。

複合設計でプログラムを分割する際は、上位モジュールはトランザクション毎にモジュールを分割し、下位モジュールは 共通機能分割・データ構造分割します。そして、中間のモジュールは源泉・変換・吸収型分割(以下STS分割)します。

SOAと言われ出した頃は、プロトコルが話題になりましたが、その実はサービスという大きな機能の単位でAPIを作りましょうということなので、トランザクション分割とさほど変わらない様に感じたのです。

マイクロサービス

最近はマイクロサービスという言葉が騒がれ出しています。汎用的な小さなサービスを用意しておけば、それらを組み合わせてシステムをつくれ、保守も容易でウハウハ!といった話を聞くと、複合設計の共通機能分割やデータ構造分割を思い出します。

複合設計で考えると、トランザクション分割はトップダウンですが、共通機能分割やデータ構造分割はボトムアップなので、汎用性の高いモジュールを実現できます。しかし、それだけではシステムを構成できないので間をつなぐ必要がありました。

構造化分析/設計ではDFDの中心を引っ張り上げてプログラム構造を作るという手法がありましたが、無理矢理なインタフェースでは良いプログラムはできませんでした。複合設計では最も抽象的はデータのところをインタフェースにするというSTS分割で、上のような中間をつないで少しマシな構造を実現しました。

構造化分析/設計にしろ複合設計にしろそれなりに動くのですが、保守性が悪く、その後のオブジェクト指向やデザインパターン、ソフトウェアアーキテクチャなどの議論に繋がりました。

歴史は繰り返す

そのように考えていると、変な感じがしました。SOAにしろ、マイクロサービスにしろ、オブジェクト指向の人たちが言い出していたからです。

技術は壁にぶつかった時、新しい解決法を生みます。それまでのオブジェクト指向が壁にぶつかった時、新しい解決法としてかつてライバルとした仕組みを取り入れて、新しいオブジェクト指向に生まれ変わろうとしているのでしょう。

たぶん、マイクロサービスだけではうまくいかないと思います。マイクロサービスをどのようにまとめるか、どのようなアーキテクチャーを実現するかなど、経験を蓄積すべきなのでしょうね。

今は問題を洗い出している段階なので、色々と工夫が必要なのだと思います。やがて、方法論やパターンがでてきて、設計で行われたように、問題の解決と問題領域の変更を繰り返すと思います。

気になるのは、エージェントがいつ再登場するか、機会学習の普及で潮目が変わるのかですが、どうなるのでしょうね。

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

ソフトウェア産業に望まれる人材 - 情報の波に飲み込まれないには -

先日、阪南大学でスピーチしてきました。1年生向けの情報の授業で、IT関係の企業の方にお願いして学生さんに興味を持ってもらおうという主旨の様です。

内容は何でも良い様でしたが、せっかくなので私の思っている若い人への期待をお話しました。

私が若い頃に見聞きしたことに、最近思う事を加えた内容です。スライドには無い、飲み屋で話すような自己紹介がわかる様に業界を説明したあと、情報の波に流されない方法をお話ししました。

「情報の波に流されないように」私が新人研修の時に聞いた言葉です。でも、どうするかまでは教えてもらえなかったので、私流の方法として、

  • 会社に閉じこもらない
  • 対立構造として理解する
  • 魚でなく魚の穫り方
  • 現地現物
  • 段取り八分

などなど、色々お話しさせていただきました。

色々アドリブでお話しした中では、授業内容のビット数と状態数とからめたり、息子の話から最近は教育がサービス化して段取りができなくなっているといったお話が、先生方に評判が良かった様です。

まだ1年生の学生さんなので、どこまで響いたかはわかりませんが、自分が若い人に何を期待しているか考えさせていただく良い機会になりました。

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

現場の人が論文を書く際に気をつけたい事

久しぶりに論文を書きました。私の様に現場にいる人間が論文を書くとき、熱い気持ちで思いの丈を書き綴っていても論文は採択されません。それは論理的に整理しないといけないのに、複雑な要素が絡み合う現場にいるからです。

今回、論文を書く際に気をつけた事を以下にまとめておきます。

現場はリアル

現場で問題に思っているのは、目の前の出来事です。スゴいものを実現したからと論文風にまとめてもなかなか採録されません。お客様に認められているのですから、決してつまらないのということはありません。それをきれいに説明できないからです。

ついつい苦労した事や工夫した事を色々と書きたくなりますが、そのままでは論旨がわかりにくくなってしまいます。書きたい事を書くのではなく、報告する内容を明確にするように、書かないといけないことを書きます。

これは、論文の構成をオーソドックスにまとめる事でかなり改善します。論文風にまとめるのではなく、論文らしくします。具体的には広い話題から徐々に話題を絞っていく、ページ比率を予め決めて書いて詳細すぎる内容は付録にまわす、全体の論理構成を決めてから書く、段落は短過ぎず長過ぎない同程度の長さに揃える、ことで見通しが良くなります。

論文には有効性が求められますが、論理的な構造が明確でなくては伝わりません。読み手が求めている事は何かを考えて書くと良いと思います。

現場にはネタがいっぱい

書いている事がわかり易くなっても、問題設定が適切でなければ評価されません。現場には論文のネタがたくさんあり、その絞り方で論文の価値が決まります。

まずはアピールできる成果を絞って、その成果を裏返してみます。「XXができていないので、XXを実現した。」という論文を考えます。そして、XXはなぜ必要なのか?あるいは、XXができると、他に何か良い事が無いか?また、なぜ、今までなぜ無かったか?などを考えて説明を膨らまして、適切な場所に配置していきます。

初めに書きたい事を書いてからスリム化をしようとしてもうまくいきません。書きたい情報が多いのでそもそも論理的な構造になりにくいですし、ネタが多過ぎてポイントがぼやけるからです。あたりまえの内容は参考文献にまかせて、新規性に関わる内容だけに絞ってフォーカスをあてます。

現場の成果はあるユーザに役立つ成果物ですが、論文に書かれた成果には一般の人に役立つ新規性が必要です。そのような成果を見つけ出すことが論文の成否に繋がります。論文を書き出してからも概要がスッキリかけるような成果を追い続けると良いと思います。

現場に引用はあまり要らない

開発現場のドキュメントでも用語集を作ることもあり、言葉の定義は重要です。しかし、その根拠となる文献が詳細に示されている事は少ないでしょう。

現場では巨人の肩にのる必要はありませんので、輪講をしていたり、常に文献を探している人は少ないでしょう。このため、意識して書かないと引用が雑になってしまいます。

具体的には、論理の組み立てが荒く、本や論文の具体的な文章やページを示さずに引用するといった事はなるべく避けたいものです。また、そもそも参考文献が少ないのは、ほとんど全てがオリジナルだと言っているのですから、良い内容であってもあまり信頼されないでしょう。

現場は独自文化

多くの開発現場には独特の社内文化があり、一般的でない言葉が定義されている場合があります。だいたいの意味は同じでも使い方を限定していることもあります。議論の展開に必要な言葉は、きちんと引用するか定義して使いたいものです。

独自文化で育てられた技術は、なぜその技術が成り立つかをきちんと説明しないと、利用が難しいでしょう。しかし、ふだん使っている技術のどこが他社と違っているのは、考えるだけではわかりません。関連する文献を読んでおくことや、勉強会などで他社の人とお話しする機会を持つことが大切だと思います。

現場の数字が出せない

現場の数字、特に生産性や信頼性に関わる数字は表に出しにくいものです。許可を得る事が難しい場合は、相対値で示す、出しやすいプロジェクトのデータを選ぶなど、色々工夫をしてみましょう。

定量的に示さずに感想を書いても信頼できる情報にはなりません。論文を書く際に最初に乗り越えておくべき課題かも知れません。

おわりに

上述の様に現場で論文を書くことは、困難を伴います。しかし、現場の情報を出さないでおいて「ソフトウェア工学は役に立たない」とぼやいていても何も変わりません。

ソフトウェア開発はエンジニアリングそのものですから、そこで見つけた技術を共有し合えば、技術はもっと向上するはずです。これは自分たちだけのノウハウだなどといって隠し持っていても技術は陳腐化してしまうでしょう。

技術はGIVE and GIVEのつもりで、情報提供すれば自然とアイデアがもらえ、より洗練された技術になるでしょう。ぜひ、論文を書いて技術を磨きましょう。

おまけ

これまで何度か論文の書き方を書いてきましたが、大学の先生方が言われる書き方と大きく違います。これは、ここに書いたような問題があって素直に書いたのではうまく書けないからです。

これまでの記事はカテゴリ「論文の書き方」にまとめましたので、是非参考にしてください。


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

[#TiDD] 標準プロセスを肥大化させない補完型チケット駆動開発の提案 - SS2015に参加して -

ソフトウェアシンポジウム2015(SS2015)に参加しました。今回は経験論文の発表とワーキンググループのサブリーダーをしました。

標準プロセスを肥大化させない補完型チケット駆動開発の提案

論文は補完型チケット駆動開発の経験をまとめました。補完型チケット駆動開発は計画に無いタスクをチケット化しますので、プロジェクトに固有の情報だけが蓄積されます。

組織的なプロセス改善では、組織内の全てのプロジェクトを共通の標準プロセスで管理します。このため、プロジェクト固有の情報を組み込むとプロセスが肥大化してしまいます。

補完型チケット駆動開発ではプロジェクト固有の情報が収集できるほか、チケットの数も少ないので、リプレース時や類似プロジェクトの計画時や障害発生時の参考になります。

一度経験すると補完型チケット駆動開発の良さはすぐに実感できるのですが、どのような内容が含まれるかはあまり公開されておらず、普及の妨げになっていました。そこで、過去のプロジェクトのチケットを分類して発表しました。

ワーキンググループ

ワーキンググループではWG7: 「開発手法・開発環境の現場導入の現実」のサブリーダをしました

ポジション発表として論文発表のプロジェクトを紹介したSPI Japan 2010の発表(概要スライド)をベースに発表しました。

ワーキンググループでは、落水先生から方法論は役に立つのになぜ苦労するかわからないとのポジション的な問題提起があり、それぞれの苦労話をしました(落水先生は元JAISTのプロセスの大御所です。色々お話できてうれしかったです)。

印象的だったのは無理やり標準化しているところはなく、現場がきちんと理解してもらえるように苦労していたことです。補完型チケット駆動開発も自主的に導入してもらえる様に、これまでの経験を具体的に示すことが大切だと思いました。

謝辞と感想

このように刺激的な経験ができたのは、開発現場の皆さんと、シンポジウムのスタッフの方々のおかげです。盛りだくさんのシンポジウムの開催は大変だったと思います。ありがとうございました。

今回はセッションが並列だったので、残念ながら論文賞の発表を聞く事ができませんでした。できればシンポジウムは論文発表を中心にして、ワーキンググループはプレイベントか並列イベントにして欲しいと思いました。

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

「Redmine実践ガイド」が出版されます - 推薦文公開 -

今年はRedmine本の当たり年のようで、続々と出版されています。「入門Redmine 第4版 」と「Redmine超入門 増補改訂版 」は改訂版、「10倍速の開発・運用ツール」は、日経SYSテMSのJenkins、Chef、Redmine、Dockerの記事を集めたムックですが、「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント 」は、全編書き下ろしの新刊書で6月22日に発売予定です。

この「Redmine実践ガイド」は基本的な使い方からチケット駆動開発、事例まで載っている本で、Redmine界隈の有名人がレビューアや寄稿などで協力しています。私もレビューのほか、コラムを寄稿させていただきました。

なかなか良い本になったので、推薦文も頑張って書かせていただきました。ちょっと面白い文章になりましたので、ここにも公開します。


この本を手にしたあなたに

 この推薦文を読んでいるあなたが、この先を読むなら少し覚悟が必要かもしれません。この本を読めばRedmineの実践に関する、多くの情報が得られるからです。

 「なにげなく手に取ったあなた」は理想的なプロジェクトを知ることになるでしょう。なんとなく感じていた不満が明確になります。プロジェクトの状況がわからない、ゴールが見えない、他の障害にブロックされて作業が進まない、このような問題は、これまでITS(課題管理システム)を使わずにスプレッドシートで障害や課題の管理をしているプロジェクトにありがちな問題です。

 プロジェクトには共有すべき情報がたくさんありますが、うまく共有するにはそれなりの仕組みが必要です。RedmineならチケットやWiki、ニュースなど、その情報にふさわしい方法でリアルタイムに共有できます。バージョン管理ツールと連携してチケット駆動開発を実践する事も可能です。理想的なプロジェクトは、実際にRedmineを使ってみないと実感できないかも知れませんが、今まであたりまえと思っていた問題に気付く事になるでしょう。

 「Redmineの導入をためらっているあなた」は、Redmine以外の選択肢考えられなくなってしまうかもしれません。 ITSならどれも変わらないだろう。そう思っているならなおさらです。規模の大きなシステム開発の管理に便利な階層的なプロジェクト、親子関係のほか様々な関連づけが可能なチケット、日常的によく使う検索を登録できるカスタムクエリ、チケットの属性を追加するカスタムフィールド、イナズマ線が使えるガントチャート(Lycheeプラグインでさらに便利に拡張できます)、確認や承認の漏れを無くせるワークフロー機能(webで簡単に設定できます)、などなど。これほど多機能なITSは他にないでしょう。

 しかも、日本発のオブジェクト指向言語Rubyで書かれていることもあり、日本でもコミュニティが活発です。この本にも、Redmineのコミュニティで広く知られているチケット駆動開発のお話や、チケット駆動開発が普及するきっかけになった、Issueがチケットと訳された際の裏話が載っています。また、Ruby専業の会社が書いた本だけあって、プラグインの作り方まで書かれています。Rubyはバージョンアップが頻繁な言語ですが、Redmineはテストコードがしっかり書かれているので安心して使うことができます。もちろん、Rubyの高速化と共にRedmineの処理性能も向上しています。ほら、あなたも使ってみたくなったでしょ?

 「Redmineを導入したいのに上司に反対されているあなた」なら、この本でチャンス到来です。Redmineは日本では最も普及しているITS(課題管理システム)と言われていますが、導入の最初で最大の難関は上司の説得でしょう。「みんなが使っているので、うちも入れましょうよ」と言っても、「みんなって誰?入れている会社があるなら言ってごらん」とまるで駄々をこねる子供を諭す様に返されていないでしょうか?これまでは導入事例を書いた書籍が少なかったので、言い返す言葉がありませんでした。しかし、この本には豊富な事例が載っています。この本の事例を知ったなら、多くの企業がどのように使っているかを説明する事ができるでしょう。

 Redmineの普及に伴って、様々な書籍が発売されるようになりました。基本的な機能をわかりやすく説明した本、リファレンス的な本、チケット駆動開発による使い方を説明した本、などなど。でも、この本ほどRedmineの事例の多くのページを割いた本はありませんでした。事例は自分たちが直面している問題を見つける際にも有効です。多くの企業がRedmineを使うのは、それぞれの抱えている問題を解決したいからです。それは障害管理かも知れませんし、タスクの管理かも知れません。あるいは、顧客からの問い合わせ管理やIT全般統制かもしれません。それぞれの問題にどう使っているのか、どのような効果があったか、この本にはそのような事例がたくさん載っています。きっと上司も納得してくれるでしょう。

 この本でRedmineに詳しくなったなら、サーバー管理者を頼まれるかも知れません。Redmineをカスタマイズして組織のプロセスを構築する事は楽しいお仕事ですが、ほかに担当している仕事があれば、忙しい時には困ることもあるでしょう。でも、このようなピンチは簡単に乗り切れます。一つはこの本に載っている運用者のTIPSに従って、バックアップや監視を自動化する事です。もう一つの方法は、職場の仲間にこの本を薦めて同志を増やす事です。

 最後に、このように推薦文を書いている私ですが、なぜかコラムも書いています。開発現場を改善する補完型チケット駆動開発の解説と、ふだんはtracを使うことの多い私がRedmineをどのように思っているか感想を書いています。これらのコラムはRedmineに肩入れせずに公平な立場で書いたつもりです。ご興味があれば、ぜひ一読してください。

 さあ、覚悟はできましたか?早く本文を読んでみたくなったでしょう。それでは読み進めてください。きっと得るものがあるはずです。

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


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