この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

エクストリームの純度

アジャイルでもそうですが、ドキュメントを書かないことの言い訳に使われることがありますね。でもそれ以前にコミュニケーションの問題があるかもしれませんし、様々なスナップショットを大量に生産したところで時間のロスばかりであまり役に立つものではない。頑張ったことの証拠としてカサ増しにはなるかもしれませんが、それよりは成果物の品質や価値を高める方が大切。その上で必要とされるドキュメントがあれば用意するのは当然。

と言いつつ、このAgile459の中でも打ち合わせのために事前にドキュメントを用意したりしていますが、それも個人が思うままにかなりの時間を割いて作ったりしているので、そのあたり、せっかくXPとか学んでいるわりに実践が伴っていなかったり、コミュニケーションが足りなかったりしています。コミュニティの運営にもこの学びを活かさないといけませんね。

オフショア開発

オフショアには権限の不均衡が伴う

とあるように、身の回りで聞くオフショアとかニアショアの案件はコストの話にしかなっていなくて、本に書かれているようなコミュニケーションとかリスペクト、単一のコードベースとは異質なもののような気がします。そうではなくて、マルチサイト（拠点の違い）をどう活かすか。メリットとしては例えば多様性と時差でしょうか。ライフスタイルの違い、物事の捉え方の違いを開発や成果物に活かす。あるいは時差を活用してうまく連携することでまさにエクストリームな開発を進めるなど。

結論

最近、働き方が問われていますが、まさにこのXPの原則そしてプラクティスがこれからの働き方に役立つと思います。

今回、ふと思いついてAdvent calendarで勢いでXP本読書会をふりかえってみましたが、読み返すたびにあらたな気づきがあります。すぐに忘れているということもありますが、また折をみてXP本をふりかえってみたいと思います。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

XP本読書会15回目と16回目からいくつかピックアップ。

ロゼッタストーン

プロジェクトが停止する前に、ビルドやテスト、システムを理解するためのガイドのようなものを書いておく。まぁ、停止する前というのもいつかわからないので、プロジェクト開始に合わせて準備して、随時更新しておくのが良さそう。

解決策の複雑さ

Agile459のコミュニティの中で「リファクタリング」が話題にあがることがわりとあります。なかなか日常の仕事の中でリファクタリングに時間をかけるのが難しいとか、その成果を説明するのが難しいとか。あるいは、一旦リリースしたものについて、具体的な予算のないところで手間（工数）をかけることができないとか。ですが、そういった気がかりがあるなら実践して前に進んだ方が良いですし、経費なのか投資なのかという判断が必要ならそういう協力者を見つけておく（15章）のが良さそうです。

継続的にデリバリーする中で、少しずつ複雑さを削り取っていく

と考えると、間違いなくメンテナンス性とか開発効率につながるわけで、変更に柔軟に対応できると考えればオープンにしてアピールすべき点とも思います。逆に、リファクタリングをしないで、複雑な状態のまま変更が求められるとなると、負担が増すばかりで、変更に対しても言い訳が先に立ってしまうような気がします。取引先も含めてお互いに気持ちよく仕事を進めるには大切な要素と思います。

また、次のセクションに出てくるトレーサビリティを考えると、こまめにリリースしておくことで、仮に大きな問題が見つかっても対応しやすいですね。これが長期間にわたってしまうと、何をどこまで戻すとか、その場合の影響範囲とか、考えるだけでもストレスになりそうです。

インタビュー

ペアプログラミングであり、チーム開発なのでそれができないとなるとXPの導入は難しいということ。それと、一部見過ごしていたのですが、見積もり当初は要件を隠しておいて、後からすべてのフィーチャーを要求される、というリスクもあるんですね。ここはやはり顧客との信頼関係ができていないと難しいですね。

全員が品質に責任を持つ

何か問題があると、伝言ゲームのように芋づる式に個人の責任が問われて対応するのが当たり前のような場面が多かったような気がします。それだとリスク管理ができていないわけで、やはりチームでコードを共有してテストも自動化することが大切。チーム全員で責任を共有して、自信を持ってプロダクトをリリース。チーム内のモチベーションにもつながります。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

この回のログを読んで気になった部分をピックアップ。

時間の重要性

ソフトウェアはレバレッジゲームだ

Wikipediaによると、レバレッジの言葉は「てこ(lever)」が由来なんですね。テコの原理か。なるほど。
だけどわりとそうなっていないケースが多いのが残念だなぁと思いました。というのは、毎回引き合いがあるたびに1から開発して納めて、しばらくして似たような案件があっても、また最初から作り直しているような。まぁ作り直すのは良いとしても、そこから横に展開するというか、汎用的にしてみるとか、可能性はありそうだけど、努力が足りないのか、営業力？、具体的なニーズの把握？もしかすると、安易に取りかかってしまうのが問題かもしれません。その先にどうありたいか、とかの見通しなど。

XPの戦略は「常に設計する」

この考え方が大切と思いました。要件を確認して詳細まで設計しても、そこから実装を進めていくうちに設計の問題が見えてきたり、要件も変わってきたりするので、それが判明した時点で設計の見直しが常に行えるようにする。となると、ドキュメントがボトルネックになったりするので、最低限必要なものにするとか、オンラインで共有して更新可能にしておくとか、テストコードで仕様がある程度表現されていれば、テストコードのメンテナンスで対応できる部分もあったりとか。長期に渡ったり、規模が大きかったりすると、どうしてもあれこれドキュメントを増やしてしまったりしますが、成果物の品質がよくて、説明しなくても使えるようなものになっていれば、それほどドキュメントに頼ることもないのかなぁと。何というか、ドキュメントを作ることは本来の目的ではないですよね。例えば、管理のために必要、と言われれば、では何のために管理をするのでしょう。管理すること自体がボトルネックになっていて、生産性や品質を下げる要因かもしれません。それよりは、常に設計できる環境にすることで、生産性がグッと向上して品質も上がれば、それこそさっきのレバレッジゲームに乗れる状況が作り出せるかもしれません。

こうした設計の改善が共通してたどり着く先が、パターン

重複は悪、パターン

と言われても、なかなか重複が取りきれなかったり。このあたり、チーム内でノウハウがあって、スマートに対応できれば良いのですが、場合によってはノウハウがあまりなかったり、学ぶ機会が少なかったり、ということもあると思います。例えばコミュニティで相談してみて勉強会、という可能性もあるかもしれません。先日開催したGDCRの中で、オブジェクト指向設計についての解説があったのですが、それを理解するまでの余裕がなかったのが残念。このようにふりかえってみると、あれもこれもまだまだ学ぶことが山積みです。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

スコープの管理

ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。

数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。

すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。

いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。

テスト：早めに、こまめに、自動化

あとでまとめてテストしようとすると、テスト自体にとてもコストがかかるのと、どうしても欠陥が残ってしまうということ。さらに欠陥を取り除こうとしてもコストが増えるばかり。逆に、こまめにテストを実施していれば、欠陥も起こりにくいしそれほどコストもかからない。あと、プログラマー目線でのテストと、顧客目線でのテストによるダブルチェックが重要というお話。ダブルチェックといっても、テストの工程を分けるんじゃなくて、まとめてテストできるように自動化が必要、という感じでしょうか。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

この当時、Kindleは買ったもののどうも慣れなくて、まだあまり本が読めていない頃でした。ですが、この回の後半にある制約理論の部分で「ザ・ゴール」という本を知り、それをきっかけにKindleで本を読むようになりました。Kindleだと本の厚さを気にすることがないのでそれですんなりと読めた気がします。今もあれこれ読んでいます。といってもまだ10冊くらいですが…

あと、読書会の進み具合をD3jsでグラフ化したりしていました。読書会の中での会話とか感想を話す際に、ちょっとルーズになってしまうこともあって、せっかく時間を決めて参加しているのに、なかなか先に進まない状況もあって、目標（その日に読むページ数）を決めて、その結果（読んだページ数）を記録していくことになっていました。ただ、ページ数を記録するだけでは様子がわかりにくいので、グラフ化(burn down chart)した次第です。
XP reading circle burndown chart
CSV形式で日付とページ数を書いて、git pushするとグラフが更新できます。今考えると、読書会Wikiに書いたページ数をスクレイピングすればもう一段階自動化できるかも？と思ったり。あるいはWikiから読み取るのはあまりきれいに書けそうにないので、ページ数の記録は別にして、逆にページ数とグラフをWikiに表示する方が良いかも。

さて、この回の「XPチーム全体」について。

ここで解説されているそれぞれの役割ですが、これまで関わった仕事ではこのような役割を意識したことはなかったと思います。なので、良い方向に捉えれば、チームのメンバーでそれぞれの役割を意識することで、仕事の仕方に変化が生まれていろいろと改善に向かうように思います。（かなり適当…

例えば、一気にすべての役割を決めるんじゃなくて、一つの役割を決めてそのように振る舞ってみて、そこから派生していくとうまくいくのかも。まぁ、ともかくすべての役割をやらないといけない、ということではなくて、現状の問題点を洗い出して、その解決に繋がりそうな役割を立ててみる、という感じでしょうか。

そして制約理論。

ここの議論で「制約理論」が気になって、いきおいで「ザ・ゴール」と「クリティカルチェーン」を読みました。で、ボトルネックを見つけて解消して、そうすると別のところがボトルネックになって、というような話で、じゃあ例えば開発チームの中にボトルネックがあって、と言ってしまうと角が立つので…という話もあったり。スループットをあげるにはボトルネックの解消が必要というのは良いのですが、読書会の当時はそれで理解していたものの、例えば加工や部品を外部委託する場合など、もちろんコストパフォーマンスが求められるのはわかりますが、単にプレッシャーというとちょっと違うのかなぁとも思います。労働環境があらためて問われる時代になっていますし、なるべくフラットな形で良い協力関係が構築できれば良いですかね。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

この回は第10章でした。XPチームの役割についていくつかピックアップ。

テスター

従来の後工程のユニットテストや結合テストではなくて、テストファーストで始めるための「要素の定義や仕様化」を支援。今年7月に高松で開催したTDDBCでも習ったように、テストコードのファンクション名で要件を表現すると思えばイメージがつかみやすいですかね。

インタラクションデザイナー

自分のまわりではこの役割が弱いというか欠けている感じがしました。
「顧客と一緒に働いて、ストーリーの記述や明確化を支援」
デザイナーさんに任せてしまうのではなくて、インタラクションを意識したデザイナーとプログラマーの間の意識合わせというか作り込みが大切と思いました。

経営幹部

振り返ってみると、経営幹部って進捗状況を見て、遅れていたら急がせるだけだったり追加の資料を求めるなど、管理しようとすればするほど足を引っ張っているような気がします。でも、ここに書いているのはそうではなくて、環境を整えたりともにゴールを目指したりチームの功績をアピールしたりと、ちょっと役割が違うみたいです。もちろん後者の方がチームとしてモチベーション高く仕事できますよね。敵対するんじゃなくて、お互いの得意なことを活かして相乗効果につなげたいですね。

役割

チームとして成長していくには変化が必要で、そのためには誰でも提案できる土壌が必要。また、提案するばかりで行動が伴わないと信用してもらえないわけで、チームとして行動を起こして変化していくことが大切。風通しの良いチーム。お互いをリスペクト。

今日はこのへんで。

そういえば、今日 ehimerb の勉強会に参加したのですが、その中で ehimerb と agile459 のコラボで何かイベントしませんか、というお話がありました。何がいいですかね…

年明けの勉強会の予習というかメモ書き。
クロコラボ #20 headタグの中を考えてみよう
少しずつ書き足していきます。

文書メタデータ（ヘッダー）要素
文書レベルメタデータ要素
Qiita:色々あるHTMLのmetaタグなど一覧

JavaScriptはhead内で読み込みたい
結論としてはhead内で良さそう。

Document metadata – HTML 5.2
W3C Recommendation, 14 December 2017

headタグの短い例

headタグの長い例

文書レベルメタデータ要素

エンコーディングを宣言する

要素は 要素の内部かつ
HTML の始めから 1024 バイト以内に配置しなければなりません。
これは、ページの文字集合を選択するまでに始めの部分しか確認しないブラウザーがあるためです。

Document.title – タイトル

What’s in the head? Metadata in HTML

https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML

タイトル

<title>Page title</title>

Document’s character encoding

<meta charset="utf-8">

charsetをISO-8859-1に変えて文字化けを確認してみる。

Adding an author and description

<meta name="author" content="name here...">
<meta name="description" content="description here...">

Googleで MDN Web Docs を検索してみる。
descriptionの内容やtitleが検索結果に利用されていることを確認。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

単一のコードベース

読書会のときは、以前に手掛けたAndroidのカメラアプリが頭の中にあって、機種依存で苦労したことを考えていたのですが、今思えば他の仕事（ウェブサイト）でも派生させてそのままになっているコードも存在していて、このあたり一つに集約する努力が足りていないなぁとあらためて反省。

今、この記事を書きながら考えているのですが、共通部分を派生させて使いまわすのではなくて、共通部分を完全に分離して、汎用的に使えるように作り込めば良いはず。今、すでに複数のプラグインでメンテナンスが必要になっている部分を切り出して汎用化する方向で検討してみます。

交渉によるスコープ契約

新規案件だと、過去の習慣もあってひとかたまりで見積もってしまいがち。部分的にリリースして、その状況で次のステップに進めるように、契約を分けておくと良さそうです。一つ一つの機能の価値を確認しながら進めていく感じですかね。

（余談）読書会とは別の Code Kata について

先月、GDCRを松山で実施したことがきっかけとなって、この1月ほど Codewars で Kata の練習をしています。（参考：最近の勉強ツールあれこれ）

レベルはまだ 6kyu で、問題も 7kyu の Fundamentals を中心に練習しているのですが、問題によっては解いているうちにプロパティやメソッド、変数の状態など強制的に使わされる感じのものがあったり、あるいは問題を解くと、他の人のコード例も見えるので、そこで自分のコードの拙さに愕然としたりという状況ですが、まぁとにかくとても良いトレーニングになっています。

日常の仕事の中だとスキルアップに時間を費やすのはなかなか難しいかもしれません。ですが、適切なコードを書けるかどうかで効率とか品質は全然違ってくると思います。そのためには日常のトレーニングが重要。あまり難しい問題だと、続かないかもしれないので、比較的簡単な問題を様々な言語で引き続き進めてみようと思います。

明日の勉強会の準備。メモ書き程度です。

1.5.1 Herokuのセットアップ
このあたりの作業中。

ndenvのnpmをインストール済みなので、

$ npm install -g heroku-cli

を試したところ、npm WARN ... 'heroku-cli' has been renamed 'heroku' と表示されたもののインストールはできた様子。
それと、cross-spawn no longer requires a build toolchain, use it instead という警告もあり。

cross-spawn-async
cross-spawn

$ heroku --version
heroku/7.19.3 darwin-x64 node-v8.11.2


$ heroku login
ブラウザが開くのでログインします。

SSHキーを作成して登録。

$ ssh-keygen -t rsa -C "your.name@example.com" -f ~/.ssh/id_rsa_heroku
$ heroku keys:add

$heroku create
ブラウザで確認

herokuにデプロイ

$ git push heroku master

pushでrejected
SQLite on Heroku

ローカルのGemfileを編集したものの、コミットするのを忘れていました。(^^;

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

インクリメンタルなデプロイ

ここでは失敗事例が結構なまなましく語られていて、とても強い気持ちが感じられるセクションです。規模の大きなシステムで長期間にわたって開発が続く場合、期日にまとめてリリースしようとしてたいていの場合失敗する。しかも、数ヶ月とか1年が過ぎると、そもそもの要望が大幅に変わって来たり。スケジュールが大幅に遅れて、かなり無理をして新たなシステムに移行したものの、個々の機能にあれこれ問題が発覚して、そのような状況で大幅な変更とか、まぁ対応できるわけがありません。ですが、なんだかよく聞くようなストーリーです。

直前の「本物の顧客参加」にもつながりますが、部分的にでも使える状態にして、実際に使ってもらって、そのフィードバックをもとに次の機能を進めていく。その積み重ね。問題があれば、速やかに対応。日数が経過してからだと、対応にも時間がかかったりしますが、そうでなければ対応も比較的楽ですよね。そうして、ちゃんと機能するものが積み上がっていって、しかもこまめにフィードバックも得ているので、あるタイミングで大幅な変更で混乱、という事態にもなりにくいと思います。あるいは、多少大きめの変更が発生するとしても、それまでの実績があるので、その時点での変更コストが見通しやすい。

チームの継続とか縮小とか

チームを継続しながら適度なローテーション、てどうでしょう。意図してローテーションというのはあまりされていないような気もします。おそらくですが、個人のスキルに依存するばかりで、チームとしてのパフォーマンスに対する意識が低いのではないかと。対象とする分野とか業種によって、それぞれ要求されるスキルとかノウハウが異なるとは思いますが、それを固定化することがチームとか組織としてはたして良いのかどうか。例えば、ある分野で培ったノウハウを別のチームに持ち込んでみると、そこで新たな気づきにつながって、組織全体としてパフォーマンスが上がる可能性もあると思います。

コードの共有

個人の責任で追い詰めたところで何も解決しないどころか、時間のロスやモチベーション低下につながりますよね。チームでコードを共有して、チームで責任を持つと思えば、自然と個々のコードの品質も上がって、チームとしての評価も上がるはず。

といった感じで今日はこの辺で終わりにします。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

メトリクスが気づきにつながることもある

読書会のときに「数値化できていないなぁ」と書いておきながら、今、この記事を書きながら実践できていない（放置状態）ことに気がつきました。何か方法を考えないと…

Git Webフック
このあたりを活用してみるか…
といいつつ、何もないところからスマートに行こうとして、結局何も進まないことになりそうなので、コミット履歴をもとにして、数値化できるものを手で拾うところから始めてみます。

さて、プラクティスのマッピングについて。

なるほど、気になるキーワードを書き出して、絵にしてみれば良いんですね。読書会の当時は、あまりピンときていなかったのですが、今になって腹落ちした感じです。普段だと、キーワードとか何か言葉なり文章なりを書くとしたら、こういうブログ記事でもそうですが、エディタとかで整然と書くだけで、それでは変化がなくて発見につながらない。そうではなくて、紙の上に向きや形を変えながらキーワードの関係を手で描いてみる。それを共有することでさらなる発見につながる。という感じですかね。

ところで、この一連の読書会のふりかえりをしていて思ったのですが、一度読むとなかなか自分では解釈を変えられない、というか、思い込みのまま読み過ごしてしまうことが多い、ということです。せっかく良いことが書いてあっても、勘違いしたままで、後で読み直しても、最初の解釈のままだったり。あるいは、なかなか頭に入ってこないセクションがあったとして、やはり後で読み直しても同じ感じで、そのままやり過ごしてしまうとか。もちろん自分の読解力の問題もあると思いますが、でもこういう読書会であれば「自分はこう思うんだけど…？」と投げかけてみることで違う解釈が聞けたりすると学びになりますよね。

あと、最近気になるのはアジャイルが △△ vs ○○ という構図で表現されることが多くて、アジャイル手法だと □□ だから注意しないといけない、というコメントなど。XPとかアジャイルとかの本で書かれているのは、過去の様々なプロジェクトでいろいろ問題があって、どこも同じような問題を抱えていて、それをどうやって改善してきたか、どうすればみんなが少しでも幸せになれるか、というノウハウの集大成のようなものだと思っています。もちろん、こうすれば必ずうまくいくということではなくて、状況に応じて何を適用するかという判断も必要と思います。ですが、アジャイルを否定するためのあら探しをしたところであまり生産には結びつかないと思います。もちろん、何か問題点に気がつけば対策を考えるなり改善していけば良いわけで。

それと、自分の組織やチームの中だけでは気がつかないことも多く、こういうコミュニティの中でディスカッションすることで、いろいろと気づきや改善、プラクティスにつながったりするんだと思います。

自分に言い聞かせるような感じで、なんども同じことを書いている気がしますが、ご容赦のほど。

今日はこのへんにしておきます。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

この時期にSlackでコミュニケーション取り過ぎの問題があって、今思えば自分の使い方も良くなかったと反省。どちらかというとプライベート寄りのチーム、仕事用のチーム、その中間的なチームに参加していて、通知を受けたり書き込んだりする時間帯の切り替えができていなかった感じです。
今でも切り替えができていないので、通知とかステータスの設定を見直してみます。

Slack 通知の仕組み
おやすみモードによる通知の一時停止

さて、まずはペアプロについて。

Agile459ではこれまでにGDCRを3回開催していて、昨年のAgile Japanサテライトではモブプログラミング、そして今年の夏にはTDDBCも開催しましたので、ペアプロの有効性についてはコミュニティの中で共通認識が持てていると思います。ただし「ペアとパーソナルスペース」に書かれているような気配りについてはこれまで意識が低かったと反省。

例えば、Wikiのまとめにも書きましたが、以前使っていたアウトドア用の腕時計。そのバンドの裏側に着け心地を良くするための皮が貼ってあり、どうやらその部分が汗臭くなっていたみたいで臭いを指摘されたことがありました。指摘されたときは分からなくて、その腕時計が故障して買い換えた時に、「あーもしかしたら腕時計のバンドの臭いで迷惑を掛けていたかも」と反省。

自分では気がつかないこともあるので、ペアで作業する際の注意点などチーム内で話し合う機会が適宜必要と思いました。

次に、ゆとり（Slack）

最近、働き方が変わってきているようで、その中で、この「ゆとり（Slack）」の考え方が重要かもしれません。

重要度の低いタスクを含めること

とありますが、これは調整のために外す（対応しない）こともできるし、比較的簡単なものでも実現することで評価につながることもあります。臨機応変に対応するためのタスク。

それと、毎日の仕事の中で集中というか効率よく仕事ができる時間は実際には割と短いものだと思います。タスクを詰め込み過ぎず、ゆとりを持って、それ以外の環境であるとか、スキルアップのための学びであるとか、そういう時間も日々確保することで、より質の高い仕事につながっていくと思います。

そして、インクリメンタルな設計。

新規に取り組んだものは、その時点で要件を満たすことができた試作レベルと割り切って、機能追加とか何らかの改修をする際に、気がついた時点でリファクタリングを進めていくことでより良いものに仕上がっていくと思います。もちろん、リファクタリングを進めるにはテストコードによる動作保証が前提になります。言い換えれば、テストコードによってシステム全体の動作確認が取れる状態になっていれば、いつでも気軽にリファクタリングに取り組むことができます。

という感じで、今日はこのあたりまで。