TEKITOU life,engineer, and father

「回り道人生」 破天荒”文系”エンジニア

回り道人生

XP祭りでの発表

XP祭り2015での発表を終えた。
http://xpjug.com/xp2015/

2012年に初参加。
2013年に二度目の参加。
2014年に初LT。
2015年に初セッション。

全ては「本がただで貰える」からだ!

2012年:実装パターン

実装パターン

実装パターン

 

 2013年:アジャイルレトロスペクティブズ

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

 

2014年:忘れた。

2015年:プログラマのための論理パズル

プログラマのための論理パズル 難題を突破する論理思考トレーニング

プログラマのための論理パズル 難題を突破する論理思考トレーニング

 

ちなみに2015年に狙っていたのは「システムテスト自動化 標準ガイド」だ。

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

 

これを十分得られるだけのスタートダッシュを切れる位置にはいた。
おおよそ獲得することは可能だった。
しかし、私は別の本にした。

 

なぜなら

 

悦◯が欲しいと言ったからだ。
要は譲ったのだな。

まぁいいや。とりあえず、先2,3年はネタにさせていただく。

カンバンよりケイジバン

いろんな現場でカンバンを作っては内容を変えているけど、その話。

今、カンバンを作ってそこにタスク上げさせている。

カンバンを中心に朝会を行い、やる事/やっている事を共有している。

が、

私的に不満が一杯ある。

それは、

1)個人タスクしか上がってない

2)リアルタイム性が薄い

つまりは"情報量が少ない"ってこと。

仕事中、カンバン見ないわ人の仕事に気を掛けないわで思いついたのが『ケイジバン』。

別段なんという訳では無いが「不満や不安があったら付箋貼って下さい」的なもの。

これが意外とHit!

さらに「お菓子神社」の前に置くことで、「お菓子モグモグしながら皆の課題感を読み、さらには書き込みや議論、新しいタスクを産んだ」状況が出てきた。

まぁ真面目にチームでカンバンやってれば、朝会で出るような話題なんだけどね。

Problem/Tryボードと言うともっとキャッチーかもww

パタン

今日の飲み会での備忘録。

以前、社内でパタン・ランゲージ勉強会に参加した。

とある問題に対してパターンを書いてみようというもの。

Forceの無い世界では目の前に見える解決策を実行すればいいが、いろいろなForceがあるので真っ直ぐに実行出来ないと学んだ。

しかもForceは当事者により違い、様々なベクトルに力が働くのでSolutionが上手くいかなかったりするのだと気が付いた。

時は流れSGT2014。

懸田さんのLTを見て、Forceを感じた。

懸田さんは上手くいった事をパタンに起こす時に上手くいったSolutionの選択理由(制約)をForceと言っていた。

成る程とForceの在り方に納得したのだった。

更に時は流れ、今日。

パタンは来ると思ってるのに流行らない。

局所的には理解されて有用であると感じる。

でも、流行らない。

この何故に関して上司が、

Contextを共有するのが難しい。

情報が抜け落ちてしまい共感しにくい。

と言われた。

確かにパタンの在るべき究極にまで高めると、然もありなん。

しかし、自分はそこまで求めてない。

理想があるのは分かるが、理想論であり現実ではないと感じる。

何故だろう。

と一つの結論。

パタンはContextが共有出来て感情(emphathy)が薄れない範囲において有効である。

これは仮説。

しかし、こんなもんで良いんじゃないかと納得した。

取り敢えず、そんなもんだと扱うことにした夜。

現場におけるADAPTモデル

DevLOVE Advent Calendar 2013の38日目のエントリです。
よく考えたら去年のDevLOVE Advent Calendar 2012も38日目でした。完全な偶然ですw

【38日目】ぼくのかんがえたぷろふぇっしょなる
  http://devloveblog.wordpress.com/2012/12/22/adcal_day38

・自己紹介

名前は、原田巌(@iwaoRd)です。
システム開発経験は15年くらいで、最初の『現場』から客先常駐で泥臭く生きてきました。何気に転職が多く、中堅SIerから始まり、フリーランスとして独立期間4年挟んで小さいSIer→大きなSIerとキャリア積んできています。
最近はモデラーとして客先常駐しており、今回のテーマである『現場』で気を付けている『ADAPTモデル』について話したいと思います。

私をもっと知りたい人は、生き様が書かれたUltimate Agilist TokyoのOpen Jam発表資料を見てください。

発表資料:【OpenJam】どんな勉強会でも話題になる目的重視。そのコアに迫る
 http://www.slideshare.net/mobile/iwaoRd/whywhywhy

・ADAPTモデルとは?

最初にADAPTモデルの説明からしないといけません。
このADAPTモデルはMike Cohnさんの書いた『Succeeding with Agile』に書かれているScrumの適応に向けたアクティビティの流れを表したモデルです。 

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

 

 Scrumの適応は、以下に説明するようにA・D・A・P・Tの順に進んで行きます。

『A』wareness:気付き
『D』esire:情熱
『A』bility:能力(を身に付ける)
『P』romote:対外に成果を見せる
『T』ransfer:広まって当たり前のコトとなる

 簡単に物語調で説明すると次のような流れになります。

(Agile開発の適応に際して)最初に今のままでは上手くいかない事に気付き、その問題を解決なければならないと情熱を持ちます。解決方法としてAgile手法を学び、実践してその効果を発表します。効果を聞いた人はそれぞれの現場で試し、いつしかその対応が当たり前の事となって自然に行われるようになる。

 説明をまとめた資料はScrum Gathering Tokyo2013で発表したSucceeding with Agileの読書会である品川アジャイル紹介LTを見てください。

・今現在、自分が現場で何をしているか

さて、本題です。

私がいる現場は泣く子も黙るSIerの現場です。周りからはオワコンと称されていますが、その中で私は課題に立ち向かいつつ、一つ一つを対応していっています。
Waterfallな現場でキャリアをスタートし、今ではAgileに開発を進めていますが変わらない事があります。

それは対話です。

なぜ対話が必要なのか。そもそもシステムの構築を生業とするのであれば、システム屋が勝手に作成して、その結果を売り付ければいいはずです。

でも、現場では対話を通して問題を明らかにしつつ合意しながら進めています。

なぜでしょうか。

不確定時代だからと言うのもありますが、人との対話を通してお互いを「理解して、理解される」事が重要で、人との「そうか、こうしたかったんだよ!」という気付きから得られる情熱を生み出す事で、より良いシステムを作りたいと思っているからです。私が現場で実現したい事はまさにそれです。

- そこでADAPTモデルを考える

人との対話を通した気付きや発見も、Scrumの適応だけでなく、実は変化の流れADAPTモデルを適応できると思っています。

例えば、私自身、アジャイル開発にハマった理由もADAPTモデルで説明が出来ます。

Waterfallな開発案件を実践していた私は「どうしてWaterfallで上手くいかないのか」を常に疑問に思っていました。しかし一方で最高に上手くいったチームもありました。違いはなんでしょう?
そこで出会ったのがアジャイル開発でした。アジャイルでは上手くいったチームで良く現れたコトが言葉として表されている事に気が付きました。そして、この方法なら最高の開発が出来るし、お客様も満足するのではないか!?とアジャイルの道を極める事を決心しました。

つまり、「自分が現場で何をしているのか」「何のためか」「何をするつもりなのか」というAdvent Calendarのお題を考えると『現場』とは、

 自分(や他の人)が良くしたいと思って情熱を傾けている場所である

と言えると思います。
本当にどうでも良ければ間違いに気が付いても「自分に関係ないのならいいや」「あいつら、また言ってら」となるのだと思います。そのような場合、その場に参加していてもそれは『現場』であるのか?と言われれば、そうでないと思っています。

更にADAPTの流れは一つではありません。Promoteした結果、新しいAwarenessを見つける事があります。その時、もっと先の理想の形を見つけられるADAPTの旅が開始されるのです。(現場でのKPTによる改善は旅立ちの第一歩に役立ちます)

こうして物事は繰り返しでなくより良い方向に向かってスパイラルアップしていく訳です。これがカイゼンマインドであり、発揮したい場所こそが『現場』です。 

・自分が想う現場とは何か?

さて、もう一度、『現場』について考えます。現場とは”仕事場”でしょうか?

- "仕事"だけじゃない!

『現場』とは職場である、と捉える人は多いと思いますがそうでしょうか?
DevLove甲子園で本橋さんが『現場』とは次のような事でないかと話されていました。

現場とは価値を出すために注力している環境のこと

私も同意します。『現場とは仕事だけの話ではない』です。

- 『現場』は何処にでもある、そして影響し合っている

私は最初のSIerの時、良くも悪くもサラリーマンでした。金がもらえれば良い程度で勉強も余りせずに現場の諸問題に表面的な解決をしてきました。しかし、子供が生まれてから変わりました。私には家庭と言う『現場』が出来たからです。こなせばいいと仕事をしていた場合と家族を含めた未来を描く場合ではマインドの変化が必要でした。その結果として、仕事のやり方も変わったのでした。

自分自身が関わる現場において周りの人や環境を巻き込みつつ、空間的、時間軸的な”先”に向かって現場は広く続いています。一つの現場は他方の現場に影響し、何一つ、独立した現場なんて存在しません。
とある開発プロジェクトだけで考えても期間の観点において終わりはあるのですが、次に紡いでいくモノがあり、繋げていく事が重要です。
そして、仕事で学んだ事が私生活に、私生活で得た経験が仕事に生かされていくのです!そう、現場と現場は密接に関係しています

ある気付きから情熱を燃やし、自身で経験した結果、他の新しい気付きに繋がっていく、生かされていく。その連鎖の流れはADAPTモデルそのものではないでしょうか?

・次に”紡ぐ”こと

このブログ記事をここまで読んだ皆さんにも行なって欲しい事があります。

1)『現場』を(特に目的を)明確にすること
2)対応する為に真摯に物事にあたること
 (この時、対話が重要で、基本姿勢として「理解して理解される」事を忘れない事)
3)上手くいかない事は新しいAwarenessに気が付けた事。次のADAPTモデルの流れを意識して変化に対応すること

ついでに言うとADAPTを回すのにモデリングを通じた共通認識の形成が有効ですよ、と宣伝しておきますw

slideshare:モデリングもしないでアジャイルとは何事だ

 

さて、次ですが尊敬する友人である森さんです。
私がプレゼンする時、私が心の中で演じているのは森さんです。私は森さんの語り部が好きで、特に熱中している時の手振りが最高です!
きっと良い話が聞けると楽しみにしています。

・本当に最後に。

本日12月17日に我が家に新しい家族が増えました
※と言いたかったのですが、生命の神秘とは不思議で来週に延期に!
 でも、文章を変える対応のテンションがないのでそのままお楽しみ下さいw

まさに新しいADAPTのスタートに立ったわけです。
これから二児の父として仕事や家庭において変化に対応しなければなりません。上手くやれるのか不安はありますが、家族での輝く未来を目指して冒険が始まりました。

そして出産準備に追われる中、「お、俺、ブログ書かないといけないし!」と言う私の要望に「出産準備手伝ってからやれ!」とブログ更新する許可と時間を割いてくれた家族に感謝しています。

これからもいろいろな現場で四苦八苦しながら、現場で全力を尽くしていきたいと思います!

XPへの回帰

私の中だけで盛り上がっている事ですが。

最近、アジャイル開発だScrumだと叫ばれていますが、一旦、XPに戻る気がしています。
特にDevelopers Summitやいろいろな勉強会に参加して感じる事ですが、

・文書のやりとりなど「コミュニケーションより技術」な論争が多い
・ScrumはFrameworkなので芯が無い人は迷子になる
・TDDの立ち位置?

ココら辺の橋渡しや理論武装としてのXPが担う箇所が多いと感じています。
今一度XPを見直すべきだと思います。

んな訳でScrumフレームワークの土台にXPライフサイクルが息衝いているのでは?と。


XPを勉強していて、今のアジャイル開発(単に本を読んでスタートした場合)で欠けている点が以下だと思います。

1) ソフトウェア開発の経済学
 「待つ」と言うオプションの価値として「下落リスクを回避する」事を認める事
 未来を邪推して悩み、ムダな機能の実装をやめる

2) 意思決定の遅延
 今日の決定コストが高く、正しい可能性が低く、明日よりよい方法を知る可能性が高く、将来設計を行うコストが低いのなら、今日必要でない設計の決定を今日してはならないこと。
 それよりも今の機能をシンプルにする事に注力する。

3) 変更のコスト逓減
 変更のコストが時とともにゆっくり上昇し、そのまま一定の値を保つのであるのならば、プロセス内で大きな決定をすることを可能な限り、遅らせて決定が正しくなるまで待つ
 その為の「シンプル設計」「テスト駆動」「ペアプログラミング

 

 

でも、まだ腹落ち感がないですね。
じゃあ、それって例えば何?というメタファー(実例?)があれば納得感があるのでしょうが。


XPはまだ「エクストリーム・プログラミング入門」を読んだだけです。
しかし、Twitter上では角さんと討論させて頂いたり、Scrum同様にまだカイゼンの余地や、その先に大きな可能性を秘めていると感じています。

XPマニアの人がいたら、一緒に議論させてください。  

Twitter自問自答:誰が為の提案?

日記を書く習慣が全く身に付かないですね。
Twitterとかfacebookで言いたいことを言って、満足するので。

ただ、ある時、Twitterで連投して自分の思いに火が点く時があります。
連投し終えた後に「ブログで書けよ」と思うので、少しずつ形にしよう!と言う・・・

 

要は手抜き企画!

 

と言う事で第1弾。

これはボトムアップによる業務提案の苦しみを述べた句ですw

日々の仕事はどうしても反射的にやりがちです。
「アレを作って下さい → アレを作りました」の流れ。
この時、決定的に欠けているのは「アレは何で必要なんですか?」の目的意識です。

で、本題。
業務提案している時に実現の可能性、リスクヘッジ、部署や会社の目標や挑戦を盛り込んでアーキテクチャやスケジュール、プロセスを考えた時にマネージャーさんに言われた

「これは○○さんが上に話せない内容ではないか」

の一言。

やっていた提案はさておきw、Agile推進している時の事が浮かびました。
Agile開発を勧める時、自分達がやりたい!こうすればリスクが少なくて済む!と言うように、それを採用する側、特に窓口となる人の立場を考えていないのでないか、と。

もちろん、やり方は間違っていない。
ただ、受ける人の覚悟を求めるばかりで「俺の考えを理解しろ!」となってないかとハッと思った呟きです。

blogにしない位だから答えもなく、何となくADAPTモデル(Awareness→Desire→Ability→Promote→Transfer)は自分だけでなく、関係する全員にも必要なんだよなぁ、と今もつらつら考えている日々です。

ぼくのかんがえたぷろふぇっしょなる

これはDevlove Advent Calendarに投稿したものです。
一部、文章を改悪しています(ニヤリ)。
 


■自己紹介

【38日目】担当するIT業界に数ある原田の中で「じゃないほう」の原田こと@iwaoRdです。
アジャイルな勉強会には多い時に月10回前後参加しているので、実は会った事がある人は多くいるのではないでしょうか。
基本的に受け身の人間なので気軽に話し掛けて下さい。

また、最近は参加するだけでなく、Ultimate Agilist TokyoではOpen Jamでアジャイルマインドの話をさせて頂いたり、outputも増やしたいと思います。
私のスライドはジョジョや銀英伝など漫画を中心に展開するので、そっちの世界のネタにも付いて来て下さいねー!
(そんなネタSlide発表を社内でも社外でも気にせずやってますw)

 

■Professionalとは?


さて、本題。
最初にあくまで私の所感である事を述べておきます。

その上でProfessionalとは?


1) スキルフルである

Professionalと一言で言っても調べると「XXXプロ」は沢山います。
「プロ」と言うと金を稼いでいる事を最初に思いつきましたが、金を稼ぐ前提として、プロは価値を届けていて、その価値は「スキル」からきており、更にはそんなスキルが「スキルフル」である事を強調したいです。

Wiki先生によれば、

 スキルフル:「熟練したさま。巧みなさま。腕の良い。上手な。」

だそうです(知らずに感覚で使ってたw)。
つまり、スキルは資格や勉強するだけでなく、実践し、向上させる必要があります。

2) マインド

では、スキルフルであればいいか?と言われたら、それは違うと思っています。
スキルフルなだけでプロであるなら、知識さえ得ればプロでしょうか?
私はそこに「思い」が必要だと考えます。それが「自分軸」です。
以前、参加したコーチングフェスタで平本あきお先生の講演中で「自分軸」という言葉を聞き、次のように定義していました。

 自分軸
   ・自分らしさ
   ・ありたい姿

自分にとって大切なものは何か?
自分がなりたい姿は何か?
その問いから形成される「自分軸」を持ったスキルフルな人が、「人に影響を与えられる」のだと思います。
そのその人なりの軸から発せられる「マインド」とそれを支える、または具現化する「スキルフルなスキル」を持って初めてプロと言えるのではないでしょうか。

自分の成功を収めて「自立」した結果、初めて人に影響が与えられる。
これは『7つの習慣』でいう「インサイドアウト」の考え方です。

  私たちは自分の内側(思考)を変えなければ、行動を変えることができないし、外側に対する影響力を持つこともできないのです。

 

プロもそうあるべきです。

 

 

改めてProfessionalとは?

結論から言うと、まだProfessionalでありません。
言うならば、ここまでで「自称プロ」。 オレオレプロははっきり言って、現場では不要だし、邪魔です。

3) 環境に対応する

最後にプロとして必要なピース。それは「Contextへの対応」です。
人であったり、状況であったり、時と場合による対応、つまり、プロとしての一般解と相手を考慮した最適解の提示が「プロである」事だと思っています。
また『7つの習慣』から言葉を借りる事にします。

 理解してから理解される
  相互依存の関係をWin-Winの関係にするために、まずコミュニケーションが重要である。
  信頼を築き、相手が本音で話せるような人格の土台の上に、感情移入の傾聴のスキルを積み上げていかねばならない。
  大切なことは、まず自分の信頼性、そして感情移入、最後に合理的な説明なのだ。

プロとして何かの「スキル」を持っていると、どうしても押し付けがちです。
自分が何を持っている前に相手が何を欲しているのか?でないでしょうか。
その上で自分のスキルが完全にマッチするのか、それとも抽象的には一般論で提案出来るのか、何にしても相手あってのプロの存在です。

ある時にはプロであっても自分の無力さを感じることもあるでしょう。
その時、プロとしてどうするべきか、その対応策は十分語ったつもりです。


■最後に”真に”プロと呼ばれる為に

Viableであること。
only oneとも言えると思います。だからと言って突出する訳ではなく、あの有名グループの歌詞と絡めて表現すると、もともと特別なonly oneでしょうかw。

同じジャンルのプロを語っても、”人”それぞれ違います。時、環境、得てきた知識。ならば、違いが在る事を前提に考え抜く事こそがプロの仕事であると思います。
絶対な成功は無い。経験則からくるベストプラクティスがあるかもしれないが、それさえ絶対ではない。プロは仕事を簡単に見せるが、簡単な仕事はどこにも無い。ただ愚直に仕事にあたる姿勢がプロに求められるのでははでしょうか。

最後に、だから何がプロなんだよ? と言われたら、簡単な計測方法があります。
お客様にメンバーにこんな事言われたら、まずは合格じゃないですかね?

 「また○○さんと仕事をしたいです」
 「これは○○さんにお願いしたいです」

と「by name」である事。
利用されてるという事もあるけど、それさえ計算に入れて「Give & Given」な関係を築き、相手を助けられるそんな人に私はなりたい。
あ、最後は願望でしたねw

何かハードルを上げ続けた気がしますが、物事は全てSimpleです。
ここまで読んだ人は、
実際に、
自分の口から、
言葉で、
以下の一言を呟いて下さい。

「私はプロである」

それを宣言したら、次は何をすべきか自分自身、分かっているのでは無いでしょうか?

 

■まとめ

さぁて、長々とProfessional論を論じたので、皆さんにご迷惑をおかけしたかと思います。
要は、、、

 自分のやりたいようにやれば良いんですよ!

人生一度きりだし、他人はあなたの人生の責任を負えませんので。
また、人に言われてそのままやったらProfessionalじゃあないですよ。
あなたのProfessionalがあるはずです。
失敗したら別の方法を試せば良いんです。 学べたら次はより上手くできんじゃんね!

 

多くの人の考えに触れて、自分なりに考察する事が大切だと思ってますので、いろいろな人の意見を待っています。

ではでは。
アリーヴェデルチ