2013-03-11

急性心筋梗塞でダウンしたお話・・【搬送から手術編】

まさか、この年齢で『急性心筋梗塞』で入院することになろうとは・・

さて、この『心筋梗塞』で若くして亡くなった方といえば・・
サッカー元日本代表の松田直樹選手（享年34歳）が思い出されます。

・・で、この病気は中高年の方が多いのですが、30代、40代の方も十分に
危険性があるという事で、自分の経験を備忘録含め、何かのお役に立てるかもと思い、
まとめてみます。

とにかく、早期発見がもっとも重要な
病気ですので、少しでも心臓があれ！？と思ったら、循環器内科または内科へ！

ここからは時系列で行きます。

【2013年2月7日(木)】
　いつも通り、出勤。
　朝からなぜか身体の『左側の肩甲骨あたりがこっている』ことに気付く。
　まあ、いつもの肩こりの延長か、運度不足か・・と特に気にしないで過ごす。

【2013年2月8日(金)】
　左側の肩甲骨のこりを気にしながらも出勤するも、ここでさらなる異変に気付く。
　PCが入っているカバンを持って、最寄駅へ向うも、10mくらい歩くと、しんどくなって
　カバンを置いて、一休みしたくなってしまう。
　つまり、休み休みでないとカバンを持って歩けない・・
　特に手ぶらだったり、会社で自席に座って仕事をする分には変わりがなかったので、
　きっと疲れかなと思い、通常通りに仕事をこなす。
　この日は次の日の3連休の為にも、早めに就寝した。

【2013年2月9日(土)】
　朝起きても、特に変わらず
　さらに、『左肩甲骨あたりの激しいこり』に加えて、
　『心臓あたりが、かるく締め付けられてる』感じがあり、やはりこれはおかしいと感じ、
　病院へ。幸い、かかりつけの内科が近くの大病院の循環器内科に居た方だってのもあり、
　迷わずにかかりつけの内科に。

　症状を伝えた後、レントゲン、心電図の結果を見た先生が何やらあわてた様子・・
　偶然にもその日は超音波検査の技師さんが来ていたので、心臓の超音波も
　確認してもらった所、何やら先生とゴニョゴニョ話・・
　その後、ベッドに寝かされ、酸素マスクをつけられ、
　ここで『急性心筋梗塞』に違いないと告げられる。

　入院先の病院をどうするか？家族への連絡と同伴について等を調整し、
　その間救急車が到着し、先生のコネクションがもっとも強い『国際親善総合病院』へ搬送。

　＜救急車＞
　　救急隊員からは意識の確認、症状の確認、等々を
　　ヒアリングされ、あっという間に病院へ到着。
　
　＜緊急救命室＞
　　あれよあれよというまに、服を脱がされ、点滴、注射、レントゲン
　　超音波とテレビドラマさながらの内容・・
　　薬を飲まされたり、おしっこの管を入れられたり（これがかなり痛かった・・）
　　・・とはいえ、ドラマほど殺伐としていなく、皆様の口調は穏やかでした。
　
　＜手術室＞
　　そのまま手術室でカテーテル検査及び問題の血管の拡張及びステント挿入の手術が開始された。
　　
　　みなさんは手術というと、全身麻酔で患者さんは眠っていて、
　　医師が「これから〇〇の手術をはじめます・・メス・・」なんてシーンを想像するかもしれませんが、
　　今回の手術はこんなのとは異なり・・まず、全身麻酔ではありません！局所麻酔です。
　　
　　まずは右手首の動脈から直径２ｍｍ程度の細い管（これがカテーテル）が刺され、
　　動脈をたどって心臓までそこからは複数の先生が「あーでもない、こーでもない」と言いながら、
　　たまに「苦しいですか〜？」「胸は苦しくないですか？」と聞いてくれました。
　　自分も特に痛みはなく、カテーテルが通っている感覚もなかったので、
　　非常に不思議な感じでした。

　　処理が一通り終わった後、簡単に状況をモニタ越しで教えていただきました。
　　まず、血液自体は完全に止まっていたわけではなかったので、症状が軽くすんでいたのだろうとの事
　　これが完全に止まったら、胸が苦しくなって倒れていたでしょう・・と。
　　さらに、他の心臓の血液に関しては問題は見当たらないとの事で、
　　入院しながら今後を考えていきましょうとのこと。

　　すべてが終わったのは１時間くらいだったかな、
　　点滴・酸素マスクをつけられ、集中治療室へ・・

　　手術が終わったあと、運ばれている最中にチラッと長男君の不安そうな顔が
　　今でも覚えています。

　　この日から、自分の心臓と一生向き合う日が続く訳ですが・・

　　さて、長くなったのでここまでにして
　　続きの入院生活編は、また次の機会に・・

2012-12-25

2012年を振り返ってみると・・

2012年も色々とありました・・ちょっとここで今年１年を振り返ってみると・・

3月
　→　次男が生まれる！この日から睡眠不足の日々が始まる
　→　誕生日が来て、四捨五入すると40歳になってしまった・・

4月
　→　念願のTV出演を果たす
　　（約5秒　新橋駅前でのサラリーマン向け該当インタビュー）
　→　長男くんが近くのテニススクールに通う

6月
　→　素敵な女性ともお知り合いになれた通っていたテニススクール（緑園都市）を辞める
　→　次男くんの定期的な病院通いがはじまる

8月
　→　次男くんの病院通いが終了！有休をかなり使ってしまっため、夏休みは２日間

9月
　→　Dreamforceには当然行けず・・

10月
　→　徐々にForce.com Developerの皆様とお知り合いになれた方が増えていく。

11月
　→　いきなり洗濯機が壊れる
　→　Salesforce認定試験を3週連続で受けるも結果は2勝1敗

12月
　→　Cloudforce Japanにて（自分にとっては）高級なカメラが当たる
　→　幼稚園・小学校・中学校と一緒だった懐かしい友人と再会
　→　内気でシャイな自分が『Force.com Advent Calendar 2012』に参加
　→　マンションの役員会のあみだくじで大当たり！なんと、仕事がない役職に就任！　

仕事面では散々！？だったのですが、プライベート面では山あり谷ありでしたが、
総じて良いことが多かった気がします。

さて、来年はどんな波乱が！？起きることやら・・

2012-12-19

タイプの異なるライセンスが同居する組織のダッシュボードの実行ユーザーに注意！

そう、あれは昨日の午後の出来事・・

『あれ、権限もあたえてるのにダッシュボードが見れない！なぜだっ！』

結局、約１時間近くハマってしまい、
見つけた原因は・・ダッシュボードの実行ユーザーにありました。

デモ環境など、結構めんどくさい時はダッシュボード実行ユーザーは、
管理者権限のユーザー（Salesforceライセンス）で固定してしまうのですが、この設定だと「Platformライセンス」のユーザーからはダッシュボードはちっともアクセスできません。

ライセンスをまたがってダッシュボードを見ることは出来ないみたいなのです。

あっ、ここで問題になるのは「Platformライセンス」のユーザーさんです。
確かに、PlatformライセンスはCRM機能部分にはアクセスできません。

以下、ヘルプです。

https://help.salesforce.com/HTViewHelpDoc?id=dashboards_select_running_user.htm&language=ja

重要なのはこの一文

『Salesforce Platform または Salesforce Platform One ユーザライセンスを持つユーザは、ダッシュボードの実行ユーザも同じ種類のユーザライセンスを持っていれば、ダッシュボードを参照のみできます。さまざまなライセンスタイプのユーザに、個別のダッシュボードを作成することを検討してください。』

・・そうでしたか・・皆様もSalesforceライセンスとPlatformライセンスの同居組織の時をご注意を！

・・・って、知らなかったのは自分だけだったりして・・

2012-12-18

イケてる！？マニュアル作成講座 for Force.com案件

突然ですが・・皆さん、『マニュアル』って作ってますか？

ここで言うマニュアルとは、Salesforce CRMやForce.comの導入案件の際の
ユーザーさん向けにベンダーが作成するオリジナルの操作マニュアルや
運用マニュアルの事です。

なんだかんだカスタマイズや追加開発を担当したエンジニアが
そのまま作っている・・・というケースが多いのではないでしょうか？

さらに、中小企業向けの比較的規模の小さめの案件をやっていると、
ユーザー側に特定の管理者がいない・ITリテラシーが高い方がいない等々
運用開始後の体制が十分とは言えないケースもあると思います。

そうなると、意外と案件の最後で作成する『マニュアル』が
今後の運用に重要な位置づけになる場合もあります。

ここでは、SalesforceやForce.comの案件ならではの
マニュアル作成のポイントってここなのでは？
実際にはこんな感じだとイケてるのでは？
ってのを完全な『主観的な視点』でまとめたいと思います。

どちらかというと、規模は小さめで、
簡単な現状業務のヒアリングから、カスタマイズ、ユーザーレクチャー
といった一通りのあるような案件を想定しています。

それでは・・

【こんなマニュアルがイケてる！？３つのポイント】

＜ポイント１＞
　操作説明ページとリンクした業務フローがある。

　→　クラウドならではの他部署や他組織等のコラボ等、
　　　新しい業務フローになる場合は、誰がどのタイミングでどんな入力が必要なのか？
　　　を明確にすることで、ユーザー側での参照率が上がると考えます。

＜ポイント２＞　
　標準機能内であろうとも、利用が想定されるカスタマイズ方法は
　『具体例を入れて』マニュアルに含める
　
　→運用後にユーザ側で必ずやカスタマイズや設定変更する箇所が明確になっている場合、
　　そのカスタマイズ・設定方法も含めることで、運用開始後の不安要素を軽減します。

　たとえば・・
　　『利用者が増えた時、減った時は』『組織が変更になった時は』
　　『商談のフェーズを増やしたい・減らしたい』『レイアウトを変更したい』
　　『自動計算の式を変更したい』・・等々

＜ポイント３＞
　管理者向け、ユーザー向け、営業部門、サポート部門等、コンテンツの対象範囲を明確にする

　→　メンテナンス方法を中心とした内容の管理者向けコンテンツや、
　　　操作方法を中心とした利用者向けコンテンツマニュアル。
　　　さらに、『商談』だったら営業部門、『取引先』だったら管理部門等
　　　どの部署がどのページ・どのセクションを重点的に読むべきなのか？
　　　をハッキリさせるのも効果的です。

以下、ザックリとした例を図にしてみます。
（ここでは、商談進捗管理＋受注後ポータルでパートナーと共有という
　非常にシンプルな案件を例にまとめています）

＜全体構成例とポイント２の例＞　

＜ポイント１と３の例＞

ちなみにマニュアルの作成工数を少しでも減らすために、
自分は打ち合わせ資料を、マニュアル作業に流用できるよう
作っています。

・・とはいえ、実際は予算・工数・スケジュール等の兼ね合いもあり、
内容の濃さはその都度調整って感じですね。

あくまで『１つの考え方』として、少しでも辛い！？マニュアル作成作業の
参考になれば嬉しいです。

このエントリーはForce.com Advent Calendarに参加しています。

Force.com Advent Calendar 2012 : ATND

是非、他の方々の素晴らしいエントリーもご覧ください

2012-12-18

『Force.comと他社のクラウドプラットフォームを比較してみよう』

第1回の今回は・・(第2回はぜひ他の方に・・)

クラウド型ERP(CRMもEコマースもあり)の『NetSuite』(ネットスイート)
のクラウドプラットフォームとザックリ比較をしたいと思います。

※自分の経験上の感覚的な比較なので、まあ、こんなのもあるんだなあ
　と息抜き程度、箸休め的に見ていただければと思います。

※どちらかを優劣つけるものではありません。

それではいってみましょう！
上段がForce.comで下段がNetSuiteです。

【クラウドプラットフォーム名称】
　Force.com
　SuiteCloud

【マウスクリックによる開発環境】
　Force.com Builder
　Suite Builder

【開発言語および開発環境全般】
　Apex（Javaに似た独自言語）
　SuiteScript（すべてJavaScriptで記述）
　　→ Server Side JavaScript or Java Script

【開発デバック環境等】
　開発コンソール、Force.com IDE
　SuiteScript D-Bug

【Web APIによる外部接続】
　(Web API)
　SuiteTalk

【ユーザーIF開発】
　Visualforce（タグベースのマークアップ言語）　
　Suitelet,Suite UI Object　（独自の言語はなし）

【その他】
　（両方）ガバナー制限はもちろんあり

Force.comは皆さんご存知だと思いますので（！？）

以下、NetSuite側の特徴をまとめると・・
大きな違いはやはり、開発言語はすべて「JavaScript」です。
レコード単位でのイベントトリガーとなる処理は、Sever Side JavaScriptで、
入力チェックなどはClient側で動くJavaScriptになります。
提供されているAPIも、Server Side、Client Sideでそれぞれ使用可能・不可能・制限等
と書かれています。

・・これだけだと、出来る事に大きな違いがないのかと思うのですが、
DBの操作部分でかなり違いがあります。

DBを直接触って、クエリかけてドドンと検索・抽出って感じではなく、
指定された検索用メソッドを経由しないとデータにアクセス出来ない点や
標準テーブル（顧客・商談・注文・請求・在庫・仕訳等々）も、
Insert,Edit,Deleteの可能・不可能等も細かく決まっている為、実装できる要件に注意が必要です。

※例：『Customer（顧客）』
　　　　→　フルアクセス可能、
　　　　　　Server Side Script、Client Script両方ＯＫ
　　　『Item Fulfilment(商品出荷)』
　　　　→　copyやInsertは不可
　　　　　　Server Side Script、Client Script両方ＯＫ・・等

また、もう１つの特徴として受注・請求等のトランザクションデータが作成されると、
自動的に裏ではjournal Entry(仕訳)データが作成される等、財務会計側の視点で
数字の不整合等を防ぐためなのかもしれません。

そのため、クラウドプラットフォームとしては『汎用性』よりも
『既存機能に対しての拡張』
としての開発プラットフォームとしての色が強いのかもしれません。

それでは、個人的な解釈でまとめます。

＜Force.com＞
　CRMに対しての拡張もでき、さらには全くCRMとは関係のないアプリもクラウド上で構築可能
　クラウド上に直接、DB含めて業務アプリを開発可能。

　Socialの考え方も含め、1企業内の業務アプリという枠にとらわれず、
　顧客・パートナー等々、企業の枠を超えた広い範囲に“つながる”クラウドな感じ

＜NetSuite＞
　標準機能が基幹にまで及んでいることから、あくまで標準で実装出来ない拡張機能を構築

　顧客管理、営業、Ｅコマースから販売管理、在庫管理、請求・入金、財務等、
　１つの企業に対して深く“入り込む”クラウドな感じ

こうしてみると、クラウドベンダーのそれぞれの方向性ってのが、
プラットフォームからも垣間見れる気がしますね。

このエントリーはForce.com Advent Calendarに参加しています。

Force.com Advent Calendar 2012 : ATND

是非、他の方々の素晴らしいエントリーもご覧ください