pocopanの日記「システム冒険図鑑」

春の訪れとともに、先週、台風並みの嵐が日本列島を縦断していきました。昨年９月の台風の記憶もまだ新しいのに、傘をこわした人、動かない電車の中で待ち続ける人、駅舎にあふれる人々が、再びニュースで映し出されていました。


【富士山に登るためのサポートマガジン】第１０８号を発行しました。

テーマは、「山での嵐」についてです。
http://archive.mag2.com/0001019160/20120408193419000.html

バックナンバーで、すべて読むことができますが、
購読登録していただけると、とっても気合が入ります。
http://www.mag2.com/m/0001019160.html


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

今月の「日経SYSTEMS」2012.034の特集１では「カイゼン型開発のススメ　システムを育てる」が掲載されていました。

業務や外部環境の変化に少しでも早く対応できるべく、システムの開発方法を見直そうという特集です。

「短期サイクルの創出」「役割連携の強化」「ブレ抑制の枠組み」という３つのアプローチを中心として、現時点での最新の「カイゼン型開発」の進め方が網羅されており、カットオーバー後の保守を任されているＳＥには必読の特集となっています。ただし、カートオーバー以前から解決しておくべき課題や盛り込んでおくべき作業もあるので、システム開発に携わる全ＳＥは、結局のところ必読になるでしょう。

昨今のビジネスの変化や進化には目覚しいものがあります。ですが、それを実感しているＳＥは少ないと思います。ビジネスの当事者ではないので、やむをえないところはありますが、もう少しお客様側のビジネスの視点に立つ必要があるでしょう。

資金を投じれば、それなりの売上が確保できた時代とは、今はもう違います。何かも不透明な時代となりました。「こうすれば、必ず売れる！」という戦術は、最近ではもうあまり通用しなくなっています。こういった暗闇の世界の中で生き抜く唯一の手掛かりは「テスト」です。不透明なマーケットに対して、リスクをかけずに小規模なテストを何度も打つことです。うまくいったテストパターンだけを本番で大規模に行うのです。こうすれば、リスクは減ります。

つまり、お客様側の視点では、「考え抜いた、あらゆるテストでマーケットを試してみたい」というのが本音になるはずです。しかしながら、現在稼働しているシステムはそれらのテストや試行錯誤やイレギュラーを許容しているでしょうか？あるいは、現在開発中のシステムはどうでしょうか？

最先端のシステムの技術も重要ですが、最新のビジネス事情についても、ＳＥはある程度マスターしておく時代が来ているようです。


さあ、今日も地図を広げて、ビジネスという世界に冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

富士通研究所が「アプリケーション資産を市街地図というモデルにして表現する」という自動作成技術を開発したそうです。

すでに稼動している大規模システムの業務アプリケーションは、それを開発した企業にとっては一大資産です。巨大な費用が投じられています。ですから、その資産を今後も生かしていきたいと思うのは自然な発想です。ですが、稼働している業務アプリケーションの実態は、複雑怪奇以外の何ものでもありません。そのシステムを長年維持してきたメンバーでないと、触ることもいじることもできない複雑なプログラムの集合体だからです。稼動当初は整然としたプログラム群であっても、積み重なる機能追加により、相当構造が歪められてしまっているからです。もちろん、メンバーは短期間で機能追加を完了しなければならないため、ベストを尽くしたとは思いますが、理想通りの変更ではなかったことでしょう。

こういう事態はどこでもおこっていることと思います。そこで、今回の富士通研究所の技術の登場となります。これを使えば、一目で直感的に現状の構造が理解できるのですから。再利用できるところは、どんどん再利用することで、今後の開発費用を相当軽減できることでしょう。

でも、個人的には「市街地図」に模している時点で残念な気がします。モデルの選ぶなら、「車」とか「人間」とかあったでしょうが、「市街地図」というのが実に不満です。

この技術を使って、あるアプリケーション資産の「市街地図」を描くと、飛び地があったり、色が揃っていなかったり、整然としていなかったり、あるいは暗い街区は、不適切なアプリケーション資産と評価されるからです。

街は、迷路のように路地が複雑なほど、町として味わいがあると思うのですが、そのような評価ではないようです。さらに、乱雑な街区は再開発が必要といわれても、すぐには納得できません。世界遺産として登録される街は、たいていは迷路のような町なのですが、この新しい技術とは、文化的・美的判断が著しく異なるようで、とても残念です。

「ＳＩＭ　ＳＩＴＹ」などの街作りゲームをパソコン上で行うと、どうしても整然とした町ができあっがってしまうので、よく残念な気持ちになることがあります。複雑な町を作ってしまうと、交通渋滞が発生したり、電気・水道などのインフラが複雑になり、すぐに町の予算が赤字となってしまうので、整然と作り上げるしかないのです。でも、本当に住み心地が良い街かどうかは別問題です。複雑な路地をいくつも抜けると、突然現れる広場の良さなど、数値的に判断して欲しくないところです。

実際にこの技術を使う日が来るのかどうかは、わかりませんが、もっと別の表現にしてほしかった思うニュースでした。


■　富士通研究所、アプリケーション資産活用のためのソフトウェア地図の
　　自動作成技術を開発
　　http://release.nikkei.co.jp/detail.cfm?relID=304221&lindID=1


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

「戦略的な見方」という言葉がよく使われます。

でも、「戦略的に見よう」とか、「戦略的に考えよう」といわれても、よくわからないのが実情ではないでしょうか？

「戦略的ではない見方」というと、私たちはすぐに次のような言葉を思い浮かべることができると思います。

・　短絡的
・　視野が狭い
・　ローカルすぎる
・　目先の話
・　重点がどこだか分からない
・　一時的には勝利しても、最終的には敗北または撤退している
・　思い切りが悪い


でも、戦略的な見方というものは、上記の言葉の反対語だけで十分説明することができるでしょうか？やっぱり、漠然としていますよね。まず、どこから手をつければよいのかがわかりません。

そこで、地図を使って実際的な「戦略的な見方」をお話しましょう。


Ａという町と周辺の地形が描かれた地図があります。Ａという町と、隣町であるＢという町との間に鉄道を建設することになりました。


◆　未来を見る

まずは、Ａ町とＢ町との間に鉄道が敷設できた地図を想像すると思います。いろんなルートを思い浮かべることができますが、１本だけ気になるルートが出てくるかもしれません。要は、将来の地図がどうなるのかを、想像することが肝心です。

最初の「戦略的な見方」とは、未来を見るということです。


◆　過去を見る

鉄道を建設するにしても、地盤の軟弱な土地は避けたいと思うはずです。昔、海や湖の底であったような土地です。それを調べるために古地図を取り出すことでしょう。要は、過去の地図ではどうなっていたかを検証することが肝心です。

２番目の「戦略的な見方」とは、過去を見るということです。


◆　上空から見る

もう少し上空から地図を眺めてみましょう。Ａ町とＢ町との間に巨大な山脈が横たわっていれば、もう少し上から見れる広い範囲の地図が必要になるでしょう。中央高速道路のように、完全に南アルプス山脈を避けたように、完全に迂回してしまうか、それとも中央アルプスの恵那山トンネルのように、山脈にトンネルを通してしまうか、判断する必要があるわけです。要は、地図をできるだけ上から眺めるということが肝心です。

３番目の「戦略的な見方」とは、上空から見るということです。


◆　足元を見る

鉄道を敷くにあたっては、大きな山脈だけが障害ではありません。小さな家１軒であっても、立ち退き交渉が長引くかもしれません。あるいは、小さな遺跡を保護するための運動で、計画自体が挫折してしまうかもしれません。要は、地図をできるだけ細かく見るということが肝心です。

４番目の「戦略的な見方」とは、足元を見るということです。


◆　角度を変えて見る

山脈にトンネルを掘るにしても、できるだけ短い区間でおさえたいところです。それを判断するために、地図上の等高線だけでは判断が難しいかもしれません。こういうときは、断面図を描いて、最適なトンネルを計画するのがよいでしょう。あるいは、岩盤の硬さを示すような地質図が必要になるかもしれません。要は、一つの地域を表すいろいろな地図を使って、いろいろな角度から眺めるということが肝心です。

５番目の「戦略的な見方」とは、角度を変えて見るということです。


◆　視点を変えて見る

Ａ町とＢ町とを単純に交通機関で結ぶということであれば、もしかすると、全線地下鉄、あるいは自動車道、リニアモーターカーなどが効率が良いかもしれません。あるいは、隣国を経由したハブ空港で結ぶ方が経済効果は大きいかもしれません。要は、地下鉄路線図・航空路線図・経済効果図など、多種多様な地図を用意して、いろいろな視点から眺めるということが肝心です。

６番目の「戦略的な見方」とは、視点を変えて見るということです。


◆　差分を見る

Ａ町には、もともと開発計画があったはずです。現状はどうなっているかを調べて、うまく進んでいない部分をカバーする形で鉄道を施設したほうが良いはずです。あるいは、Ｂ町との交通機関が少ないという住民たちの不満を解決する形で、鉄道を敷設するほうが開発としてはベターです。Ａ町の発展計画を示す地図を用意して、Ａ町の発展を阻害しているギャップ、すなわち問題点を拾い集め、理想と現状との差分を見つめるということが肝心です。

７番目の「戦略的な見方」とは、差分（ギャップ）を見るということです。


◆　機会を見る

Ａ町とＣ町を結ぶ鉄道沿線に、すでに住宅地や商業地がたくさん林立しているとすれば、Ｂ町との間に鉄道を敷けば、同様な発展を期待することができるでしょう。Ａ町の発展状況を示す地図を用意して、問題点だけでなく、積極的な開発の機会を捉えるいうことが肝心です。

８番目の「戦略的な見方」とは、機会（チャンス）を見るということです。


◆　無から見る

白地図ならぬ、まったくの空白の地図を用意して、ゼロベースから鉄道計画を考えるというのも有効です。

９番目の「戦略的な見方」とは、無（ゼロベース）から見るということです。


◆　借りて見る

鉄道は全国中に張り巡らされています。その中からＡ町に条件が非常に近い鉄道計画図を持ってきて、そのコンセプトをそっくりそのまま当てはめてみるということも有効です。

１０番目の「戦略的な見方」とは、借りて（フレームワークを利用して）見るということです。


◆　全体を見る

ここまでくると、あとは今までの見方を総合し、全体をまとめて地図を把握することになります。この段階までくれば、精密に再現された鉄道模型を使った立体ジオラマや各種統計図表で、将来像を語ることができるでしょう。

最後の「戦略的な見方」とは、まとめて全体を見るということです。


さあ、今日も地図を広げて、戦略的に冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

最近、職場でこんなやりとりがありました。

Ａさん「○○に関するファイルはどこにありますか？」
Ｂさん「はい！」

と、ＢさんはＡさんに印刷された紙の資料を渡していました。

質問に答える方法にはさまざまな方法があります。たかがファイルの存在場所を答えるにもさまざまな方法が浮かびます。けれども、Ｂさんの回答？というか行動は、私には想定外の方法でした。

なぜ、その質問が発せられたのか？その原因を探ることも、質問を回答する際には重要なことのようです。Ｂさんの簡単な回答から始めて、いろんな回答についてレビューしてみましょう。


１　ファイルを印刷して渡す。

　　Ｂさんの回答ですが、この回答だと、
　　すぐに次の質問が飛んでくるでしょう。

　　別の資料でこの図を再利用したいので、
　　電子ファイルでいただけないですか？

２　ファイルをメールで送る。

　　しばらくすれば、次の質問が飛んでくるでしょう。

　　類似の資料で○●のファイルは、どこにありますか？

３　ファイルの保存場所をメールで送る。

　　だいぶマシな回答になってきましたが、
　　次の日には、別の質問が飛んでくるでしょう。

　　××に関するファイルはどこにありますか？

４　ディレクトリ構成についてメールで送る。

　　ここまでできれば優秀です。
　　でも、こんなことがありました。

　　ディスクが壊れてしまったので、
　　もう一度メールを送っていただけますか？

５　ディレクトリ構成について掲示板で説明されていることを教える。
　　また掲示板から容易にアクセスできるという事実だけを教える。

　　もちろん、ディレクトリ構成を説明した掲示板が
　　常に最新の状態にメンテされていることが前提です。
　　一度こういった掲示板が確立していれば、
　　その後のメンテは思っているほど、大変な作業ではありません。

　　あと、うまく誘導できたかどうかフォローする必要があります。
　　どうしても見つからないのであれば、原因を調べ、
　　掲示板の説明に関してフィードバックを施す必要があります。


たかが、質問の回答ですが、されど質問の回答でした。常に「なぜ？」を繰り返してみましょう。「どうして、そんな質問が発せられるのか？」


さあ、今日も地図を広げて、質問への回答という冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

先日、家内といっしょにＤＶＤで「宇宙戦艦ヤマト 復活篇」を見てしまいました。二人とも大の宇宙戦艦ヤマトファンですので、上下左右のある宇宙空間や、強引なストーリー展開、大げさなメッセージ、すべて二人にはＯＫです。

そういう要素がなければ、もはや「ヤマト」ではありませんので。

今回の作品では、古代艦長は実に多忙を極めます。一応優秀で若い部下たちに恵まれますが、責任はすべて自分で負うべく、まさに孤軍奮闘です。

艦長といっても、移民船団やその船団を護衛する護衛艦隊までを指揮しなければならないので、実質的には一大艦隊の艦隊司令官、すなわち提督になったようなものです。

しかし、古代艦長は、移民船団を統率する提督という重要な仕事をこなしながらも、ヤマトという個艦が持つ特有の武器を駆使するため、艦長としての激務も果たします。さらに、コスモパルサー隊の戦力を上げるために、はては、艦の操舵まで引き受けてしまいます。

相当なスーパーマルチタレントぶりを発揮する古代艦長です。でも、人に任せるべきところは、うまく人に任せていますし、任せてうまくいかない場合には、すぐにフォローに回るなど、リーダとしての才能には目を見はるものがあります。

まあ本来なら、古代艦長は提督業に専念し、艦長にはしっかりとした艦長代理を立て、航海長や艦内医がコスモパルサーのパイロットと兼任しないような適材適所を実践すべきでしょうね。

部下に仕事を任せるというのは、いつの時代（ヤマトは西暦2220年）でも大変なようです。

というわけで、今月の「日経ＳＹＳＴＥＭＳ 2011.11」では、「多忙なリーダ必読！任せる技術」を特集していました。

「任せたはずなのに、自分でやってしまい、忙しさは変わらない」というリーダは多いのではないでしょうか？

特集では、「準備」「依頼」「フォロー」という３つのフェーズに分けて、「任せる」という技術の勘所をうまく伝えてくれています。

本特集のテクニックを実践すれば、リーダとしての自分の忙しさを減らすことができ、プロジェクト全体の力を増やすことができそうです。

中でも、「目標のイメージの共有」が一番重要でしょう。

メンバー全員が自律的に動いてもらうためには、「人類全体を、青くて美しい惑星に移住させる」という具体的なイメージが絶対に欠くことのできない力なんですね。


さあ、今日も地図を広げ、目標のイメージを共有し、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

先日のニュースで、「ニュートリノが光よりも速い」という実験結果が出たことで話題になっています。

これが本当なら、タイムマシンも実現可能になるかもしれません。ただし、今までの常識をくつがえす発見なだけに、第三者の徹底的な検証が必要だとの声も多数あがっています。また、発表した研究グループの学者たちも、第三者の検証を求めるべく、公表に踏み切ったということです。

これを聞くと、私たちＳＥも、襟を正す必要があるようです。

お客様に納める納品物は、きちんとテストを行います。しかしながら、納品対象外の自作のツールやバッチなどは、十分な検証を行なっているでしょうか？

このぐらいの試験でいいかなと、作った人のさじ加減ではないでしょうか？作成した人任せで、第三者がツールの要件から試験項目を抽出して、パターンを網羅するような試験はなかなか行われていないはずです。

これらのツールは、お客様への納品物を作成するのを支援するためのものですから、最終的に納品物を十分にテストすれば、それはそれでよいのでしょうが、意外とこれらのツールのバグにより、時間をロスしていることが多いようです。

例えば、先日実際にあった例では、各フォルダ内のＰＤＦファイルを一つにつなげて所定のファイル名で保存してくれる便利なバッチがありました。でも、フォルダにＰＤＦファイルが１個しかない場合、バッチで呼ばれたプログラムは、結合すべきファイルが１個しかないので、処理をスキップしてしまいます。その結果、所定のファイル名で保存してくれないという不具合が発生しました。でも、そういう事象は、納品物を十分にチェックするまで、なかなか気づくことができません。

となると、ツール自体もきちんと検証しておく必要があるということになります。少なくとも、第三者による検証を実施していれば、防げた時間ロスです。作った人の責任だという話ではまったくありません。何気なく使うツールといえども第三者が検証を行うかどうかというプロジェクト自体の文化の問題です。

少なくとも、ツールのｒｅａｄｍｅには、ツールの要件を書き、第三者が実施した試験内容もあわせて記載しておくべきだと痛感した次第です。

ツールやバッチといえども、第三者による検証は重要だというお話でした。


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

問題が発生すると、作業が中断します。しばらくすると、問題が解決したようで、再び作業が再開します。再開後まもなく、またまた問題が発生のようです。

待機と作業が繰り返し発生するプロジェクト。最近のプロジェクトでは、よく経験します。

しかも、問題が解決しても、何の説明も無く、何事もなく作業を継続するというのが、お決まりのパターンです。私たちには、原因も対策もわからないままです。

どうして、一連の問題解決の過程を記録に残さないのでしょうか？誰にも知られたくないような問題だったのでしょうか？あるいは、自分たちの失敗を隠さなければならないような問題だったのでしょうか？

まあ、これは考えすぎですが、どうやら、記録に残すということを知らないようなのです。まれに、記録に残すようにと指示されることもありますが、そういうときは決まって、お客様に一連の問題点を報告しなければならないときです。それ以外のときは、まったく記録に残さない。記録を取ることも思いつかない。そんな感じです。

記録に残さないので、同じ過ちを繰り返してばかりいます。まあ、同じミスを同じ人が繰り返すことは少ないのですが、問題の記録をシェアしないので、チームとして、まったく進化がなく、別の人が同じミスを繰り返します。

記録を取ることで、同じ過ちは、かなりの確率で再発せずに済みます。さらに、その記録にもとずいて、フィードバックを真剣に行えば、システムとプロジェクトの双方が間違いなく改善されていきます。

ゴールへの近道を歩きたいのであれば、記録を取るという地道な作業が重要です。一足飛びにゴールへたどり着くことなど、考えるのはやめましょう。「記録を残して、少しずつ改善していく」という小さな成功を積み重ねていきましょう。

失敗の記録は、成功への確たる礎になるはずです。


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

メンバーに作業を指示する場合には、作業内容をテキストファイルなどに記述し、必ず文書化してから作業指示を出しましょう。

要は、口頭では作業内容を説明しないということです。口頭で説明すると、どうしても曖昧になります。曖昧さが少しでもあれば、思わぬ落とし穴にはまります。

口頭の説明にしたがって、参照すべきファイルをメンバーが次々と開いていっても、間違って閉じてしまったら、また口頭で教えてあげねばなりません。説明する側も大抵はうろ覚えでですから、ディレクトリ構造を思い出しながらの説明になります。もし、メンバー全員を集めて、こんな説明をしていたら、メンバー全員がメモを取らねばならず、大変非効率です。間違ってメモをするメンバーもきっといるはずです。

「文書で作業内容を説明するには、作業が複雑すぎる！」という場合には、なおさら口頭での説明は危険です。文書にすれば、意外とすっきりと整理できるものです。

リーダのちょっとした手抜きが、メンバー全員の作業に大きなロスを課してしまい、悪くすれば、メンバーにミスを誘発することになります。

作業のきっかけは、口頭でかまいませんが、作業の骨格だけは文書で示しましょう。

「作業目的や作業理由は何か？」
「どのディレクトリにある、どのファイルを参照するのか？」
「最終的に、どのディレクトリに何というファイル名でアップするのか？」
「作業の範囲はどこまでか？」
「期限は何時までなのか？」

誤解のないように記述しましょう。もちろん、タイトルも必要です。その作業内容に適した「作業名」をつけましょう。

ここまで準備して作業指示を出しておけば、進捗確認の際に「どの作業ですか？」という寝とぼけた返事は聞かなくて済むようになります。


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。

チームで作業を受けたら、早速地図を描きましょう。２枚の地図を描くと便利です。

１枚目の地図は、システムを表す地図です。システム内の複雑なモジュールの構造を示すモジュール構成図であったり、システム間の複雑なインタフェースを示すインタフェース図であったりするかもしれません。要は、自分たちの作業の範囲を明確に示す仕様書なり、設計書なりを用意できれば良いのです。最近のプロジェクトではよくあることですが、こうした仕様書や設計書がなければ、自分たちで描いていきましょう。そして、用意した地図に自分たちに作業範囲を赤ではっきりと描いていきましょう。

ここからが重要です。作業範囲を示す赤い境界線上に、あいまいな部分はないでしょうか？あいまいな部分があれば、作業の終盤で必ずひどい目にあいます。ですから、この段階であいまいな箇所はなくすように努めるのです。作業期間で関係者が勘違いすることは、ほとんどありませんが、作業範囲をめぐるトラブルは数限りなく発生しています。ですから、みんなで一目で理解できる地図が必要なのです。

２枚目の地図は、作業全体を表す地図です。地図といっても表になります。縦軸は作業対象となるモジュールやプログラムなどの構成要素の一覧となります。横軸は、作業を構成するすべての作業ステップになります。表の各マス目には、担当者と作業が完了した年月日を記載していきます。表のすべてのマス目が埋まれば、作業の完了となるわけです。

こうした地図を用意しておけば、作業のリーダは特に指示を出すまでもなく、全メンバーがすべてのマス目を埋めるべくしかるべき役割を果たしてくれます。リーダは真の問題だけに取り組むことができるようになります。作業が複数日にまたがる場合には、毎朝みんなで今日の作業範囲を決めましょう。今日の作業範囲を決めておけば、また自動的に全メンバーが今日の作業分のマス目を埋めるべくしかるべき役割を果たしてくれます。作業が終われば、全員で帰宅です。作業が終われば、帰宅ですから、作業完了に向けて、全メンバーが一致団結してくれます。つまり、毎日最終電車の時間まで居残る必要がなくなります。

こうした２枚の地図は、全メンバーと関係者全員に公開し、常に最新の状況を示すようにメンテしておきましょう。進捗以外の変更がある場合には、もちろん全員を集めて、変更となった理由を明らかにしていきましょう。

ポイントは、地図で大事なことがすべて全員に把握できるようにしておくことです。


さあ、今日も地図を広げて、冒険にでかけましょう。

最後までお読みいただき、ありがとうございました。