「BPM とかを読み下す」までの流れ
BPMN
ビジネスモデルは BPMN という「書く人によってなんとなく書かれるモデル図」として記載される。BPMN の内容とチケットの内容を紐付けると次のようになると思う。
(この記事を参考にさせていただきました)
[フローオブジェクト]
イベント = status (todo, done)
アクティビティ = status(doing など)
ゲートウェイ = 完了の定義
[接続オブジェクト]
シーケンスフロー = チケットのステータスの通る場所(頭の中にある)
メッセージフロー = プログラムでフックしてればメールが飛ぶかもね
関連 = ステータスのフローを作る時に注意すべきこと
[スイムレーン]
プール = アサイン
レーン = ロール
[成果物]
オブジェクト = チケットに添付するもの
グループ = 対応するものなし
注釈 = チケットのコメント
BPMN は UML はわかりにくいからわかりやすくしてやったぜ！という
意気込みのもと作られたらしいが、はっきり言ってわかりにくいと思うよ。
アクティビティに対する条件を記載するのは、注釈とゲートウェイでフロー管理するんだろうけど、ちょっと厳しいと思う。拡張されたアクティビティは、現実に対応するためとはいえ筋が悪い。
ループは、ゲートウェイを通るまでやるということなので、特に書く必要を感じないし
アドホックは、ワークフローがひとつにしか流れないという前提と戦っている。
ここに記載されていますが、BPMN で表すのは UML のアクティビティ図の部分 だけ。
IT システムを作るには、アクティビティ図はホンの一部なので BPMN が出来れば簡単にシステムが出来ると勘違いしないほうが良いと思います。発注する人はわからないかもしれませんが、こんなのは コンサルが金をとってくための紙切れですよ。ほほほ。この紙切れを作るのに、数週間もかけてしまうようなら、プロジェクトのやり方を考えなおしたほうが良いかもしれません。
BPMN 自体は、図 なので解釈できる必要があります。
そこ出てくるのが BPEL です。
BPEL
BPML を機械化するための変換処理機構全般の呼び名。
WS-* の亡霊とも言うべき WS-BPEL という規格もあるらしい。
こういうとこを見ると良いですよ
個人的に興味ない。
まとめ
アクティビティの所をプログラム化できるか、できないかで判断していくと早いんじゃないかな。
できるのなら、プログラム化を進めていく。
どうせ完璧なのは、最初からは無理なので サクサク作れる簡単なツールを作っていくと良いのではないでしょうか。
あるアプリを作るために調べたんだけど、コンサル内容が多すぎて、読むのにつかれたよ…
十数サイトをみたのですが、中でも取り上げている 日揮さんの記事が一番わかり易かった。
あれですよ、奥さん。
こうなんじゃないかなー、という日記なので、間違いがあれば指摘くださいな
Voyage Group に転職しました
Voyage Group に転職しました。
// こういう時に、どこの子会社で働いているかとか、書いていいものか迷いますな。
基準は人
私は人を見て、仕事先を決めています。実は、前職も人で選びました。前職はこの人と働いてみたいなー、今回は この人のいる会社なら間違いないだろう
という感じで決めています。
まぁ、どっちかっていうと仕事内容では決めていないですよ、って話です。
仕事内容について
じゃあ、仕事内容について全く考えていないかというと、そうでもない。自分にある程度やりたいことがあるので、優先順位をなんとなく付けて
その基準で選んでます。例えば、楽しく開発ができること、開発だけじゃなくて
他の見方や考え方などを学べること・発揮できる場所が将来的にあること、などが
自分の中で存在しています。
TOC でいうところの、ブランチなんかも書きましたね。
最後の二者から選ぶ時は、クラウドを使ったり…。
ま、パーソナル過ぎて見せませんけど…。
人材紹介会社について
金で人を紹介する会社から何件かお話を頂いたのですがメールと、会った人の言うことがちぐはぐすぎるということが多々あり、あまりいいイメージがなく、ほとんど使いませんでした。
一番面白いなぁ、と思ったのは facebook にスカウトメール、数カ月後に Linkd-in 経由で
メールをスカウトメールを送ってきた渋谷の某社。経歴などを見て、どうしても！という
会社があるので会ってもらえないか？という話。おもしろそうだから会ってみたら
「職歴や資格」を聞いてくるので話をすると 用意していたのより良い枠を紹介できる！と。
あれ？雇いたいって話じゃなかったの？？ってね。
これくらいチグハグだと笑い甲斐があってよかった。
転職してみて
<ステマ>椅子が良い椅子なので長く座れたり、飲み物とか無料。会議室もかっこいい思ってた以上に働きやすいなぁと感じています。
殺伐としてないというのも大きいです。前職からだと、だいぶ異世界に来た感じです。
うちの子会社は、社長を中心にいい感じでまとまっています。プロジェクトは
UX の考え方を中心に、アジャイルを始めた頃の感じで開発をしています。
今週から相対的な見積を入れたりしてますが、CI とかもこれからな感じ。
今は新規開発なので、会社のメインのサイトがどうなっているかは知らないのですが
結構、いい感じとの話です。
まぁ、導入については、そのうちどこかで発表できるかもです。
会社に対する貢献とか
しばらく勉強会に節操無く行くのをやめようと思っている人間のいうことじゃないですが、こういう開発をしたい、生活をしたいと思う人を呼び込むのも大事な貢献かなぁ
と思い書いています。
私個人の時間の切り売りは限られているし、技能もたかが知れているので、優秀な人に一緒に働いてみないか？
と言うのは重要なことだと思ってます。
あとがき
実は転職記事はもうちょっと早めに書こうと思っていました。ただ同じ時期に転職された方の記事を読んで、ちょっと日付をずらしました。
そして、まぁ、他にも色々あって、さらに日記が遅れるということに…。
転職するときの価値判断は人それぞれだと思うので、記載しようと思い書きました。
ほそく
アジャイルな開発は、ツールとかじゃないという Tweet をされたので補足。アジャイルマインド自体は、もともとある会社なのです。どーやっていいかわからないとか
時期じゃないとかで見送られていただけなので、そこに使い方とか、考え方を少しいれただけ。
言うなれば、開発者よりの SM 成分が少し足りなかったので、補えればなぁと動いています。
医師の説明を受けて感じたこと
今日は父親のがん手術の術前説明だった。
医師は、説明に紙とペンを使い、必要なところだけPCを使っていた。例えば、内視鏡の写真や、スキャン結果にPC を使用していた。IT 系だとすべての説明にパワポやWord, Excel を使ってしまうところだけど、その場で必要事項や合併症やリスクを書きだしていくほうが医師の頭の中のものを示しているので安心感を与えるのかなぁ、などと考えた。
この時、医者は忙しいから〜、という言い訳も浮かんだが、SI にいた時のことを考えると、SI も忙しかったと思う。だから IT 系かどうかは関係ないんじゃないかしら。
また、説明に使った紙にサインをさせて説明した証拠とするのもいい手だなぁ、と感じた。
手術の説明はこんな感じだった。
・一般的な検査までの流れ(いつ手術病棟に移るとか、説明するタイミングとか、必要なモノとか)
・どういう点に問題があるのか？(腫瘍の場所)
・MRI の結果を見たが、素人目にはよくわからないけど、白くなってるところが腫瘍とか調査結果を説明してもらった。
・どういう手法で問題を解決していくのか？(手術方法とその他の術式。また、その手術方法を選択した理由)
→この時に、絵を書いて説明してもらった。
・開腹した時に、手術をしない場合の説明
・手術中に考えられる状況、それに対する対応方法
・手術後に考えられる状況、それに対する対応方法
・手術後の合併症や、再手術の条件、対応方法
・退院の条件、予定通りに退院できるおおよその可能性
ipython のメモ
ipython の使い方のメモを付箋に残しておいたんだけど、見事に忘れていたのでblog化。
ipython -cl で、doctest にも使える >>> という出力をする。
object? で、object の情報を出力
@run filename で、ファイルを実行
@pdb (filename) で、pdb 実行
In[n] 、Out[n] で、その行の内容を list として使える。 or 実行できる
@macro myMacro 2:4 で、2-3 行目をマクロ
@save filename 2:4 で、2-3 行目をセーブ
# 2:4 は、スライス
@hist -n 5 で、直近 5 回分の history 表示
