SaaS事始め - Googleスプレットシート

Web

lamuu2008-07-09

・『Googleスプレットシート』
http://www.google.com/google-d-s/hpp/hpp_co_jp.html


Googleカレンダーが思いのほか使えるのが分かって、いい機会なので個人的にいくつかのソフトウェアをSaaSに乗り換えてみる。まずは、勤務表をGoogleスプレットシートで作ってみた。

  • 主要な関数はExcelと遜色なし
  • マクロが無いのはやはりキツイ
  • セルの保護が欲しい（合計時間とかは入力不可にしたい）
  • 行や列のグループ機能も欲しいなぁ

やはりまだExcelにはかなわないし、もしかすると表計算機能なら後述するZohoやOnSheetのほうが高機能かもしれない。でも、社内のNotes勤務表よりはマシだぞorz

それにしても”SalesForceなどはCRMだし、SaaSって自分とはあんまし関係ないな”とか思ってたが、グループウェアやオフィスソフト方面から攻めている（ように思える）SaaSは、個人が無料で使うことのできる間口の広さゆえに、かなり脅威に感じる。

データベースも作れちゃったりするもんなぁ。これらにバッチ・帳票・ワークフローくらいが加われば、ちょっとした業務システムなら簡単に構築できそうだ。
PaaSとかいうキーワードも聞こえてきたし、自分のようなSIerはもっと危機感持たないとダメな気がしてきた。
でも、SaaSそのものを構築することができない会社は、今後何やるんだろ。ERPみたく、各SaaSベンダーに特化したカスタマイズ屋さんになるとか？…いやぁ、そんな未来は正直カンベン。

WILLCOM 03

モバイル

lamuu2008-07-06

2年間お世話になったW-ZERO3[es]ともおさらばして、WILLCOM 03に機種変更。
うーん、悪くはないけど、いろいろと微妙な端末。

  • 携帯並みの小ささはイイ（[es]がデカすぎか。）
  • キーボードが押しやすくなった（Advanced／W-ZERO3[es]とは同じだな）
  • Opera9.5が残念なことに（Safariっぽい使い勝手を目指したんだろうけど、いかんせんモッサリ）
  • イルミネーションキーの感度はイイ（だけどテンキーと十字キーの切り替えはイラつく）

あとはカスタマイズ次第か。
まぁ、それこそがWindows Mobile搭載スマートフォンの真骨頂であるわけだけど。
とにかく、これからこの端末にバリューセレクトで2年縛られる。
2年以内に次世代PHSの実現と、もう少し操作が軽い端末をお願い＞WILLCOM

ソフトウェア再利用ガイドブック

本 ソフトウェア開発

ソフトウェア再利用ガイドブック―アーキテクチャ、プロセス、組織の変革による再利用ビジネス成功への道

ソフトウェア再利用ガイドブック―アーキテクチャ、プロセス、組織の変革による再利用ビジネス成功への道

ソフトウェアの再利用について思うところあり、本棚からこの古い本を引っ張り出す。
Amazonで見たら既に廃刊してて、中古にプレミア価格ついてる。


それはいいとして。
本書では、再利用によりビジネス上の利益が見込める場合はドメイン・エンジニアリングを開始しなさい、と教えている。

ドメイン・エンジニアリング
　・ドメインを定義し範囲を明確にする
　・例、ニーズ、トレンドを分析する
　・ドメインモデルとアーキテクチャを開発する
　・共通性と可変性を構造化する
　・再利用可能なコンポーネントシステム、言語、ツールを設計する


アプリケーション・システム・エンジニアリング
　・ドメインモデルとアーキテクチャに関連する差分の分析と設計を行う
　・開始点としてコンポーネントシステムを使用する
　・コンポーネントを発見し、特化し、統合する
　・可変メカニズム、言語、ジェネレーター、…、を利用する

要するに再利用可能なドメインのコンポーネント化を促進するためには、個別のアプリケーション開発とは分離した計画・活動・管理・組織が必要ですよ、と。これは基本的にはビジネス視点、つまり、複数アプリケーションを跨る再利用・共通化の観点での話だが、単一アプリケーション開発プロジェクトにも必要だよなぁ、と最近よく思う。


各業務開発チームに共通な非機能要求を解決するために、アーキテクトチームを編成することは普通に受け入れられるけど、複数業務共通の問題を解決するチームはなかなか編成させてくれないことが多い。


これには色々原因があると思う。
一つは、分析でモジュール分割が十分に検討される前にチームが編成されること。
一つは、例えば会社標準のWBSや開発プロセスに、この”複数業務共有地の悲劇”を解決する明示的なタスクが無いこと。
（もう一つは、ドメインオブジェクトの没落とトランザクションスクリプトの隆盛…と言いたいとこだけど、これはまぁ、コンポーネント化技法の違いの問題であり、たいしたことはない。）


後々ヤコブソンは、複数のユースケースに跨るドメインオブジェクトのモジュール性を維持する困難さを解決する手法として、AOSD(ユースケースによるアスペクト指向ソフトウェア開発 (Object Oriented Selectionシリーズ))を言い出すけど、あくまでテクニカルな解決方法で、この『ソフトウェア再利用ガイドブック』で熱心に語った計画・活動・管理・組織の分離の問題にはあまり触れてない。


とにかく…ITのプロマネというやつは、適当にチーム組んだり、適当に標準プロセスそのまま実行しちゃったりしちゃいかん。

ザ・ゴール

本

ザ・ゴール ― 企業の究極の目的とは何か

ザ・ゴール ― 企業の究極の目的とは何か

CCPM(Critical Chain Project Management)を考える前に、TOC(Theory of Constraints(制約条件の理論))の原典を読まないと…。


ということで、長年積ん読してた『ザ・ゴール』を土日で読破。発行年を見ると、実に4年も在庫として眠っていたようだ。


すぐさま仕事に活かせるとか、そーいうものではなさそう。ソフトウェアプロジェクトに適用できるのはたぶん『クリティカルチェーン』のほうか。とりあえず現時点での疑問とか感想とか。

  • 製造と開発の違い。TOCはソフトウェア工場には適用できそうだけど、そもそもソフトウェア開発の工場化自体が賛否両論だ。そういえば、デマルコは反対なんだか、賛成なんだかよく分からん。
  • ソフトウェア会社はソフトウェア工場？どっちかというとソフトウェア会社は、プロジェクト工場じゃないのか。そうすっと、今は非稼動の俺のような人間は在庫？
  • ソフトウェア会社やソフトウェアプロジェクトの制約条件は何か。会社は、やっぱ人？自社製パッケージの有無かもしれん。プロジェクトは、うーん、要件定義？いや、それこそプロジェクト固有だろう。
  • プロジェクトのボトルネックを改善する仕組みこそ反復型プロセスか。でも、ボトルネックを見つけ、改善するチャンスはそう多くない。前回ＰＪは４回だけだった。だいたい、統一プロセス（United Process）的な反復だと、たとえ製造が改善されても、後の反復ではテストのほうが比重が大きかったりするぞ。
  • ボトルネックの評価基準は何か。QCD？EV？あれ？そもそもEVってROIに関係ある？高コストなエンジニアがくそったれな要件定義書を100頁作ったからといって、それは出来高なのか？
  • そもそも『ザ・ゴール』の工作機械のように”あれこそボトルネック！”と、指差せるタスクはソフトウェア開発には少ないような。まずはバリューストリームの見える化が先じゃないか。
  • 『リーンソフトウェア開発』にソフトウェアの会計基準の話があったような、なかったような…。TOCの話もあったような。確かめないと。
  • 会社の話に戻ろう。在庫（非稼動要員）がなかったら、プロジェクトは組めない。だからといって外部調達を強化するの？会社のゴールが利益だけならそうだろう。けど、会社のゴールには社会貢献ってのもあるはず。多重請負構造に加担するのはいかがなものか。
  • バッファマネージメントは『クリティカルチェーン』を読んでから考える。ところで、開発者は”過大見積り”し、”学生症候群”に陥るという前提は本当か。少なくとも前回ＰＪにそんなやつはいなかったけどなー。早期完了のときも正直に報告してくれるマジメなメンバーなんだが。
  • 積ん読の在庫はどーにかならんものか。
  • ウチの妻がジェリーのようにならない保証はない。「あなたの仕事は、いつもきつい仕事ばかりなのね。いつもよ。そんな仕事しかさせてもらえないあなたに、会社はどうして昇進させたり給料を上げたりするの」


…とにかく『ザ・ゴール』は、あの分厚い本を読む時間より、考えさせられる時間の心配をしたほうがよい。

お勉強の日

出来事

最後の日記からまた２ヶ月も経ってる…。
本番リリースと新案件の提案の同時平行なんてもうヤダ。


けど新案件の提案も終わり、あとは結果を待つのみ。
今日１日を自分へのご褒美に「お勉強の日」にした。


・CCPM(クリティカルチェーン・プロジェクトマネジメント)をWebで読み漁り、
　次のプロジェクトのバッファ管理について考え、
　http://www.atmarkit.co.jp/aig/04biz/ccpm.html


・OSSのジョブ管理ミドルウェアを探し、Hinemos（ヒネモス）が良さそうだなと思い、
　http://www.hinemos.info/hinemos/


・良く知りもせず偏見を持ってたSOAとESBへの誤解を解き、
　http://www.thinkit.co.jp/free/article/0703/7/1/


・ESB Muleをインストールしてチュートリアルをこなし、
　http://codehaus.org/~hozawa/index.html


・ほとんど積ん読してた『成功する要求仕様 失敗する要求仕様』を読んで、
　これから難航するであろう、要求のトリアージのテクニックを学ぶ。


なんてこったい、俺の一日はかくも充実できるものだったとは！

Software Process Dynamics

本 ソフトウェア開発

Software Process Dynamics

Software Process Dynamics

初プロジェクトマネージャは、おおむね成功裏に終わりそう。けど、スキルアップした感じはなく、どちらかと言うと消耗・疲弊したことのほうが多い。


ということもあって、そろそろ勉強して充電する時期にしたいなぁと、金曜は社内勉強会に参加。テーマは「システムシンキング・システムダイナミックス」で、そこで紹介されたが、この「Software Process Dynamics」という本。思わずamazonでボタン押してしまった。8,888円ナリ。高い...。


システム思考は別段新しいものではなく、この本冒頭でも触れられてるが「ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉」とかは昔から有名で、既にこの頃から”ブルックスの法則”のモデル化が試みられていたりする。


ビジネス界隈だと最近？では「ラーニング・オーガニゼーション」で注目されたのが記憶に新しい。ソフトウェア界隈では、最近目にしたとこだと「デッドライン」の中で、アブドゥール・ジャミッド博士が、主人公の直感モデルをさっそうとシミュレートしてみせる場面が印象に残ってる。（※Abdel-Hamidのパロディだってことが今回よーやく分かった）


で、この本は、20年間におよぶMadachy氏の研究成果として、ソフトウェア開発プロセスにおける様々な”力学”を、システムダイナミックスによってモデル化してみせたものであり、米国amazonに載ってるヨードンの書評曰く、”2007年の最も良いソフトウェア工学の本だけではなく、もしかしてこの10年間の最も重要な本”らしい。


目次はこんな感じ。

[基礎]
１．イントロダクションと背景
２．システムダイナミックスによるプロセスのモデル化
３．ソフトウェアプロセスのためのモデル構造と振舞い
[適用と将来の方向]
４．人々への適用？（people applications）
　（※燃え尽き症候群のモデル化とか、人の問題を扱う）
５．プロセスと製品への適用
　（※再利用するときのモデルなど）
６．プロジェクトと組織への適用
　（※アーンド・バリューなどに触れられてる）
７．現在、そして将来の方向
　（※アジャイルとか最近のトレンドのモデル化？）


まだ全然読んでないけど、きっと、この本に”完璧な解”を期待しちゃいけないと思う。勉強会中の話題にも出たけど、こういうのは、モデル化して、シミュレートして、実際と照らし合わせてまたモデルを調整する、そのこと自体に価値があるんですよ、と。


４章とか特にそうだけど、いくら精緻にモデル化したって、”要員の疲労”、”モチベーション”、”スキル”、”コミュニケーション”といった要素のモデル化はどうしても恣意的になるだろうし。


「デッドライン」では、”モデルを作って…それで？”という疑問に対し、こう言っている。

「...画面上の直感を、腹の中の直感より優れたものにすればいい」

プロマネのKKD（勘、経験、度胸）では、もはや人を説得するのがむつかしい時代でありますしね。多少恣意的であろうとも、モデル化して、プロマネの考えを可視化することが大切なんじゃないかな、と。


でも、”よし！モデルを書くのじゃ”と思ってシステムシンキング用のメジャーなツール「STELLA/iThink」を買おうとしても...
http://www.varsitywave.co.jp/products/stella/price.html
260,400円だって。さすがに手が出せませんorz

入学式

出来事

半年間の忙しかったプロジェクトもようやく終わりが見え始め、昨日は振休を取って息子の入学式へ出る。
なんだか、いつの間にか小学生になってた感がある。
仕事ばかりに気をとらわれて申し訳ない＞家族の皆々様。