« 2012年12月 | トップページ | 2013年2月 »

2013年1月

2013/01/29

SparkleShareで無料版Dropboxを作る

SparkleShareというOSSのファイル共有ツールを使うと、無料版Dropboxが作れる。
リンクをメモ。

SparkleShare - Self hosted, instant, secure file sync

SparkleShareメモ - nofuture.tv

第210回 SparkleShareで自分専用のDropboxサービスを立ち上げる:Ubuntu Weekly Recipe|gihyo.jp … 技術評論社

SparkleShareでさくらVPSにオレオレDropboxを作る | tjun memo

無料のGitサーバーを準備して、SSHを設定すれば、ローカルPCの所定フォルダでファイル変更があれば自動的にGitへ共有される。
GitHubでもよいが、BitbucketならばGitのプライベートリポジトリが使いたい放題なので、その方が便利だろう。
自分用サーバを所有しているならば、Gitさえ導入すればすぐに使える。

後は、iPhoneやAndroidでも参照できるようになれば、より使いやすくなるのだが。

| | コメント (0)

2013/01/28

期日が間近のRedmineチケットをメールで通知する

期日が間近のRedmineチケットをメールで通知する方法が公開されていたのでメモ。

【元ネタ】
Twitter / iktakahiro: こんな簡単にできるんかい! | 期日が間近のチケットをメールで通知する(リマインダ機能) | Redmine.JP http://redmine.jp/faq/issue/send_reminders/ …

期日が間近のチケットをメールで通知する(リマインダ機能) | Redmine.JP

【1】チケットの期日がもうすぐなのにまだ完了していない場合、担当者に通知して、対処を促すようにする運用をしたい時がある。
その時、Redmineの場合、下記のコマンドが使えるらしい。

(引用開始)
【期日が3日以内に到来するチケットを通知】
※例えば実行した日が5月27日であれば、期日が5月30日以前(30日も含む)に設定されているチケットの一覧を通知。

rake redmine:send_reminders days=3 RAILS_ENV=production

【cronによる定期実行】
cronで毎朝自動的に実行するように設定すると便利です。

/etc/crontabに下記のように設定すると、各ユーザーに、7日後までに期限を迎えるチケットまたは既に期限が過ぎたチケットの一覧が毎朝6:30に送信されます。

30 6 * * * root cd /path/to/redmine ; rake redmine:send_reminders RAILS_ENV=production
※ /path/to/redmine はRedmineのインストールディレクトリに置き換えてください。
(引用終了)

【2】下記プラグインを使うと、リマインダにチケットの期日・ステータスの表示など追加できるらしい。
やるべきタスクの一覧を整理して通知したい時に使えるだろう。

vividtone/redmine_extended_reminder ・ GitHub

また、プロジェクト管理の理想の記事が素晴らしい #redmine: プログラマの思索でも、@yusuke_kokuboさんの方法も紹介していた。

Redmineでリマインダー - こくぼ@Everything is the experience.

PMBOKのEVMの観点では、「今日が期限の未完了チケット」「期限が過ぎている未完了チケット」はSPI>1に相当する。
チケットが開始日になれば、SPI=0からSPI>0に変わるので、今からタスクを開始しなさい、と通知すればいい。
チケットが期日までに完了すればSPI=1になるので、期日になってもSPI<1のチケットは未完了チケットゆえに、タスクが残っていますよ、と通知すればいい。

つまり、上記の機能は、SPIというEVMの指標を使って通知する事も可能だ。

【3】従来ならば、現場リーダーがExcelのタスク一覧をにらめっこして、必要なタスクを毎晩洗い出し、翌朝に担当者へ指示する運用が多いだろう。
この運用の弱点は、現場リーダーが倒れたり、多忙でタスクの整理が追いつかない場合、リーダー自身がプロジェクトのボトルネックになることだ。
そもそも、やるべきタスクはメンバー自身が自ら気づいて動けばいいのであり、そのためには、チケット管理システム自身が期日になれば必要なタスクを通知すればいい。

プログラミング技術の一つとして「私に聞くな、必要な時はこちらから声をかけるから」というハリウッドの原則があるが、チケット駆動開発におけるチケット通知機能はこの原則に似ている。
つまり、必要なタスクはリーダーに聞く必要はなく、チケット管理システム自身に問いかければいいのであり、チケット管理システムが自動通知してくれればいい。

そうなれば、他のタスクはチケット管理システムで既に管理されているのだから、現在のチケットに集中して作業すればいい。
@sakaba37さんが「チケット駆動開発」で書かれているように、このような情報は非同期で取得した方が、タスクを通知したいリーダーも、タスクの担当者も時間に追われることもない。
メール通知だけでなく、RSSなどの機能を使う手法もあるだろう。

色々考えてみる。

| | コメント (0)

2013/01/27

JRuby+Redmineのインストールメモ

Windows上で最速でRedmineをインストールするためのメモ。

【参考】
u6k Apps開発ログ: Redmineをwar化 (1) とりあえずRedmine+JRubyを動かす

Redmine 2.1をCentOS 6.3にインストールする手順 | Redmine.JP Blog

日本語JRuby: JRubyの一年を振り返って

【環境】
Windows7 64bit
JDK:1.7.0_06
JRuby:1.6.8

※PATHに登録済み。
※CRubyでも良いが、JRubyなら解凍するだけで良い。
 日本語JRuby: JRubyの一年を振り返ってによれば、Windows上でRubyを気楽に使えるためにJRubyがあるという意見もあるらしい。

※JRuby1.7.2では、Redmineのバージョンによって起動できない時があった。Redmineの最新版では変わるかもしれない。

Redmine:2.2.2

※ redmine\lib\SVG\Graph\Graph.rb などのファイルで改行コードをLFに直さないと、Webrick起動時にエラーが出るみたい。
Redmineの最新版では直っているかもしれない。

※Redmineの動作検証で使うため、MySQL、PostgresSQLは使わない。SQLiteをデフォルトDBにする。
 長期運用を考える場合は、MySQLやPostgresSQLの方がいい。

【インストール方法】
Redmineを落としてきて解凍する。

cd $REDMINE
cd config
cp -ip database.yml.example database.yml

vi database.yml

デフォルトのDBは、SQLiteへ変更する。
production:
adapter: sqlite3
database: db/production.sqlite3

jgem install bundler --no-rdoc --no-ri

jruby -S bundle install --without development test

cd $REDMINE
rake generate_secret_token

rake db:migrate RAILS_ENV=production

jruby script/rails server webrick -e production

http://localhost:3000
へアクセス後、admin/adminでログイン。

| | コメント (0)

最初から完璧な開発環境を作ろうとする時の罠

良い記事があったのでメモ。
自らも肝に銘じておく。

未知の領域で開発を始める時には、環境を整えすぎてはいけない - 愛と勇気と缶ビール

(引用開始)
未知の領域って何ぞいな、というとだいたい以下の二つ。

・開発経験のないプラットフォーム。場合によっては触ったことのない言語を含む。(e.g. iOS, Android)
・今まで触ったことのない言語を用いた開発。

世の中にはエディタ・IDEからCIまで沢山の開発を支援するためのツール・枠組みがあるが、新しい領域に挑戦する時にはこれらの開発環境をあまり整えすぎない方がいい気がしている。

というのは、最初から「エディタも完璧に設定して、テストも全部書いて、JenkinsでCIするようにして、デプロイの前にビルドが走るようにして…」というようなセットアップを全部やろうとしてしまうと、それ自体に時間がかかって、それだけである程度満足してしまうから。単なる経験則だけど。

環境構築に時間をかけ、その結果に満足してしまうと一番初めのプロダクトに使うためのモチベーションと時間が消費されてしまう。(なんか誰かが同じようなことを書いていたような気もする。忘れた。)

新しい領域で、何かまとまったものを一つ作ってしまう。作りきる。それが大事かつ最も大変なことなので、ノイズは乗せない。初めから全てうまくやろうとしない。かっちょいい開発プロセス、効率的な開発環境が欲しければ後からいくらでも整えればいい。

そんなわけで、何か新しいことをやろうとする時に、最初から完璧に環境を作ってしまおうとするアナタは結構危険である。そのモチベーション、使いドコロが間違っているかもしれない。
(引用終了)

泥臭いプログラミングでまずはリリースして納品することが目的なのであり、綺麗なプロセス整備が目的なのではない。
こういう落とし穴にはまらないように注意。

| | コメント (0)

2013/01/26

DevOpsアンチパターン

「DevOpsアンチパターン」という記事を見つけたのでメモ。
アンチパターンをもっと作れたら面白いだろうと思う。

【元ネタ】
DevOpsアンチパターンとは? - Publickey

AWS-CloudDesignPattern

【1】クラウドが出現して以来、Webインフラもプログラマブルになってきた。
そのおかげで、開発と運用が以前のようにチームとして分離するのではなく、一体化して作業していく方向へ進化している。
以前はWebの基盤構築作業は、設計書を事前に入念に作り、その設計書に従ってサーバーやメモリ、HDD、ルータなどのハードウェアを揃えて構築するというWF型開発が主流だった。
でも、仮想化技術やクラウドのおかげで、構築後にスケーラビリティを上げることもできるし、事前に入念な計画を作らずとも試行錯誤しながら基盤構築できる時代になってきた背景がある。

クラウドに関するデザインパターンは、下記の記事が有名だろう。
AWSに特化したパターンだが、そのノウハウは従来の基盤構築でも十分通用すると思う。

「クラウドデザインパターン」をAmazonが公開。システム冗長化、突発的トラフィック対応、動的コンテンツ処理など45種類 - Publickey

「クラウドアーキテクティング原則」。クラウドデザインパターンの背後にある、システム設計の原則とは - Publickey

僕も以前に記事を書いた。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

【2】上記の記事では、以下のアンチパターンが紹介されている。
クラウドでWebサイトを公開している経験があれば、こんな失敗例があったな、とか思うのではないだろうか。

(引用開始)
1)アンチパターン1:コミットが“完了”/Committed is “Done”

デベロッパーにとって、“コミットが完了”と考えるでしょう。システム管理者なら“スクリプトが実行され、それが理解できている”ことだといえます。でもみんなちょと待って。これはDevOpsなんだよ!
(DevOpsでは)あらゆるデベロッパーはエンドユーザーのことを考えなくてはならないんだ。

よいデベロッパーは、新しい機能のコードを書いたらそれだけではなく、テストをし、最終的にはユーザーへリリースされたことを確認しようとします。そのときこそが、本当にタスクが完了したということなのです。

2)アンチパターン2:僕の担当はここまで/My Responsibility Ends Here

コードの問題だろうと運用の問題だろうと関係なく、だれもが責任を感じ、問題発見に力を貸すべきだ。

3)アンチパターン3:彼らがやるべきだ/They Should

もしも“俺たちvsあいつら”といったことがあなたの組織で起ころうとしているなら、それと戦いなさい。だれもが自分たちの組織全体の成功に貢献し、そしてコミュニケーションの向上によって“俺たち”といった縄張りを解いていくのです。
自分たちは同じ組織に属しているのだと感じることが、コラボレーションを育て、DevOpsのカルチャーへと導いていくのだ。
(引用終了)

(引用開始)
1)Config Management = DevOps
構成管理ツールを入れればDevOpsができると思ってはいけない。協力し合うカルチャーを作り続けていくことが重要なのだとのこと。

2)Guerrilla DevOps
プロセスの一部だけをDevOpsっぽくしたからといってそれほど効果は期待できない。プロセス全体を統合すると。

3)Start a separate DevOps Group
DevOpsグループなんてのを作ったところで、また新しいサイロを1つ作るだけだ。全体で取り組むべき。

4)Silo X takes Over
開発者がプロセス全体を支配したところで、また彼らが運用を学び直すことになる。どちらかが支配するのではない。
(引用終了)

DevOpsに関するアンチパターンを読むと、開発チームと運用チームをいかに一体化して作業していくべきか、に関する内容が多い。
アジャイル開発の知識がある人ならば、アジャイルなプラクティスととても似ていることに気づくだろう。
だからこそ、とても面白い。

そしてこの分野は今なお、いろんなアイデアを試しながらノウハウや失敗例を収集し、整理して、普遍的概念を抽出しようと試みている時期なのだろう。
その意味ではとてもホットな分野であり、今後も注目していく。

| | コメント (0)

2013/01/25

チケット駆動開発の弱点~プロダクトオーナーをどこに配置するのか?

チケット駆動開発を今まで実践してきて、アジャイル開発を現場で導入するための一手法としてとても有効だと思う。
でも、多分唯一の弱点とすれば、「プロダクトオーナーをどこに配置するのか?」という問題があると思う。
ラフなメモ書き。

【1】プロダクトオーナーは、開発チームと同等の立場で、リリース計画を作り、マイルストーン単位にリリースすべき機能を定めて、少しずつ製品を完成させていく。
プロダクトオーナーは、顧客と交渉して要件をまとめたり、作るべき製品の機能を整理して開発チームへ説明すしたり、予算計画を作って日々のコスト管理を行ったりする。
だから、プロダクトオーナーが開発チームを管理したり、進捗を監視する必要はそもそもないし、そんなことをする暇もない。

すると、チケット駆動開発では、プロダクトオーナーはどこに配置すべきか?

【2】チケット駆動開発で出てくる役割(ロール、権限)は最大4つある。
それは、システム管理者、管理者、開発者、報告者。

システム開発者は、BTSないしITSのサイト自身の管理者。
管理者は、ITSの該当プロジェクトで最も権限を持つ人。イメージはプロジェクトリーダー。
開発者は、ITSの該当プロジェクトで、チケットに書かれた作業に従事する人。イメージはプログラマ。
報告者は、リリースされたシステムをテストして障害報告したり、使ってみて機能改善の要望をあげる人。テスターないし製品の一般ユーザ。

これら4つのロールは、元々、障害を管理するためのシステムとしてBTSないしITSが生まれた経緯を、チケット駆動開発が引き継いでいる。
だから、自分たちで作業を作り出してどんどん開発していくスタイルには向いている。

すると、あるべきシステム、あるべき製品のロードマップを作って、そこから少しずつ改良しながら小規模リリースしていく場合、仕様を生み出し、決定する人はどこに配置すべきか?

【3】開発チーム主導ならば、管理者(=プロジェクトリーダー)がプロダクトオーナーになる。
管理者がリリース計画を作り、マイルストーンごとにリリースする機能を定めて、チケットへタスクを落としていく。
しかし、管理者はチケット駆動開発の中で最も権限が強いため、普通は、開発者は管理者に従属しがちだ。
開発者と管理者は権限として対等ではない。

【4】ユーザストーリーから駆動して開発するスタイルならば、報告者(=ユーザ)がプロダクトオーナーになる。
報告者は障害を報告したり、使いづらいユーザインターフェースを改善する要望を上げて、機能拡張や品質改良に自らも積極的に関わる。
しかし、報告者はチケット駆動開発の中で最も権限が弱いため、普通は、報告者は開発チームにお伺いを立てる行動ぐらいしかできない。
報告者は、開発者や管理者が形成する開発チームと同等ではない。

【5】チケット駆動開発では、開発者は自らのタスクをチケットで公開することで、チームや自分自身の透明性(オープン)を保証してくれる基盤はある。
また、チケットがタスクであるから、そのタスクを担当することで、コミットすべき責任も負う。

システムのリリースバージョンをイテレーションと見なすことで、リリース後のフィードバックを得たり、日々の朝会やユーザからの障害報告からフィードバックを得たりして、開発チームがリリース計画を改良し、経験知を上げて成長していく基盤もある。
少なくとも、開発チームがソフトウェア開発を自律的に進めていくための基盤は揃っている。

でも、プロダクトオーナーをどこに配置すべきか、という問題は、チケット駆動開発だけでは解決してくれない。
それは組織構造の問題も孕んでいる。

こんな製品を作りたいという曖昧な所から、少しずつ作っては製品イメージを固めて、製品を最終リリースしていこうとすると、プロダクトオーナーのような役割がとても重要になるのに、その権限をマッピングする役割をチケット駆動開発のオリジナルだけでは実装できていないのだ。

多分、プロダクトオーナーというロールを管理者や開発者とは別に作る必要があるのかも知れない。
色々考えてみる。

| | コメント (0)

2013/01/24

野中郁次郎先生の講演資料の解説記事

Scrum Alliance Regional Gathering Tokyo 2013で野中郁次郎先生の講演資料の解説記事が公開されていたのでメモ。
SlideShareの資料だけでは読み取りにくい内容がうまく説明されていて理解しやすくなっている。

【元ネタ】
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造(前編) - Publickey

プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造(後編) - Publickey

アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:ITmedia オルタナティブ・ブログ

野中先生の資料を読むと、古き良き時代の日本企業の経営手法からエッセンスを取り出して、知識をベースとした組織のあるべき構造を説明されようとしているように思える。

でも、僕は、アジャイルの右翼(ソフトウェア開発環境)の観点でアジャイル開発を理解しているので、アジャイルの左翼は本当に理解できていない。
野中郁次郎先生の論文や出版された本を読んだけれども、平鍋さんがこれまで説明されてきたアジャイル開発とどのように関係しているのか、自分の中ではうまく理解しきれていない。
この内容からスクラムへどのように発展していったのか、をまだ完全に理解できていない。

むしろ、アジャイル生産とは ~ exBuzzwords用語解説に書かれている話の方が理解しやすい。
アジャイル生産とは ~ exBuzzwords用語解説では、日本の製造業が多重下請構造を政治的にうまく利用した開発スタイルなのだと思う。
つまり、トヨタのような政治的にも強い上流工程の組み立てメーカーが、特定の部品を作ったら品質が一流の下請け企業を自社の部品の在庫のように扱い、欲しい時に必要なだけの量の部品をいつでも納品できるような仕組みを作ったのがトヨタ生産方式といえるのではないかと思う

その仕組みを欧米人がよく研究して、ソフトウェア開発へ適用する場合、プログラマの創造的な能力を活かすように、規律を持ちながら自己管理できるスクラムチームのような組織構造を定義していったのではないか、と思ったりする。

野中先生の資料は、ソフトウェア開発論と言うよりも、経営論や組織論の観点から理解した方がいいのかもしれない。
平鍋さんと野中先生の共著「アジャイル開発とスクラム」を読んでみようと思う。

| | コメント (0)

2013/01/22

RedmineでGTD

RedmineでGTDされている記事を見つけたのでメモ。

【元ネタ】
RedmineはGTDにもピッタシだった | Azrael

GTDを使ってみたらストレスがマッハで軽減した | Azrael

GTDとチケット管理が似ている: プログラマの思索

チケット駆動開発にGTDの概念を導入する: プログラマの思索

企画や営業に携わる人は、日々のTODOリストがとても重要だ。
その日にやるべき作業を分刻みで次々に処理していかざるを得ない。
その時に、GTDのような考え方があると、タスクに押しつぶされるようなプレッシャーやストレスから逃れることができると思う。

GTDの良さは、Inboxというバックログのような概念があること、日次レビューや週次レビューのように定期的に検査するイベントを作ってフィードバックする仕組みがあることだと思う。
つまり、GTDはタスク管理のアジャイル版に思える。

そのやり方をRedmineへ適用してみようと思うのはとても自然だ。
GMailでもToDO管理できる機能があるけれども、関連付けができないし、マイルストーンや納期の単位でグループ化するのが面倒。

上記の例で面白い特徴はいくつかある。
ステータスに「Inbox」「いつかやる」「Done」「ToDO」「仕事」「プロジェクト」などのタグを入れていること。
個人的には、タグはRedmineチケットのカテゴリに使い、ステータスはタスクの状態に一致させる運用の方が整理しやすいだろうと思う。

タスクの期限を見るためには、カレンダーを使えばいい。
カレンダーを見れば、今日はどのタスクが完了しなければならないのか、どのタスクが始まるのか、がひと目で分かる。

また、朝8時にやるべきタスクをグルーピングして、リマインダー発行メールを送るようなこともできる。
チケットのウォッチャー機能を使っても面白いかもしれない。

またRedmineチケットに登録しておけば、iPhoneやAndroidのようなスマートフォンでいつでもどこでも参照したり更新できる。
色んな使い道があるはず。

| | コメント (0)

2013/01/20

オフショアプロジェクトマネジメント

標準テキスト オフショアプロジェクトマネジメント 【PM編】」を読んだ。
こまごまとした文章よりも、コラムや経験に基づく具体例の方が面白い。
オフショア開発に携わった経験がある人ならば、うんうんあるよ、と頷く箇所が多いのではないだろうか?
一部のコラムを抜き出して、感想をラフなメモ書き。

【1】自社のオフショア子会社よりも外部の協力会社の方が安いとしたら、どちらを選択するか

あなたはオフショアPMOで海外発注数量の数値目標を持つ責任者とする。
ある日、顔なじみの協力会社の営業マンがやってきて、自社の3年前に設立したオフショア会社よりもはるかに安い人月単価を提案してきた。
そもそも、あなたの会社のオフショア社内単価は随分高めに設定されている。

あなたは、勝手を知る協力会社の提案を受け入れるか?
それとも、オフショア発注数量を数値目標を達成するために、赤字覚悟で自社のオフショア会社を社内プロジェクトへ展開し続けるか?
あなたはどちらを選択するか?

このコラムでは、日本のSIですらも「赤字なら自社のオフショア会社を使わない」人が過半数を超えたらしい。
つまり、人月単価の高い自社オフショアよりも、外部の協力会社を使う方が合理的だ、という判断を下している、と。
同じ質問を米国人マネージャにしたらどうなるか?
おそらく、「グループ企業とはいえ、赤字なら絶対使ってはいけない。コスト競争力のある外部の協力会社を積極的に使うべきだ」という回答になるだろう、と。

このコラムで言いたいことは、企業統治における経営指針に従って判断すべき、ということ。
経営方針として、オフショア子会社を育てるために最初は我慢して使うべきなら、それに従うし、取引基準は経済合理性に基づいて判断すべきなら、品質が同じなら安い方を選択することに従う。

個人的には、この質問では、日本のSIではオフショアPMOと現場のプロジェクトマネージャの間で緊張関係が発生し、一つ上の階層のプロジェクトオーナーがトップダウンで判断する事例が多いのではないかと思う。

オフショアPMOが数値目標を持たされた責任者であるがゆえに、赤字であろうとも、彼は自分の職務を果たそうとするだろう。
逆に、高い単価の技術者を押し付けられる現場のプロジェクトマネージャは、赤字にならないようにするために、品質が同じで単価の安い外部の協力会社を選択肢したいだろう。
つまり、社内では、それぞれの現場責任者が個別最適の選択をするうちに、会社全体としては全体最適とならない事例が多発する時が多いだろうと思う。

【2】アジャイル開発とは名ばかりで、実態は手戻り多発の反復作業

オフショアとアジャイル開発の親和性を調べてみると、実はアジャイルとイテレーション(反復)の意味を誤解していた事も少なくないらしい。
つまり、見切り発車と手戻り多発が慢性化した状態をアジャイル開発と呼んでいただけだ、と。

個人的には、地理的にチームが分断されたオフショア開発では、上流工程が自社の社員、下流工程が海外オフショアのように工程ごとにさらに分断されるために、工程を一体化して小規模リリースしながら作っていくアジャイル開発とは、水と油だと思う。

【3】オフショア拠点では品質保証スタッフは不人気

多くの海外オフショア会社では、プロジェクト実行部隊から独立した監査チームが計画的にプロジェクトを監査する。
CMMI導入に熱心な企業ほど、SQAを設置して品質管理を実践している。
しかし、中国の開発現場では、品質保証業務に人気がなく、プロジェクト監査が弊害化しやすい、と。

理由は、中国人IT技術者にとって品質保証業務は、キャリアとして確立されておらず、仕事ができない人が配属されるイメージがあるから、と。
実際、品質保証業務では、プログラミングよりもひたすら定量化したデータをまとめて報告書を作るドキュメント作成作業がメインだろうから。
すると、オフショア会社へ発注するSIにとっては、海外オフショア会社のCMMIのアセスメント(評価)認定が本当に保証されているのか、見極める必要がある、と。

品質管理は日本のお家芸。
その理由は、日本では製造業をモデルとしてソフトウェア工場を目指していたからとも言える。
しかし、日本のソフトウェア工場の実態は、開発プロセスの一部が標準化された部分最適化の状態に過ぎない、と。
すると、そのやり方が海外のオフショア発注で通用するとは限らない。

【4】「日本人プログラマ」は不要と公言してはばからない日本人上司の自己矛盾

大手SIの金属30年の部長は「付加価値の低い下流工程は全て外注するから我社にプログラマはいらない」と公言する。
しかし、ベテラン日本人管理職のキャリアをヒヤリングすると、彼らはかつては泥臭いプログラミングで技術を鍛え、OJTをこなしながらマネジメントスキルも身に付けていった人が多い。
しかも一部の達人は、今なお現場でコーディング作業に従事し、誇りを持って仕事をしている、と。

でも、彼らが管理職につくと、若い従業員にはプログラミング技術よりも上流設計や顧客との折衝能力を期待するようになってしまう、と。
自分たちは泥臭いプログラミングでキャリを築いた事実を棚に上げて、若手技術者にはプログラマ不要論を説教する矛盾がある、と。
大手SIの管理職にいるベテラン社員は、おそらく会社で育てられた最後の情報技術者だからこそ、若手技術者はオフショア開発に消極的になり、抵抗勢力になる、と。

個人的には、技術者がマネジメント技術を身につけることは重要と思うけれども、ライン管理職になって、プログラミング技術に疎くなり、現場のプロジェクトを回す技術すら忘れてしまうのは危険だと思う。
昔にCobolとメインフラームで腕を鳴らした経験があっても、スマートフォンやタブレット上でアプリを作る開発や、JavaやRubyを使った業務系Webシステム開発では、設計のボトルネックの目利きすらできないだろう。

また、現在の日本のSIの主流の開発アプローチは、「日本人による日本語で書かれた日本人顧客のための」プロジェクト運営に最適化されている垂直統合型モデルだ、と。
この手法は、「大手SIは上流工程のみ担当し、付加価値の低い下流工程は協力会社や海外オフショアに任せる」水平型モデルと、そもそも水と油だ。

日本のSIのオフショア開発で成功例が少ない理由は、従来の日本の製造業をモデルにした「職人のすり合わせ」という垂直統合型モデルに、オフショア会社の社員を取り込めていないからだろうと推測する。

【5】オフショアでいきなりプロセス改善は難しいから、まずは整理整頓から

あるオフショア会社へトヨタ生産方式の5Sを導入しようとして失敗した。
失敗の原因は「ISO導入の失敗」と同じ。
そこで、中国製造業の事情に明るい専門家から、中国の職場でいきなり躾(プロセス改善)の展開は難しいので、まず整理・整頓から着手してはどうか、と提案した、と。
整理整頓を持続させるには、改善前(Before)と改善後(After)を記録し、PDCAサイクルを回していくことが大事だ、と。

プロセス改善の導入は、オフショアだろうが日本国内だろうが、経験上難しいと思う。
今までの価値観を否定し、新しいやり方に慣れようという気持ちが皆になければ、そもそも続かない。
そして、少しずつであっても成果がでなければ、モチベーションも維持できない。

日本で生み出されたプロセス改善の技法は基本的にはPDCAサイクルと職人のすり合わせが中心にある。
従業員の価値観を平準化し、価値観を揃えることで、垂直統合型モデルで成功してきた。
でも、そのやり方で果たしてうまくいくのだろうか?
3年先のマーケットすらも見えない現代で、多様性を認めない職場でやっていけるのか?

| | コメント (0)

2013/01/19

Scrum本が最近続々出てきた

最近になって、日本の出版界からScrum本が続々できているのでメモ。
日本でアジャイル開発が注目されている今、日本人がスクラムを翻訳紹介ないし実践例を紹介するのは、アジャイル開発の普及と、その誤った運用を避けるためにも、とても重要だと思う。

【1】今最も注目の本は、平鍋さんの「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」かな。
Scrumの概念を生み出した原論文を書かれた野中郁次郎さんとの共著。
まだ買っていないので、デブサミで読んでみようと思っている。

【2】昨年後半は、江端さん(@ebacky)が「スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発」と「アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理」を翻訳出版された。

2冊とも読んでみて、僕自身の好みは「スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発」の方が興味深かった。
僕が業務系システム開発に関わっているので、ゲーム業界のスクラム実践例よりも、スクラムの中で最も重要な役割であるプロダクトオーナーの特徴やアンチパターンが書かれている方に目が向いたから。

スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発」は頁数は少ないものの、プロダクトオーナーがどんな仕事をしていて、どんなスキルが必要なのか、を的確に説明していると思う。

【3】@ryuzeeさんもスクラム本を出版されれるらしい。
おそらく日本のスクラム業界で最も実戦経験の豊富な方なので、日本の現場での実践例が紹介されているかなと期待しています。

Scrum Boot Camp Premiumを開催します(デブサミ特別編 2/14) | Ryuzee.com

スクラムチームではじめるアジャイル開発 SCRUM BOOT CAMP THE BOOK

【4】デブサミ2013で、僕が個人的に注目しているのは、和智さんが講演される「【15-A-5】人が作るソフトウェア ~今『組織パターン』を読む意味~:Developers Summit 2013」。
Coplien著の『Organizational Patterns of Agile Software Development』の日本語版を今も翻訳されていて、もうすぐ出版されるのではないかと期待しています。
(和訳は「アジャイルソフトウェア開発の組織パターン」になるのでないかな?)

Coplienと言えば、94年というアジャイルの初期の時代に「生成的開発プロセス・パターンランゲージ」という優れたパターンの論文を書いたことでも有名。
この論文にあるパターンは、XPやScrumにも大きな影響を与えていると言われている。

その後、『Organizational Patterns of Agile Software Development』や「Lean Architecture: for Agile Software Development」のように、組織パターンやリーンアーキテクチャなど、今後のアジャイル開発が発展していく指針のような内容の本を出版されている。
誰か早く2冊とも翻訳して欲しいと思っていたので、とても期待している。

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

| | コメント (0)

2013/01/18

Facebookはセルフブランディングの最強ツール

Facebookバカ」を立ち読みして思ったことをメモ書き。

【参考】
Twitterは最速のメディア: プログラマの思索

【1】Facebookは単なるSNSとは違う意味がある気がしている。
その違和感は「Facebookバカ」の下記の文章から、ようやく分かった。

(引用開始)
大事なことなので繰り返しますが、私が記事を投稿するときの意識と基準は、「自分は、どういう人として覚えてもらいたいか」ですから、フェイスブック上で私の投稿を読んでくれている人に私の興味がダイレクトに伝わるように投稿ネタを選んでいます。(P.130)
(引用終了)

Facebookでコメントする時、普通は自分の思いを書く時が多い。
でも、Facebookをプライベートな人間関係のコミュニケーションツールとして使う以上のことをしたい場合、自分はどんな人間として覚えられたいのか、を意識した方がいい。
否定的なコメントを残すほど、書いた人のイメージは悪くなり、人が離れていく。
だから自然に投稿したコメントは、明るい内容、役立つ内容に変わっていく。

すると、Facebookは、自分という人間を世界中に発信する放送局に変わる。
つまり、Facebookはセルフブランディングのための強力なツールなのだ。

【2】Facebookのタイムラインは、自分の発言が時系列に流れているだけだが、書いた本人の価値観に基づく投稿記事になる。
新聞のニュースなら、時系列に政治・経済・スポーツなどの記事が流れていくのと同じ。
投稿した人のファンならば、その人の記事を追いかけるだけで、その人が書いたニュースが分かる。
投稿した人がアルファブロガーだったり、オピニオンリーダーだったり、スポーツマンや女優などならば、その人の行動なり言動に敏感になるだろう。

【3】でも、普通の一般人でも、Facebookを使えば、HPよりも強力な営業ツールになる。
その例として下記があげられる。

妻のパン屋の悩み事をFacebookページで解消したお話 - give IT a try

Facebookには以下の利点があげられるだろう。

実名のユーザが書いているので、信用できる。
情報をHPやBlogよりも気軽に書ける。
「いいね」ボタンでPVに近い指標をフィードバックしてもらえる。
Twitterほどではないが、リアルタイム性がある。
「http://www.facebook.com/username/」 というURLが作れるので、自分を簡単に識別できるアクセス方法が得られるので、集客力につながる。

すると、普通の一般人でも、Facebookを使いこなせれば、セルフブランディングになる。
つまり、自分という人間の価値が優れているならば、自然に人が集まり、そこから市場が生まれる。

特に、コンサルタントという職種の人達は、Facebookのようなセルフブランディング・ツールは必須だろう。
コンサルタントは自分が持つ知識やノウハウを売り物にするけれど、今の時代、○○コンサルタントという呼び名は星の数ほどあり、信用できるかどうか不明だ。
そのため、信用、そして集客力が不安の源泉になる。

でも、Facebookでコンサルタントとしての価値の一部を公開して信用してもらえれば、人が集まり、マーケットが出来上がっていく。
コンサルタントが出版した自分の本と一緒に宣伝する理由の一つが、著作物という信用性のあるもので保証されたいという動機があるからだろう。

その意味では、今は普通の一般人でも、何らかの価値を発信できる能力さえあれば、その集客力を利用して生活していくことができる時代になったと言える。

【4】似たような話として、BlogがSNS時代になって再発見されたという意見もある。
Blogも自分放送局のツールであるが、FacebookやSNSと違う利点は、蓄積した記事というログはGoogleの検索エンジンによってPageRankで再利用されて、どんどん価値が上がっていく点。
必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える“俺メディア”の極意」の本でその意義が詳しく書かれている。

【読了】必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える"俺メディア"の極意 著者:コグレマサト するぷ : AverageのHobby Blog

本が付箋だらけになっちゃった「ブログ運営テクニック100」 | サラリーマンプラス

惜しみなく披露! ブロガー必読の「必ず結果が出るブログ運営テクニック100」(Excite Bit コネタ) - エキサイトニュース

例えば、倉貫さんが社長のソニックガーデンさんもBlogやTwitterなどを積極的に使われているが、従来の営業スタイルを使わずともBlogやSNSを上手く使えば影響できることを説明されている。

急がば回れ、売り込まないソニックガーデン流営業スタイル - SonicGarden 株式会社ソニックガーデン

BlogやFacebookで記事をリアルタイムに公開する方が、より個人的な情報がオープンになることで親近感を持つし、より顔が見えやすくなる。
そして、「どんな人として覚えられたいのか」「どんな会社として覚えられたいのか」という問いを自然に実行しているとも言える。

【5】この言葉は、ドラッカー著「プロフェッショナルの条件」にあるシュンペーターとの話を連想させる。

人と組織と、fukui's blog ドラッカー

(引用開始)
(ドラッカーの)父はにこにこしながら。「ヨーゼフ(・シュンペーター)、自分が何によって知られたいか、今でも考えることはあるかね」と聞いた。シュンペーターは大きな声で笑った。私も笑った。というのは、シュンペーターはあの2冊の経済学の傑作を書いた30歳ごろ、
「ヨーロッパ一の美人を愛人にし、ヨーロッパ一の馬術家として、そしておそらくは、世界一の経済学者として知られたい」
と言ったことで有名だったからである。
彼は答えた。
「その質問は今でも、私には大切だ。でも、むかしとは考えが変わった。今は一人でも多く優秀な学生を一流の経済学者に育てた教師として知られたいと思っている。(中略)私も本や理論で名を残すだけでは満足できない年になった。人を変えることができなかったら。何にも変えたことにはならないから。」
(引用終了)

(引用開始)
シュンペーターはこの会話の五日後になくなった。ドラッカーは、シュンペーターのこの言葉から3つのことを学んだと言う。それは、
・人は何によって知られたいかを自問しなければならない。
・問いに対する答えは、成長に伴って、変わっていかなければならない。
・本当に知られるに値することは人を素晴らしい人に変えることである。
(引用終了)

「どんな人として覚えられたいのか」の問いを常に考えながら、Facebookに投稿するのは良いかもしれない。

| | コメント (0)

2013/01/15

アジャイルはパターンムーブメントに戻るのか

今日明日はScrum Alliance Regional Gathering Tokyo 2013が開催されている。
参加できていないけれど、セッション概要やTwitterを読みながらラフなメモ書き。

【元ネタ】
Scrum Alliance Regional Gathering Tokyo 2013 ≫ セッション概要

2013/01/16(水) Scrum Regional Gathering Tokyo 2013 (2日目以降) #sgt2013 - Togetter

2013/01/15(火) Scrum Regional Gathering Tokyo 2013 (開催直前〜初日分) #sgt2013 - Togetter

個人的には、Coplien氏の講演が聞きたかった。
Coplien氏と言えば、1994年に書き著した論文「生成的開発プロセス・パターンランゲージ」が有名だろう。
XPが生まれる前、Scrumが有名になる前に書かれたこの論文には、アジャイル開発の概念の源流が感じられる。
そして、彼は今Scrumのパターン作成に取り組んでいるらしい。

Scrum Alliance Regional Gathering Tokyo 2013のセッション概要を見ると、開発プロセスをパターンカタログとして表現しようとする試みがチラホラ見える。
その意図は、下記の平鍋さんのBlogに書いてあるとおり、開発プロセスをプロセス標準化として使うのではなく、パターンカタログとして抽出したプラクティス集として表現しようとする試みのように思える。

SEMATの最初の本が出ました。:An Agile Way:ITmedia オルタナティブ・ブログ

ソフトウェア工学のエッセンス: SEMATカーネルの適用 - Project Hews by 木南英夫

その発想は、開発プロセスを知識体系のような演繹的な体系として捉えるのではなく、現場の経験知から帰納的な体系として吸い上げて、プラクティスの集合として捉え、他の現場へ実践できるようにヒントを与える方法だと思う。

僕はこういう帰納的な発想が好きだ。
現場の経験知を元に、そのアイデアを抽象化して一つの体系としてまとめていく方法が好きだ。
何故なら、帰納的に抽出された体系は、現場の実例という証拠があるので、机上の空論ではないし、その有効性や限界を的確に説明できるからだ。

チケット駆動開発も同様に、一つのパターンカタログないしパターン言語として捉えることができると思っている。
それについては色々考えてみる。

パターン、Wiki、XPは良書: プログラマの思索

パターンランゲージの形式と正当性: プログラマの思索

組織パターンとプロセスパターン: プログラマの思索

【追記】Scrum Gathering Tokyo 2013のセッションにある鷲崎さんのスライド資料が公開されていたのでリンクしておく。

Twitter / Hiro_Washi: #sgt2013 パターンマイニング資料+結果を掲載しました。参考まで。パターン候補一覧: 経験者の活用、とりあえずやっちゃえ、百聞は一見にしかず、とりあえずやってみる、振り返りは大事、目標達成、チキンハート、安全度まで失敗。http://slidesha.re/V6P5VM

【追記2】
下記の記事に引用されていたのでリンクしておく。

パターンっていうのは、計算機工学の考え方の基本なんだよ! - ウィリアムのいたずらの開発日記

| | コメント (0)

2013/01/14

groovyでredmineを操作する

groovyでredmineを操作する方法が書かれていたのでメモ。

groovyあれこれ: groovyでredmineのプロジェクトを作成する

他にも、Go言語でRedmineを操作できるらしい。

Big Sky :: コマンドラインからredmineを扱える「godmine」作った。

APIキーさえあれば、HTTP経由でRedmineを操作できるから、どんなプログラミング言語でもやろうと思えばできる。
JavaでもC#でもRubyでも同じ。
所詮はJSONを操作するだけだから、そう難しくないだろうと思う。

Rest api - Redmine

Redmine .Net APIであるredmine-net-api: プログラマの思索

redmine-java-api: プログラマの思索

| | コメント (0)

2013/01/13

groovyの可能性

JVM上のスクリプト言語groovyに興味を持ったので、アイデアをラフなメモ書き。
アイデアを書きかけ。

【参考】
書評:プログラミングGroovy - Digital Romanticism

【1】普通のUnixサーバーならば、Javaは当たり前のようにインストール済み。
JVMの最大の利点は、OSに依存せず、一つのプログラムでどこでも動かせること。
Windowsサーバーならbat、Unixサーバならシェルのように使い分けることはあまりしたくないから。
ちょっとしたプログラムをすぐに書いて、どこでも動かせるようにしたい。

本来ならPerlが最強なのだが、Javaが業務系Webシステムで開発言語の筆頭となったからには、JVM上で簡単にスクリプト言語が動かしたい欲求は多い。
JRubyもそうだし、Groovyもそう。
Groovyの使い道をいくつかあげてみる。

【2】ビルドスクリプトで使う。
使い道は、Antの代用。
Antはとても枯れた技術だが、XMLで書くのは面倒だし読みにくい。
Groovyなら、XMLの読み込みも、XML生成も簡単。

実用的な Groovy: XML を作成し、構文解析し、容易に扱う

Groovyで書かれたビルドライブラリGradleを使う方法もある。
また、Jenkins上でGroovyが使えるので、Jenkinsからビルド結果を取得したり、Jenkinsを操作して一連のビルド手順をGroovyで自動化する方法もある。

【3】内部DSLとして使う。

進化するアーキテクチャーと新方式の設計: Groovy で DSL を作成する

実用的な Groovy: Java プログラマーのための DSL としての Groovy

多い使い道としては、既存言語から他の言語へコンバートして自動生成すること。
例えば、Cobolプログラムから、カーソルを取り出して、Javaとのインターフェイスにマッピングすること。

あるいは、細々とした自動化スクリプト。
例えば、ApacheログやTomcatログ、メールサーバーのログから、エラー処理を検知して集計したり、月末にSLAを顧客報告するために、インシデント管理の情報を集計するなど。

あるいは、既存プログラムから、DBスキーマや状態遷移図を生成するなど。

GroovyやRubyのような言語の方が正規表現やファイル操作が強いので、便利なはず。

【4】テスト駆動開発への応用。
TDDはもはや当たり前の概念になったが、振る舞い駆動開発(BDD)へ発展させるアイデアもある。
その時、GroovyのSpockを使えば、RubyのRSpecのように、受入テストケースがそのままプログラムになるように書ける。

気になってたSpockを試してみた - No Programming, No Life

ビルド・リリース自動化への足掛かりとしてのGroovy・Gradle・Spock|サイバーエージェント 公式エンジニアブログ

平鍋さんは、アジャイル開発の観点からソフトウェアの品質特性として、テスト容易性という概念を提唱した。
そのアイデアには、そもそもテストはスクリプト言語のような柔らかい言語の方が向いている、と指摘されていたように思う。
だから、CやJava、あるいはCobolのような硬い言語は、RubyやGroovyなどで自動テストした方が簡単かもしれない。

【5】他のフレームワークへの応用もある。
RailsのGroovy版であるGRails。
Groovyのデスクトップアプリ作成ライブラリであるGriffon。

第31回 Grailsライクにデスクトップアプリケーションを構築する「Griffon」:本格派エンジニアの工具箱|gihyo.jp … 技術評論社

Grailsの基本を知ろう (1/6):CodeZine

プログラミングGROOVY」には、他にも面白そうな使い道が書かれているので、色々試してみる。

| | コメント (0)

2013/01/12

Mercurialに取り込まれたコミュニティ由来の機能一覧

入門Mercurial」の著者の藤原さんが、Mercurialに取り込まれたコミュニティ由来の機能一覧を公開されていたので、リンクをメモ。

【元ネタ】
Mercurial に関するコミュニティ由来の成果(2012年版) - 彷徨えるフジワラ

とても素晴らしいなあと思う。

| | コメント (0)

2013/01/07

アジャイルの左翼は開発者自身の能力向上を前提にしている

僕が尊敬する@yusuke_arclampさんが、アジャイルと組織論の関係について記載している記事を見つけたのでメモ。
ラフなメモ書き。

【元ネタ】
アジャイルって組織論ですよね(DevLOVE2012ご報告) - arclamp

アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:ITmedia オルタナティブ・ブログ

なんで全員にリーダーシップを求めるの? - Chikirinの日記

【1】@yusuke_arclampさんがずっと講演で話されている「アーキテクチャとマネジメントのギャップ」については、僕自身も別の文脈で腑に落ちない部分を感じている。
現代は、@yusuke_arclampさんが言うように、技術革新が速すぎて理論が追いつかず、実証主義的にシステム開発のあるべき姿を追い求めようとしている時期なのかもしれない。

【2】アジャイルが組織論に行き着くという話に関連して、Scrumの自己組織化の発想は、プロマネがチームの全てを管理するのではなく、メンバー自身が自己管理した方が上手くいくというものだと思っている。
そのために、Scrumではメンバーに軍隊のような厳しい規律(ディシプリン)をメンバーに要求するし、その責任と采配をメンバーに預ける。

【3】似たような話として、なんで全員にリーダーシップを求めるの? - Chikirinの日記では、何故アメリカでは特に個人にリーダーシップを求められるのか、という話がある。
リーダーシップを持って活動した経験がある人ならば、組織やチームにおいて、自分がどのように振る舞ってチームに貢献すればいいのか、という姿をイメージして自発的に行動できる。
リーダーシップを持つ人は、そもそも他人から指示待ちで動く必要もないのだ。
逆に、リーダーシップを持って活動するという経験のない人は、組織の中でわがままに振る舞うか、指示待ち人間になってしまう。
組織が今必要としていること、今の自分の能力提供できることについて、比較検討して行動していくことがイメージできないからだ。

【4】また、似たような話として、「フレームワークを使いこなすための50問」では、プロマネが忙しすぎて組織運営のボトルネックになったり、業務が専門化しすぎてプロマネが部下の仕事内容の全てを理解できなくなっている危険を解決するために、2つの方法を試した話がある。

ある企業では、業務内容を形式知化するために、マニュアル化を推進した。
マニュアルを中心にプロマネや新人がノウハウを共有できると思ったわけだ。
しかし、失敗したとのこと。
理由は、高度化・専門化していく業務のスピードにマニュアル整備が追いつかず、膨大なマニュアルが時代に合わなくなりがちで、結局使われなくなった、とのこと。
マニュアル改定が仕事になってしまい、本来の業務の効率化やノウハウ共有に至らなかったわけだ。

別の企業では、プロマネになる一歩手前の3~6年目の若手層に対し、プロジェクトマネージャ化を進める対策を実施した。
つまり、プロマネが各技術の専門家である部下の内容を理解するのではなく、部下がプロマネとして自分の進捗管理を行い、プロマネの意を汲み取って自発的に行動できる環境を整えたわけだ。
すると、この方法は成功した、とのこと。
理由は、部下自身でタスクの抜け漏れをチェックでき、妥当な工数見積を自分自身で行い、作業を制御できるようになった。
更に、部下自身で各タスクのゴールを明示でき、自身のリスクをマネージャに明確に提示できたため、マネージャは、リスクを自ら探してリスクの背景にある業務を理解する必要もなく、提示されたタスクとリスクで判断できるようになった、とのこと。

【5】いずれの話でも、メンバー自身がマネジメントスキルないしリーダーシップの能力を身に付ければ、管理者と作業者という関係ではなく、作業者自らが自分で判断して行動し、自分の能力や作業範囲を超えるリスクはマネージャに判断や指示を仰ぐという関係へ変化して、組織自身が活性化することを示している。
開発者自身のレベルをお互いに高め合うような環境が必要ではないか?

多分、アジャイルの左翼が本当に目指しているものは、そのような環境づくりではないかと思っている。

| | コメント (0)

2013/01/06

ソフトウェアの複雑さはどのように制御すべきか?

ソフトウェアやシステムのアーキテクチャ設計では、ソフトウェアの宿命と言える複雑さをどのように制御すべきか、という根本問題を孕んでいる。
考えたことをラフなメモ書き。

【1】「スティーブ・ジョブズ II」の自叙伝では、ジョブズが携帯音楽プレーヤーのあるべき姿を述べている。

(「スティーブ・ジョブズ II」から要約)
iPodを本当に使いやすくするには、iPodでできることを制限する必要がある。
iPodで制限した機能(プレイリストの作成など)はコンピュータ側のiTunesに持たせる。
リオのような機器があんなに役立たずなのは複雑だからだ。
アップルの場合、iTunesソフトウェアとiPodという形でコンピュータと機器を協力させられるから、複雑な部分をあるべき場所(iTunesソフトウェアとそれを操作するMac)に持っていけた。

ジョブズは、ユーザが触れるiPodは極力シンプルにして、PCで操作するiTuneソフトウェアに複雑さを移行しようとした発想で開発している。
そのおかげで、ユーザはワンクリックないし簡単な操作だけで、音楽を簡単に聞ける。
プレイリストを作ったり、曲を同期したり、メモや写真を同期する処理は、PC上で操作した方が簡単だ。

Android携帯が使いにくいのは、iTunesのようなソフトウェアがないために、必要な情報の同期処理が難しい点もあるのだろう。
でも、クラウド経由で同期する方法もあるから、今後変わるかもしれない。
とは言え、ユーザが触れるインターフェイスはシンプルにして、複雑さを別の場所へ移すという発想で設計している。
その思想があるからこそ、複雑なハードウェアを作る必要がないので、iPhoneやiPadなど次々に新製品を作り出すことができたわけだ。
最近流行しているアジャイルUXという考え方も、この発想と似ているかもしれない。

【2】渡辺幸三さん著「販売管理システムで学ぶモデリング講座」の227頁では、「複雑な機能と複雑な業務のバランス」節で、ソフトウェア設計の複雑さをどこに配置すべきか、という渡辺さんの観点が書かれている。

例として、帳簿在庫と実在庫の差異が発生した時、出荷指示を画面にどのように表示すべきか、という問題が提示されている。
状況としては、例えば、月末に倉庫で、小売店の商品や工場の製品を実地棚卸ししてみたら、帳簿(システム)と実際の在庫数が違っていた時に相当する。
原因としては、間違って記録していたり、繁忙期の在庫引当や仕入れの記録を忘れていたりする時もあるだろう。
あるいは、生鮮食料品のように腐ってしまったり、醸造酒や醤油などのように保管していたら蒸発して減ってしまった場合もあるだろう。

販売管理システムで学ぶモデリング講座」では2つの方法が提示されている。
一つは、実棚で差異が発生したならば、出荷予定を取り消して、在庫数を確定させるように修正した後、もう一度出荷指示を作り直す方法。
これは、実棚の差分を認めず、理論在庫と実在庫を一致させる作業を重視する方法。

もう一つは、実棚の差異があっても、ユーザの指示次第で、システムが在庫数を調整して都合よく出荷予定を作り直す方法。
これは、実棚の差分を認めて、システムが在庫確定よりも出荷指示を優先させる方法。

販売管理システムで学ぶモデリング講座」では前者の方法を勧めているが、現状の業務設計では前者が必須要件だ。
何故なら、在庫数が間違っているまま業務を進行させるということは、商品有高帳引いては貸借対照表の数字を狂わせることにつながり、内部統制や会計監査でNGを食らう可能性があるからだ。

販売管理システムで学ぶモデリング講座」に説明があるように、実在庫と理論在庫が一致するような運用品質を求めるように、ユーザ企業の担当者が業務のレベルを高めるように持っていくべきだ。
そうでなければ、いつまで経っても、日々の在庫を確定させる動機がなくなってしまう。
小売業ひいては製造業における業務管理の基本は、在庫のズレをなくすように運用すること。

在庫管理がザルでは、自分たちが今どれだけの資産を管理しているのか、を理解できないことにつながる。
普通は、倉庫の棚に置かれた商品や製品が散らかっていれば、数えることすら手間がかかる。
ここから、トヨタ生産方式における5Sの整理整頓などの改善活動が生まれるのだろう。

この話に関して、システム設計では、データモデルと業務モデルを複雑にして、機能モデルを単純化する方針を「販売管理システムで学ぶモデリング講座」では勧めている。
理由は、機能の開発・保守はコストがかさむし、複雑すぎる機能は業務や体制の硬直化を招くから、と。

ここでは、機能モデルは画面などのユーザインターフェイスを指すと思われる。
つまり、ユーザが触れる画面は極力シンプルにしておき、めったに起きない状況に対処するための複雑な運用はマニュアルに書いて参照するようにした方がコストが安く済む。
年1回の例外的な運用は、手運用でカバーするように手順化しておけば、無駄にシステムを作って複雑化する必要もない。
この辺りはシステム開発と運用業務のトレードオフかもしれない。

【3】「販売管理システムで学ぶモデリング講座」では、システムが宿命的に負うべき複雑性をいかに分散して全体のコストを最小化するかというBPR的な観点が必要と述べている。
iPod開発にしても、業務システム設計にしても、ユーザが触れるインターフェイスは極力シンプルにして、システムの複雑さはソフトウェア内部に押し込めてしまう方法を勧めている。

システムの複雑さは、エントロピーみたいなものであり、複雑さ保存の法則みたいなものがある。
つまり、システムの複雑さは減らすことができるわけではなく、常に一定であるがゆえに、その複雑さをどこへ配置して、ユーザとシステムを一体化した世界でコストを最小化し、価値を高めるか?という問題をいつも孕んでいる。
全体最適という観点は、複雑さの再配置(これこそがBPRかもしれない)という見方も含んでいると思う。

| | コメント (0)

2013/01/04

PMBOKにおけるプロジェクトファイナンスの考え方

PMBOKを勉強する時、正味現在価値(NPV:Net Present Value)や内部収益率(IRR:Internal Rate of Return)という概念が出てくる。
この意味が今までずっと分からなかったけれども、「ざっくり分かるファイナンス」を読んでようやく意味が分かったのでメモしておく。
但し、自分の理解で書いているので、以下のリンクや「ざっくり分かるファイナンス」を参考にすること。

【参考】
プロマネのひとりごと ざっくり分かるファイナンス

「ざっくり分かるファイナンス」はもっと評価されていい|ぶっちゃけ税理士・岩松正記のブログ

「道具としてのファイナンス」石野雄一/著 | ZUU-ONLINE

PMBOKツールと技法: PMへの道

ASCII.jp:第3回 キャッシュの時間的価値を反映したプロジェクトの経済的評価方法|公式ガイドブックだけでは不十分!? PMP資格試験対策

【 PMP ・ Project+ 】正味現在価値(NPV)について | イープロジェクトPMP(R)講座のブログ

ASCII.jp:第2回 プロジェクトの経済的な価値を比較する問題を解く|公式ガイドブックだけでは不十分!? PMP資格試験対策

PMP試験: 暗記すべき計算式のまとめ ? 最短5週間でPMP資格を取得する!

【1】PMBOKでは最初に、そもそもどの新規案件(プロジェクト)を選択すべきか、という問題が出てくる。
赤字が前提になっているシステム案件は、よほど経営戦略上重要でなければ、取るべきではないのは当たり前。
すると、会社のリソース(エンジニアや営業マンなどの人員、PCなどのハードウェアなど)をどのプロジェクトに投資すれば、売上と利益が得られるのか、という基準が欲しくなる。

この時、以下の概念を使って、初期投資額(人件費だったり、サーバー費用だったり)とプロジェクトから得られる収益を予測して、どれくらいのリスクを見据えれば投資すれば良いか、判断する。

将来価値(FV:Future Value)
現在価値(PV:Present Value)
正味現在価値(NPV:Net Present Value)
内部収益率(IRR:Internal Rate of Return)

おそらく、部長クラスになれば、毎年の期首になれば、予算計画を立てて、売上と利益を宣言しなければならない。
そして、期末になれば、部の実績を経営者から評価される。
彼らの仕事の殆どは、おそらく上記のような計算をExcelマクロを使って、毎日やっているのだろうと推測する。

【2】上記の概念を「ざっくり分かるファイナンス」に従って説明してみる。
ざっくり分かるファイナンス」の「第3章 明日の1万円より今日の1万円~お金の時間価値」と「第5章 投資の判断基準」を読めば良い。

PMBOKでもそうだが、基本は「Time is Money」。
その意味は「お金の価値は、お金をいつ受け取るかで変わる」ということ。
つまり、「明日100万円もらうよりも、今日100万円もらう方が価値がある」ということ。
実際、明日になれば、貸し手から本当に100万円戻ってくる保証はないのだから。

お金の時間価値には、将来価値(FV:Future Value)と現在価値(PV:Present Value)の考え方がある。
この2つの概念で重要なのが、複利の考え方。
つまり、定期預金における複利型の金利みたいなもの。

今、元本が100万円で毎年の金利が5%だとしよう。
(現在の日本はデフレなので、銀行の金利は1%もない。
余談だが、金利がゼロ又はマイナスになることは現実にありえるのだろうか?
理屈上は数字がマイナスでもありえるはず。
金融機関の人に聞いてみたいものだ)

すると、1年後には100万円 * (1+5%)=105万円になり、5万円の利益が得られる。
そのまま手付かずで置いておけば、2年目は、100万円 * (1+5%)^2年=110.25万円に増える。
つまり、複利にすれば、指数関数的に増えるから、利息が利息を生む。
この発想を将来価値に当てはめてみる。

将来価値は、今のお金を複利で運用したらどれくらいの価値になるかを表す。

FVとは|金融経済用語集

ここで、元金100万円を金利10%で3年間運用すると、将来価値(FV)はいくらになるか?
答えは簡単で、FV=100万円 * (1+10%)^3年=133万円になる。
つまり、FV=元金 * (1+利率)^年数 という公式になる。

この意味は、今の100万円と3年後の133万円の価値が同じ事を言っている。
つまり、3年後の133万円は、現在では100万円の価値しかないので、少なくなっている。
実際、将来は予測不可能でリスクがあるからその分、将来価値は高くなるのだろう。

逆に、現在価値(PV)を考えてみる。
1年後に110万円が得られるようにするなら、10%の複利で割り引けば100万円に戻る。
将来価値から割引率の分だけ割り引けば、現在価値(PV)が得られる。
つまり、PV=元金/(1+割引率)^年数 という公式になる。

ざっくり分かるファイナンス」で書かれているけれども、割引率はバーゲンの割引とは意味が違うことに注意。

時間管理術」でも将来の100億円は現在価値で評価すると、複利計算で割り引かれてしまうため、ずっと小さくなってしまう。
これが、財貨の時間価値だと言っている。
この複利の発想がなければ、現在価値、将来価値の意味は分かったことにはならないと思う。

すると、NPV(正味現在価値)法とは、初期投資の時点で、将来得られる収益や費用から現在価値を求める手法である。
NPVの意味は簡単で、NPV>0となるプロジェクトなら黒字なので、そのプロジェクトは実行する価値がある。
逆に、NPV<0のプロジェクトは赤字になるので、そのプロジェクトは実行する価値がない。

また、NPVを会社の各事業部単位に求めることもできる。
その場合、各事業部のNPVはまさに、その部の現在価値そのものになる。
NPV<0なら、その事業部は存在する意義がないと言えるかもしれない。
但し、管理部門のように売上が立たない部門はNPVは必ずマイナスになるので、一概にそうとも言えない。

割引キャッシュフロー法(DCF)は、NPV法を用いて、ある期間のプロジェクトの現在価値を評価する手法であり、ITプロジェクトの財務分析で使われているのだろう。

また、IRR(内部収益率)は、NPV=0となる割引率を指す。
つまり、IRRは、価値と価格がちょうど均衡するような割引率であり、損益分岐点みたいなもの。
ざっくり分かるファイナンス」では、IRRは銀行預金の金利みたいなものだ、というとても分かりやすい説明が書かれていて納得した。
例えば、IRR=3%のプロジェクトに投資することは、預金金利が3%の銀行に預けるのと同じ事だ、と。
この意味は、IRRが高いプロジェクトはその分リターンも大きいがリスクも高く、逆にIRRが低いプロジェクトはリスクは小さいがリターンも少なく旨みがないことを意味している。

【3】FV、PV、NPV、IRRのような概念は計算も難しそうだけれども、実はExcelの関数で簡単に計算できる。
実際、NPVやIRRの関数はExcelマクロの財務カテゴリに存在している。
以下を参考にすればいい。

正味現在価値の計算方法?NPV関数:Excel エクセルの使い方-関数/計算式-財務

IRR計算の方法?NPVからゴールシーク:Excel エクセルの使い方-関数/計算式-財務

IRR関数とNPV関数の関係:Excel エクセルの使い方-関数/計算式-財務

IRRの計算方法?IRR関数:Excel エクセルの使い方-関数/計算式-財務

Excelマクロを使って、「時間管理術」にあるプロジェクトXの正味現在価値(NPV)の例を計算してみる。
例えば、社運をかけた新製品プロジェクトXのキャッシュフローは以下の通りとする。

初期投資(研究開発費や工場の設備投資など):81億
1~5年目の生産収益:27億

この時、割引率=5%、10%、15%、20%でNPVを計算してみる。
Excel上で以下のセルに値を設定すれば、Excelマクロで簡単にNPVとIRRを計算できる。

C2=割引率
C5=初期投資額=-81億 (←初期投資なのでマイナス値を設定するのがミソ)
C6=1年目の収益=27億

C10=5年目の収益=27億

すると、以下のような値が出てくる。

プロジェクトXの正味現在価値=NPV(C2,C6:C10)+C5

内部収益率=IRR(C5:C10)=19.86%

つまり、割引率が約20%を超えると、NPVがマイナスになるので、プロジェクトXは赤字になる。
もちろん、割引率が50%のようにIRRを上回るほど、プロジェクトXの赤字額は指数関数的に増えていく。

また、上記のように、将来の収益が確実に27億円も確定するとは限らない。
最近の日本の家電メーカーがテレビなどに大金を設備投資して大幅赤字に転落したように、収益が減ればその分、IRRもNPVも減り、リターンも少なくなる。

なお、「時間管理術」ではリスクを失敗確率rで表し、割引率から以下の公式で求めている。

失敗確率=割引率/(1+割引率)

すると、プロジェクトXの失敗確率(リスク)は、16.57%になる。
このリスクを高いと見るか、低いと見るか、どう判断するか??

【4】IT部門の部長ならば、以上のような考え方をどのように使うべきか?
彼らは、過去数年の各プロジェクトの初期投資額(費用)や売上高、コストが分かっているので、現在の手持ちのプロジェクトの状況と、現在提案中ないし受注済みの案件に対して、DCF法を使って、プロジェクトのNPVを計算できる。
そうすれば、そのITプロジェクトで、どれだけ投資すれば元が取れるのか、判断できるはず。

でも、ITプロジェクトはそもそもリスクが非常に高い。
WF型開発は失敗案件が多いだろうが、アジャイル開発であっても、そのITプロジェクトの成功率は、他業界に比べれば低いだろう。
初めての技術、集めたメンバーは初めての人ばかりというチームならば、そもそも生産性はいきなり高くならないいはずだ。
逆に、そんなプロジェクトで成功すれば、新しい技術を使った経験が得られるし、専門家集団が一つのチームと化した経験も得られる。
リスクが高いからこそリターンも高いのがITプロジェクトの特徴なのかもしれない。

| | コメント (0)

2013/01/03

アーキテクチャ設計のアンチパターン集~44のアンチパターンに学ぶDBシステム

44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。
過去の経験上、あるあると思う箇所がたくさんあった。
感想をラフなメモ書き。

【元ネタ】
44のアンチパターンに学ぶDBシステム - give IT a try

あなたの現場にも必ずあるDBシステムの"悪い例"が満載!「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp

『44のアンチパターンに学ぶDBシステム』 - 虎塚

44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog(ブログ)

【本】SQLをしっかり学習したい人におすすめミック本。 | プラプラ式技術系 Access流!

【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとなる前に。。。 | プラプラ式技術系 Access流!

ソフトウェアの品質を学びまくる:【本】我がふり直すためのアンチパターン百花繚乱

【1】「44のアンチパターンに学ぶDBシステム」は以下の目次になっている。
アンチパターンは「アンチパターン―ソフトウェア危篤患者の救出」のパターンテンプレートに従っていて、とても分かりやすい。
幾つかのアンチパターンについて感想を書く。

PART1 DB&アプリケーション 編

Chapter1 データ設計
アンチパターン(1) ねずみ算
アンチパターン(2) 大河ドラマ「大作SQL」
アンチパターン(3) バケツ RDBMS
アンチパターン(4) 太っちょ(多くの列を持つ表)
アンチパターン(5) OLTPなのにSQLが重い
アンチパターン(6) DATE型の意識統一不足(時分秒など)
アンチパターン(7) データの保持期間を決めていない

Chapter2 アプリケーションコーディング
アンチパターン(8) 不適切なリトライの仕組み
アンチパターン(9) バッチにおいて適切に処理を分割していない
アンチパターン(10) バッチがリラン(再実行)できない
アンチパターン(11) 再利用しない(コネクションなど)

Chapter3 SQLコーディング
アンチパターン(12)バインド変数を使っていないSQL
アンチパターン(13)組み合わせ爆発
アンチパターン(14)臭い物に蓋をすると、もっと臭くなる
アンチパターン(15)データの量の暴力
アンチパターン(16)過ぎたるはなお及ばざるがごとし

Chapter4 計画にまつわるもの
アンチパターン(17) データの分身の術……どれが本物?
アンチパターン(18) DB連携地獄
アンチパターン(19) サーバー移行やバージョンアップでSQLのテスト軽視
PART2 インフラ 編

Chapter5 設計
アンチパターン(20) トランザクションスコープが不適切
アンチパターン(21) なんでもかんでもリアルタイム集計
アンチパターン(22) 詰まると接続が増えるアーキテクチャ
アンチパターン(23) 引きずられるアーキテクチャ
アンチパターン(24) 無関心(エラーが起こるまで異常に気がつかない)
アンチパターン(25) タイタニックシンドローム(絶対に沈まないと思って緊急時の備えを怠る)
アンチパターン(26) 自分で自分を診察する(自分を冷静に判断することはできない)

Chapter6 設定やテスト、運用
アンチパターン(27) 不法占拠
アンチパターン(28) 掃除しない部屋
アンチパターン(29) 振り返れば相手はいない
アンチパターン(30) 足元おろそか
アンチパターン(31) リソースのバランスが悪い
コラム● 限界性能テスト
PART3 プロジェクトマネジメント 編

Chapter7 DBシステムとプロマネの問題
アンチパターン(32) 気がついたらテストの時間がない(もしくはテストをしない)
アンチパターン(33) 目標なきチューニング
アンチパターン(34) 完璧な初期DBサイズ見積もりと実際のデータ量の差が生む悲劇
アンチパターン(35) 性能に関するアプローチがない
アンチパターン(36) DBに格納されているテストデータ量が少ない/種類が少ない

Chapter8 人のサガに起因するトラブル
アンチパターン(37) 見て見ぬふり
アンチパターン(38) 重すぎる高価な鎧(よろい)
アンチパターン(39) 度を越した楽観
アンチパターン(40) 心配屋

Chapter9 DBAをめぐる組織や権限の問題
アンチパターン(41) 自社に合ったDBAのあるべき姿が分からない/DB担当の要員アサインが悪い
アンチパターン(42) DBAが育たない
アンチパターン(43) セキュリティ権限設定とDB運用のミスマッチ
アンチパターン(44) DBチームのリーダー/担当者の権限が弱い

【2】OLTPなのにSQLが重い、なんでもかんでもリアルタイム集計

例えば、Webシステムなのに、応答時間に3秒以上かかったりする。
今のWebシステムならば、1秒以上応答がなかったら、苛つくユーザも多いし、Webサイトに訪れるリピータが減ってしまう。

原因は、開発時は少ないデータ件数でSQLを実装して問題なかったが、システムテストや性能テストで、Web画面から検索したら応答時間に30秒以上かかってタイムアウトしてしまう、などの事例が多いだろう。
特に新規案件で、過去プロジェクトの経験者のいない開発チームでは、どこにDBのボトルネックが起きるか予想できないから、よく起こりうる。
似たようなアンチパターンとして「なんでもかんでもリアルタイム集計」があげられる。

再構想の解決法としては、開発初期にプロトタイプを作って性能検証したり、性能負荷テストを十分に実施すること。
最近なら、JMeterのようなオープンソースの優れた負荷テストツールがあるので、故意にリクエストデータを増やすなどのテストもやりやすくなった。

あるいは、サマリ用テーブルや導出属性をテーブルに追加するなど検索結果を取得しやすいテーブル構造へ設計しておくこと。
サマリ用(集計)テーブルを作るなら、普通はCobolやストアドプロシージャなどのバッチ処理で集計処理する設計になるだろう。
導出属性の場合も同様で、累計回数とか累計金額、残高、在庫数などのデータはバッチ処理で後から更新するようにした設計になるだろう。

【3】データの保持期間を決めていない

本番リリース後、トランザクションテーブルは放置しておけばどんどんデータが溜まっていき、数年後には当初想定していたデータ容量よりも溢れてしまう時もある。
例えば、業務要件として、会計データは8年間保持しなければならないという法律があったりするので、過去のデータをすぐに削除することもできない場合もある。
しかも、会計監査上、過去データを保持するだけでなく、いつでも検索できるようにしておかないと、会計監査に引っかかる場合もある。
そもそも、会計データ(特に日々の仕訳データ)を紙の会計3伝票からシステム化することで、8年分の紙データを倉庫に保管するコストがなくなるために、そのようなシステムを導入する場合が多いから、皮肉なものだ。

再構想の解決法としては、引き落とし処理を実装しておき、直近数ヶ月~1年のデータを保持して更新する可能性のあるテーブルと過去データで参照するだけのテーブルに分けたりする。
そうすれば、更新系テーブルから参照系テーブルへ月次で引き落とし処理を実装すれば、参照系テーブルにインデックスを貼ってチューニングすればいい。

あるいは、運用後数年してトランザクションデータ量が多くなり、DB設計が複雑でリファクタリングもできないならば、メモリやHDDなどのハードウェアを強化するしか方法がないだろう。
この方法では、システムリプレースになるまで、コストが増え続ける弱点がある。

【4】バッチにおいて適切に処理を分割していない、バッチがリラン(再実行)できない

バッチは業務システムの生命線である場合が多い。
例えば、日次で、製品や商品の在庫数や納期のリードタイムを計算したり、製品を作るのに必要な品目とその所要量を計算したりする。
あるいは、月次で、在庫の棚卸しや会計締めを行い、商品有高帳や損益計算書、貸借対照表を出力したりする。
いずれも、これらの処理が止まるとユーザ企業の業務が文字通り止まってしまう。

このアンチパターンでは、そのバッチ設計で、業務の観点では1トランザクションなのに、バッチ処理の観点では複数のトランザクションに分かれていて、バッチ処理の途中で異常終了した時に、データが不整合のまま放置される場合が相当する。
そもそも、大量データを処理したり、複雑な処理をするために夜間バッチ処理するのだから、複数のジョブが正常終了して初めて一つの業務が完了する時が多い。
しかし、異常時にバッチをリランできるような仕組みにしておかないと、あるべき想定されるデータを復旧できなくなる。
しかも、異常終了したバッチの後に続くバッチが終わらなければ、翌朝のオンライン処理に必要なデータが設定されない制約があるため、バッチのリラン処理は短時間で終わらせる必要がある。
業務SEならば、夜間バッチのリラン処理は遭遇したくなくらい悪夢だ。

再構想の解決法としては、異常終了した時のバッチ設計をきちんと考慮しておくことが基本。
そして、システムテストや障害テストで、障害発生時の運用方法を事前にテストしてマニュアル化しておくのが大切。
そうすれば、本番運用時にバッチが異常終了した時でも、自信を持って対応できる。

【5】データの重複(データの分身の術……どれが本物?)

同じ意味のデータ(ホモニム、シノニム)が複数のテーブルに混在しているアンチパターン。
普通は、テーブルの正規化が不十分な場合が多い。

だが、よくある例は、一次開発後、次々にサブシステムを行き当たりばったりで開発して、個別最適化してしまい、システム全体の観点で見ると、あちこちにデータの重複が発生してしまう事例があるだろう。
特に昨今は社内Webシステムをどんどん作ったのは良いが、複数のサブシステムを連携する時に、重複するとは分かっているものの、開発の都合上、重複したデータを保持せざるを得ない場合があるかもしれない。
システム間接続ではありがちだ。

再構想の解決法としては、全体最適の観点(つまり、EA:Enterprise Architecture)でサブシステム内に散在する重複データをなくす正攻法しかない。
とはいえ、普通は、やっと安定運用させたサブシステムをいじることはできず、抜本的なシステムリプレースの案件が出てくるまで、重複データを放置して、システムをどんどん複雑化させてしまう場合が多いだろう。

【6】トランザクションスコープが不適切

アンチパターンの例としては、Webシステムの処理で、1トランザクションに不要な処理が混じって、処理が重くなりがちだったりする。
あるいは、1トランザクションの観点では、分離して後回しにして良い処理が混じっていて、応答時間が長くなりがちだったりする例があるだろう。
すると、障害発生時に処理が遅延していつまでも処理が終了しなくなったり、データの不整合が発生したりする危険がある。
原因はいずれも、トランザクションの設計が悪い。

再構想の解決法としては、タイムアウトの場合の処理を実装して、障害発生時にいつまでも処理が終わらない事態にならないようにする。
あるいは、重くなりそうな処理を分離して非同期処理にすることで、ユーザへの応答時間を短くする。
昨今なら、JavaScriptの非同期処理が使いやすくなっているので、ユーザにとって使いやすいユーザインターフェイスにすることもできるだろう。
あるいは、処理が重くなりがちなトランザクション処理はサービス監視対象として、障害を検知しやすくする方法もある。
最近は、Zabixなどオープンソースの優れた監視ツールが揃ってきているので、運用ノウハウが色々出てきた。

【7】引きずられるアーキテクチャ

よくある例は、外部システムとデータをやり取りする時に、応答時間が遅すぎたり、リクエストのデータ量が多いためにリソースを浪費してしまったり、閾値を超えるためにエラーになってしまう場合があるだろう。
あるいは、外部システムとの通信障害のエラー処理が甘いために、タイムアウトしているのにいつまでも応答を待ち続けたり、不正データ取得の処理がまずくて障害が起きやすかったりする場合もある。
最近は、複数システム間のデータのやり取りはSOAPやJSONなどが多いだろうが、特にSOAPはXML形式ゆえに、無駄にデータ量が増えやすい。

再構想の解決法としては、外部システムとの方式設計(アーキテクチャ設計)を事前に考慮することや、外部接続テストや障害テストで十分に接続インターフェイスを検証することがあげられるだろう。

マネジメントの観点では、外部システムは別チームないし外部ベンダーの管轄になるため、プロジェクトの初期段階から外部ベンダを巻き込んだコミュニケーション計画を立てておき、事前に外部接続インターフェイスの情報を収集するような仕組み作りが重要になってくる。
駄目なプロマネは、この辺りのコミュニケーション計画や外部ベンダのような利害関係者のハンドリングが下手な時が多い。

【8】DBに格納されているテストデータ量が少ない/種類が少ない

よくある例は、システムテストで本番運用に近いテストをしたい時に、テストデータ量やテストデータの種類が少ないために、本番運用後に想定していない障害が多発する場合がよくあるだろう。

再構想の解決法としては、システムテストや性能テストでテストデータの種類や量を増やすことがあげられる。

性能テストの観点では、本番稼動後の業務要件を想定して、必要なテストデータ量を準備すべき。
そのために、増幅データを作るためのプログラムも別途作る工数が必要になるかもしれないので注意すべき。

システムテストの観点では、ERPのようなパッケージ製品を導入する場合、テストデータをERP自身で生成するパターンと、本番環境で運用中のデータを移行するパターンの2パターンが考えられる。
前者の場合、ERPで使われる全種類のテストデータが生成される保証があれば、採用した方が良い。
なぜならば、網羅性の高いデータを使ってシステムテストを実施できるので、運用品質を高めることができるからだ。

しかし、稼働中の本番データがあるならば、本番データを移行してシステムテストした方が良い場合が多い。
なぜなら、既に使われている本番データをシステムテストで使うことによって、ユーザが業務で使うデータに近くなるからだ。
運用後に想定外の障害が発生しないように、どちらのやり方を使うか、考えておくべき。

【10】自社に合ったDBAのあるべき姿が分からない、DBAが育たない

今の時代、DBAのような業務データだけの管理者は多分いない。
普通は、運用チームやアプリ共通チームなどのように、どこかのチームの一人だけにタスクが集中する時が多い。
すると、DBAが初心者だったり、経験が浅い開発者であれば、DB周りのトラブルがいつも発生しがちで、大きな障害の地雷原になっているだろう。

原因としては、運用時の体制が不十分だったり、DBAのスキル不足だったりする。
再構想の解決法としては、DBAを補佐するチームを含む体制をきちんと作ること。
44のアンチパターンに学ぶDBシステム」では、DBAを含む体制として、開発チーム、運用チーム、全てのサブシステムを管轄するインフラチームの3つが挙げられている。
最近は、全体最適の観点から、全てのサブシステムを統括するインフラチームがDBAの役割を持つ時が多いだろうと思う。

44のアンチパターンに学ぶDBシステム

| | コメント (0)

2013/01/02

高品質と高機能は同義ではない

「「高品質」と「高機能」は、同義ではない。」というとても優れた文言に引っかかったのでメモ。

【元ネタ】
差別化とは「社会認知」であり「品質」ではない - 准教授 牧田幸裕の戦略的視座

ポーターの『競争の戦略』を使いこなすための23問」の本にも出てくるらしいが、最近の日本製品が韓国や台湾勢に押されている現状を見ると、上記の言葉が何故か引っかかる。

ケータイ、デジカメ、パソコン、スマートフォンなど、どの電化製品も、マニュアル無しの使いやすさよりも、ハイスペックを売りにするために、ユーザマニュアルが馬鹿でかくなる。
それに比べて、iPod/iPhone/iPadなどのApple製品はユーザマニュアルすら無きに等しい。
マニュアルがなくても自然に操作できてしまう。
アフォーダンスという言葉を連想させる。

高機能を高品質と間違えてしまう事例は、以下のBlogの記事がとても分かりやすい。
マーケティングの反面教師として見習うべきかもしれない。

Life is beautiful: AppleとSonyの一番の違い

Life is beautiful: AppleとSonyの一番の違い part II

Life is beautiful: もし日本のメーカーが iPhone を発売していたら..

| | コメント (0)

「コンサルタントの秘密」の法則集

ワインバーグ著「コンサルタントの秘密―技術アドバイスの人間学」のまとめの記事があったのでメモ。

【元ネタ】
「コンサルタントの秘密」の法則集

yomoyomoの読書記録 - G.M.ワインバーグ『コンサルタントの秘密』(共立出版)

コンサルタントの秘密―技術アドバイスの人間学」で有名な一節は、オレンジジューステストだろう。
コンサルタントと技術者の受け答えの違いを感じさせるやり取り。

Okdt BLOG: オレンジジューステスト。

(引用開始)
あなたが、ホテルの宴会主任からある相談を持ちかけられるとします。そのホテルの営業部の新しい習慣として、毎朝700人の営業部朝食会の席で、大きなグラスで絞りたてのオレンジジュースで乾杯することになった。どうしよう?、と。ここで、あなたは 「できません」「他に方法はないんですか」「ごまかしてしまえ」などという答え以外の答えを出さなければなりません。どうすれば良いでしょうか。

非常に難しい問題の解決方法をあきらめさせる思考の中には、相手から得ていない、こちらが勝手に推測した情報を基盤としてしまっていることに気づくことがあります。上記の例だと、もし、早朝に大量のオレンジを絞らせることだって、一人1000ドル払うつもりで集めれば、集まらなくもないだろう、というようなアイデアは、まだ尋ねてもいないのに締め出されているのです。予断することなく、「No」ではなく「YES, But...」とディスカッションを進めていける必要があります。「できますよ。で、それにはこれだけかかります。」と答えをだすのです。
(引用終了)

顧客の課題に対し、ITでどんなソリューションを提供するか?
開発者は、システムを実現性(フィージビリティ)や工数見積りの観点で考える。
コンサルタントは、システム導入による解決策だけでなく、手運用やコストをかけた方法なども考慮に入れる。
選択肢は2つ以上あった方がいい。
比較検討することで、長所と短所が見えてくる。

他の法則集もストーリーと共に説明されているので読みやすい。

| | コメント (0)

2013/01/01

組織はアーキテクチャに従う、アーキテクチャは組織に従う、どちらが正しいか?

フレームワークを使いこなすための50問」の一節にこんな問いがある。
「組織は戦略に従う、戦略は組織に従う、どちらが正しいのだろうか?」

フレームワークを使いこなすための50問」は経営コンサルタントのためのフレームワークに関する本なので、上記の問いは、コンサルタントが顧客へ戦略を提示時の制約条件について説明している。

その回答は「両方とも正しい。でも日本企業では戦略は組織に従うのがほとんどだ」と。
組織変革を自由に行える立場の場合、経営戦略の自由度は高い。
経営コンサルタントの好きなように、あるべき理想像に従って提示できる。

例えば、IBMが90年代に、メインフレームがWindowsパソコンなどのBPRの台頭と共に販売不振に陥った時、ハードウェアからコンサルタントやサービス事業へ転換した。
その時、40万人の従業員のうち30万人を解雇し、20万人を入れ替えた。
ハードウェア事業にいる人がいきなり経営コンサルタントになれ、と言われてもすぐになれるわけがない。
経営戦略に従って人材を入れ替えて組織を従わせる方針を取ることができるわけだ。

しかし、普通の日本企業は、今ある組織、今ある人材を前提に戦略を作らざるをえない。
終身雇用制度が古いといっても、大企業ほどその制度にしがみついている。
そして、退職推奨制度を設定すれば、優秀な人材ほどすぐに逃げていくのが今の御時世。
今なら、日本メーカーから韓国や台湾、中国のメーカーへ流れる人も多いのではないだろうか?

だから、今の組織構造を抜本的に変革できる余地がない場合、戦略は組織に従う。
すると、組織変革を伴うような経営戦略を作ってしまうと、机上の戦略のように思われてしまう、と。
したがって、採用される戦略は、組織に衝突を生まないような見栄えだけの改善策になってしまい、抜本的な組織変革に至らず、経営上の課題を解決できない場合が多いだろう。

この内容は、Conwayの法則「組織はアーキテクチャに従う、アーキテクチャは組織に従う」に適用できるか?
Conwayの法則が言う所は、ソフトウェアの構造はソフトウェアチームの構造に従うという経験則。
つまり、アーキテクチャに合わせた組織構造が良い、というもの。

プログラムデザインのためのパターン言語」では、アーキテクチャが安定した後に組織とアーキテクチャを密接に連携させるようにした方がよい、と言っている。
つまり、方式設計完了前の要件定義やシステム提案の時期に、開発チームを結成してしまうと、アーキテクチャが不安定であるがゆえに、アーキテクチャの変更のたびに組織構造に変更をもたらし、組織が不安定になることを意味している。

だから、SIの開発案件では、外部設計までは少数精鋭チームで機能やアーキテクチャをおおまかに作り、内部設計以降、大量の人員を投入して開発チームをアーキテクチャに合わせて形成していく。
その方が、組織変更が少なくなるからだ。
つまり、プロジェクト単位に人員の流動、変動が激しい。
SIにおける大量の人員を開発・テストで一括投入し、本番リリース前に人員を減らすという変動を行う理由は、Conwayの経験則に無意識に従っているのだろう。

「アーキテクチャは組織に従う」方針でアーキテクチャを組織に合わせようとすると、無駄なコミュニケーションパスが無駄なライブラリを増やす。
特に、複数の下請け会社で請負開発させると、複数の会社間のインターフェイスで無駄なライブラリが増える。
第4回shinagawa.redmine勉強会 - Togetterでもこんなつぶやきがあった。

Twitter / boochnich:Conwayの法則、「アーキテクチャは組織に従う」はよくあります。複数会社で開発すると、会社毎に共通化ライブラリができました。 #47redmine

最近なら、地理的に離れたオフショア開発でも同様のアンチパターンが生まれているだろう。

ゆえに、SIだけでなくソフトウェア業界では、安定したアーキテクチャに組織構造を合わせるように経験上無意識に運用していると言えるだろう。
ソフトウェア業界では「アーキテクチャは組織に従う」よりも「組織はアーキテクチャに従う」方が経験上良いと言える。
但し、その宿命として、案件ごとに人員の流動が激しく、組織の改変も多い。
その変化に付いていける人だけが生き残れるのかもしれない。

| | コメント (0)

« 2012年12月 | トップページ | 2013年2月 »