アル中プログラマの備忘録。もはやコーディングしてないけど。

酔いどれまさになう。プログラマとして就職し、システムエンジニア、プロジェクトマネージャーと立場を変えながら、システム開発に関わるとあるアル中の成長記録。

システム開発

アジャイルサムライ横浜道場参加記録

投稿日:2014年5月21日 更新日:

読書会

アジャイルサムライ横浜道場

説明は以下を参照してください。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinyokohama
https://yokohama-dojo.doorkeeper.jp/

たまに参加していた分の記録を残しておきます。

2013-03-19 横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」

ドメインと特定ドメイン

ドメイン:
×ネットワーク上の識別に使われているドメイン名
○単語そのものの意味である、領域、範囲、分野など

特定ドメイン:
メンバー共通(特定)の概念(ドメイン)(を使ってのコミニュケーション)

ワークショップ

上記をまどマギを使って体験するというものでした。

キャラクターの人気投票。何故かヒロインが不人気。
投票

仕事について自分が似てると思うキャラクタと理由をチームごとにまとめました。
まとめ

まとめ

まとめ

まとめ

小さくて見えませんが、KPTでふりかえりをして終わりです。
KPT

感想

実際に初対面の人が多かったですが、共通で知っている話題をもとにすると仕事の話もしやすかったです。
会社の後輩も連れて行きましたが、楽しんでくれたようでした。

問題があるとすれば、ドメインが暗黙知になっているため、それをいかに共有するかだと思います。
(共通の話題が思いつかないことも多いですし)


なお、この本に詳細が書かれているそうです。

2013-04-16 横浜道場 特別編「宝探しアジャイルゲーム」

ワークショップ

今回は「開発」と「ビジネス」でチームを組んでのゲームに「開発」として参加しました。 細かいルールは割愛しますが効率よくオセロで白を黒にしていきます。
オセロ

オセロの隣にある赤い物がバックログにつまれた物を表しています。うまく黒にできるとこれらを成果物として「ビジネス」に渡すことができます。(1スプリントに3つまでしか置けない)
「ビジネス」メンバは成果物を使って、市場を押さえにいきます。市場に成果物を投入すると、ユーザを獲得できます。
最終的にユーザ数と現金を多く持っていた方が勝ちです。

結果は以下の通りです。
ゲーム
わかりにくいですが、左側が勝っています。右側の方が現金が多いですが、ユーザ数で逆転が起きています。僕のいたチームは赤色の市場を攻めていました。

感想

アジャイルの勉強になるかはちょっと分かりませんでしたが、チームビルディングには良さそうでした。(「開発」と「ビジネス」が完全分業だと厳しく、お互いに話をしないとうまく回らない)

2013-08-27 横浜道場 特別編 「Challenge our Product Development’s Assumption Change! ~ adapt PDAC to PDCA ~」

(印象に残った部分に勝手に解釈加えて書いているため、本来の趣旨から外れてたり誤解があったらすみません)

プロジェクトを成功させるためのルールってあるのか?そもそもプロジェクト(ビジネス)における成功って何か?
成功についての回答は最終的にほぼ「黒字であること」にたどり着きます。
では、(少々つまらないですが)黒字であることという指標ってのがあるのにもかかわらず、最初にゴールやルールが話し合われないのはなぜなのでしょうか?

よく上がる理由は、「どこまで決めていいかわからない」や「当たり前だと思ってた」などです。
ですが、本当に当たり前なのでしょうか?誰(またはどのグループ)にとって当たり前なのでしょうか?例えば、人数・予算・期間はどうでしょうか?

最初から完璧である必要があるのでしょうか?また、決めたルールは変更できないのでしょうか?(変更するより守らなくなることのほうが多いのはなぜでしょうか?)
作業をお願いしても、誰もその作業がどうしたら成功かを聞きにこないのはなぜでしょう?
毎度、一生懸命プロジェクトの振り返りをしても、次で同じ事を繰り返すのはどうしてでしょうか?

などなど。常識だと思ってることは、自分(もしくは相手)が思ってるだけで、話してみると食い違いや発見があると思います。問題は、常識だと思っているので話題に上がらないことです。
「暗黙知の共有」につながると思うので掘り下げると面白そうです。
個人的にはプロジェクトに入るときには「これが完成すると誰がどういうふうに嬉しいの?」を聞くようにしていますが、あわせて「何がどうなったらこのプロジェクトは成功なの?」も聴くところから始めたいです。

以下はメモ書きなどです。
メモ

メモ

2013-11-05 横浜道場 特別編 「見せて貰おうか、KPTの性能とやらを・・・。」~KPTの基本と、その活用法~


普段、会社の振り返りでも使っているKPTですが、何だか微妙で、うまくやる方法があるのかと思い参加しました。
(Problemがいっぱいあり、Tryをだしてもなかなか実行できていません)

注意したほうがいいことで、すぐできそうなこと(そしていままで気にしてなかったこと)

Problemで「〜してない」というのは良くない

Problemが「○○してない」だとTryが単に「○○する」になってしまいます。
してないことの何が問題なのか、してないことでどう困っているのかがわからないのでよくありません。

Tryで「しっかり」とか「ちゃんと」というのは良くない

抽象的なため、どうやって良いかわからないし、できたかも判断しづらいためよくありません。
これは目標はSMARTであるべきというのと同じですね。
 Specific:どうすればいいかはっきりしてる
 Measurable:測れる
 Achievable:やれる
 Realistic(Result based):現実的、結果志向
 Timely(Time bound):期限が明確

ワークショップ

ペアドローというらしいです。2人1組で、一筆ずつ交互に絵を書いていきます。

ペアドロー
今回の対象は人物画です。
左から順に1回目〜3回目で、3回目はモデルが変わっています。

最初はどことなく安西先生を思わせるポッチャリさん(当然全く似てない)でしたが、2回目はそこそこ見れるものになりました。(絵心はありませんが)
最後は下手ですね。ごめんなさい。

一緒に写ってるのがKPTの表で、繰り返すうちにKeepに付箋が溜まった状態のものです。
うまく回ってるとこんなふうにKeepの部分にうまくやるためのナレッジが溜まることになります。

「〜してない」はそれの何が問題かをひとつ掘り下げるだけで、結構変わるようなので、今度KPTするときは気にしてやりたいです。

2013-11-26 横浜道場 特別編 「忘年会&LT大会」

酔った勢いでLTありで申し込んでしまったため、特に人前で話すようなことは無いですが、最近やってる読書会について話をしました。

初めてでしたので緊張しましたがいい機会でした。

2014-05-13 アジャイルサムライ横浜道場 「みんなをバスに乗せる」

今回は「インセプションデッキ」についての概要です。
内容について説明のあとテーマを決めて各テーブルで話し合いました。

僕達の話し合い結果は以下の通り。
インセプションデッキ

テーマは「インセプションデッキを導入する上での障害」ということで、見切り発車的に始まりました。(テーマをあれこれ悩む時間もなかったので)

色々意見は出ましたが、最終的に以下の3つに分類できるよねってことになりました。
・導入する前
 →同意が得られないとか、結局形だけで通らないとか
・作っている時
 →責任を負わされるとか、同コミュニケーションをとるかとか
・作った後
 →メンテナンス(見直しや修正)をどうするかとか

結局この場ではまとまった解決策までは出ませんでしたが、お互いいろいろ悩む点があるんだということがわかりました。
最後は他のグループがどういう話をしたかという発表を聞いて終わりです。

酔いどれまさになう。

-システム開発

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

入り口

Developers Summit 2012に参加してきました

Developers Summit 2012 名称:Developers Summit 2012 (デブサミ2012) 会期:2012年2月16日(木)・17日(金) 会場:目黒雅叙園(東京・目黒) …

セミナー

QCon Tokyo 2012に行って来ました

QCon Tokyo 2012 はじめて同時翻訳のレシーバ利用しました。 その場で訳されていてすごいと思いました。ある程度は台本があるのでしょうか? ラウンジではアジャイルマインドの同人誌が売っていた …

体系的に学ぶ安全なWebアプリケーションの作り方〜脆弱性が生まれる原理と対策の実践〜

体系的に学ぶ 安全なWebアプリケーションの作り方 Kindle版の方が安かったため、そちらを買いましたが、適宜参照しやすい紙の方を買ったほうが良かったです。 主なサンプルコードはPHPで書かれていま …

Review

設計レビューを効果的に行うには、目的を理解してそれに沿った方法で行おう

レビューあるある 長い 喧嘩してる、槍玉に上げられてる 脱線する 重箱の隅をつついていている 不具合を見つけたけど黙ってる などなど、結果として時間はかかる、気分も悪い、その割には後で不具合が見つかる …

Jenkins実践入門

Jenkins 執事さん!公式サイトの人で、 CI(Continuous Integration、継続的インテグレーション)のためのサーバー(ソフト、サービス)。 継続的に開発、ビルド、テスト、修正、 …

カテゴリー