nDiki : 開発

スポンサード リンク

2016年10月25日 (火)

第1回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まって勉強会をすることにしました。今日が第1回。毎週1章ずつ進めていく予定です。

事前に読んで興味を抱いた場所を意見交換するぐらいかなぁと勝手に思っていたのですが、当番の人がサマリやプラスαの考察・勉強会での議題などをまとめたスライドを用意してきていていてビビリました。輪講っぽい。

第1章では

「ワリコミ駆動の作業」「スクラムは、割り込みが多すぎる作業にもうまく合わない。」「割り込み駆動の環境では、カンバンと呼ばれるアジャイルアプローチを採用することを検討するとよい だろう。」「カンバンが適しているのは、ソフトウェアの保守とサポートの領域だ。」

「共存する別々のシステムの要求に対応するために、スクラムとカンバンをどちらも使うことができるかもしれない。」

と書かれているのが興味を抱いた箇所。

昨年度まではCS 開発チームとして割り込みを意識した開発プロセスで進めてきました。全部が割り込みではなく、主体的な開発もあったのでもしかしたらスクラムとハイブリッドでやってみるという選択肢もあったのかもしれないなと感じました。

来週当番です。

スポンサード リンク

[ 10月25日全て ]

2016年10月26日 (水)

ようやく日記システム DiKicker のメンテナンス開始

この日記(nDiki)で使っている自作日記システム DiKicker開発し始めたのが2003年12月末なのでもう13年物だったりします。ここ最近大きなメンテナンスはしていなかったのですが、まだこの先10年以上使えるように手を入れることにしました。一昨日から着手。

やりたいこと

  • もともと WiKicker (WikiEngine) からの派生で作ったのでが WiKiEngine の方は使わなくなったので、不要なコードを削除したい。共通部分をスーパークラス化してあるけれどもここもまとめたい。
  • WikiName の特別扱いをやめたい。
  • Perl 5.005_03 でも動くように Perl v5.8.0 未満かどうかで処理を変えているけれども、もう 5.005_03 用のコードは消したい。
  • データを Berkeley DB にトリッキーな形で入れているので SQLite あたりに変えて簡単にしたい。
  • 最終的には Go で書き換えたりして。

[ 10月26日全て ]

2016年11月8日 (火)

第3回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。

原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。

イテレーティブとインクリメンタルの話のところでは

スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。

とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。

「3.3 予見と適応」では

コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。

アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。

WIP にまつわる話

作業者の手持ちではなく、作業の手持ちに注目せよ

は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。

「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。

勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。


[ 11月8日全て ]

2016年11月9日 (水)

チームでインパクトマッピングしてみた

次にどのようなサービス開発をしようか(ユーザーにどのような価値を提供しようか)というアイデア出しをするのに「インパクトマッピングというのがあるよ」と教えてもらったのでチームで昨日やってみました。

ゴール (WHY) を中心に以下の階層でツリー(インパクトマップ)を描いて考えるというものです。

  1. ゴール (WHY)
  2. アクター (WHO)
  3. インパクト (HOW)
  4. 成果物 (WHAT)

個人では「ミッション → ビジョン → ゴール → (ここでいう)インパクト → (ここでいう)成果物」のように広げていくことはあるのですが、 WHO はツリーに入れたり入れなかったりするのでなるほどなと思いました。

昨日はすでにメンバの頭の中にあったアイデア(ここでいう成果物)を、このツリーに入れていくという整理の側面が強かった感じですが、それはそれで良かったかなと。みんなで同時にやると WHO・HOW の分類が違って見通しが悪いのでそこは別途誰かまとめる人が必要だなとも感じました。


今日のさえずり: そういえばまだTodoistプレミアムだった

2016年11月09日

  • 21:00 Emacs は止まらない。 / “MacのTouch BarをサポートしたEmacs開発が進行中。 | AAPL Ch.” http://bit.ly/2fAJ0jJ
  • 21:19 todo.txt にデイリーとウイークリーのルーチンワークを繰り返しタスクとして入れると厳しい感じになることがわかった。
  • 22:12 そういえばまだTodoistプレミアムだった。

[ 11月9日全て ]

2016年11月14日 (月)

ミッション・ビジョンをもってサービスを作り CS 活動をしていく【日記】

ネットサービスCS グループマネージャーの方とディレクターの方と食事してきました。歩高里(ブルゴーニュ)は六本木交差点からすぐそばなのに、広くて空いていて安くて美味しかったので満足でした。

私の方は「最近はサービス開発CS 開発の両方を担当するグループにいて、CS 開発チームがサービスと独立してリソースが確保でき、CS の価値観や KGI・KPI で動く良さを別の視点であらためて感じている」という話をしました。CS 開発という地位については相手の方に「サービス開発から CS への異動だと第一線から外れるような劣等感をもたれる事もある」と言われて、ああそうだよねとなりました。私のまわりだと誇りをもってやっている人が多かったので最近そういう風にとらえていませんでした。

相手の方のサービスの話などもいろいろ聞かせていただきました。相手のお2人とも、そしてその上の経営陣の方もきちんと大きなミッション・ビジョンをもって動いているのが強く感じられました。素晴らしいなと。あとちゃんと dogfooding しているなと。

それから本質的に意味のある仕事かどうかを見極めるのをとても大切にしているように感じました。

我々もあらためて自分たちのミッション・ビジョンに向けて邁進しなくてはと思って帰路についた1日でした。


[ 11月14日全て ]

2016年11月25日 (金)

mixi の価値を一言で発表せよ!」(1日目)

naney:30895708000

今日から2日間の日程で、「サービス企画開発」と「CS 開発」担当するリレーションシップグループ初の合宿「第1回RSG合宿」です。場所は「ホテルコンチネンタル府中」。府中での合宿は去年の企画開発合宿(1日目2日目)ぶりです。

mixi の価値を一言で発表せよ!

共通の課題について集中的に議論することで価値観を共有し相互理解を深める。

を目的とした今回の合宿のテーマは

mixi の価値を一言で発表せよ!

です。あらかじめ準備しないようにテーマは当日まで秘密で、私も今日知らされました。 10:00 スタートで今日の説明があったあと3チームに分かれてさっそく議論開始。まず最初に決めるチーム名は「チーム魚旨」としました。やっぱ鮨いいですよね。

アイデア出しとディスカッションは私たちのチームは Trello を活用。みんなで同時にカードを追加したりコメントをつけて行きながら議論を進めていきました。

13:00 になったところでお昼休憩。肉と魚のダブルでパワーを補充しました。

会議室に戻ってからさらに議論を続け、夕方にいったん中間発表。機能別に検討したり2軸にマッピングしてポジションを考えたりなど各チーム毎に議論の進め方に違いが出ました。しかしながらどのチームも議論の向かっている方向は大きく異なっていないなと感じました。常日頃からサービスに向き合って考えているのでブレなく議論できているのかなと。

1日目の議論を終えたあとは夕食。そのあとは自由時間ですが、合宿企画担当の皆さんが懇親として希望者向けに謎解きゲームの準備をしてくれました。

ヒントをもらいつつ昼間とは違う頭を駆使して SCRAP 謹製の難題に挑みました。制限時間も残すところ3分のところで、ついにナンバーロックの番号に辿り着き見事クリア。

諦めずに頑張って良かったー。良い気分で自室に戻りました。諦めないことが大切だと勝手にプチ学びを得ました。

明日も朝から引き続き議論を行い、夕方には最終発表予定です。

2日目に続く

naney:31227258806


[ 11月25日全て ]

2016年11月29日 (火)

第6回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会6回目。今日は第6章 プロダクトバックログ。

プロダクトバックログは、優先順位の高いものほど詳細度を上げて分割していく一方で優先度の低いものはざっくりとで良いというのがポイント。現実的で良いなと思います。2回から3回分程度のストーリーを準備完了状態で抱えておくのが経験的に良いとのことでした。

一方プロダクトバックログはリストなのでこの分解ツリーが見える化されていません。このあたりがちょっと扱いにくいなと感じることはあります。アウトライナーのような形でツリーで整理しつつ、その中でプロダクトバックログアイテムとなるところのみビューとして抽出して順序付けるものがあるといいのになと思うことはあります。

グルーミング(プロダクトバックログリファインメント)については

プロダクトバックログのグルーミングは、プロダクトオーナー主導で行う共同作業だ。

と書かれていてこれは「おっと」と感じたました。関係者でのグルーミングはおざなりにしていたなと。ここは PO の責任範囲だとあらためて把握。なおグルーミングはいつ行ってもいいとありました。

開発チームは、各スプリントの作業時間の最大1割程度までをグルーミング用に確保すべきだ。

とあり結構たっぷりだよなと思うわけですが、考えてみるといわゆるウォーターフォール開発でも初期の工程に時間をかけているわけですし、特別多い割合でも無いのかなと。

複数チームでプロダクトバックログをどうするかについては、1つのプロダクトバックログからビューでチーム別のプロダクトバックログを用意するのが良いとありました。理想的には確かにそうだと思いますが、そこまでやるとすると結構ヘビー級のツールが必要になって気がしてそちらの学習・運用コストが馬鹿にならないのではという印象を受けました。

何事もできるだけシンプルにしていきたいですね。


[ 11月29日全て ]

2016年12月13日 (火)

第8回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • プリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント

「技術的負債返済スプリント」だとか「リファクタリングプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。


[ 12月13日全て ]

2016年12月20日 (火)

第9回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会9回目。今日は第9章 プロダクトオーナー。

自分がプロダクトオーナーをしていることもあり発表担当をしました。

受け入れ条件の定義と検証

受け入れ条件が満たされていることを確認することがプロダクトオーナーの主な責任の1つにあげられています。これはスプリントレビューで行うのかなと勘違いしていたのですが、プロダクトオーナーによる受け入れ条件の検証はスプリントレビューまで待たずにスプリント実施のときに行うとあり、ここは学びになりました。スプリントレビューでデモが許されているのは完成した機能だけとのことです。

ただ CSM によるとプロダクトオーナーが忙しくスプリントレビューのタイミングになっているところも多いらしいです。

誰がプロダクトオーナーになるべきか

ネットサービス開発は商用開発にあたるので「顧客の声を代弁する社員(プロダクトマネージャーなど)がなる」に相当しますね。

その他の役割と組み合わせ

プロダクトオーナーとスクラムマスターを兼任するのはよくないという点については、それぞれ違う行動指針で動くものだからと CSM がいっていました。確かに。

プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。

プロダクトオーナーチーム

チーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。

プロダクトオーナー? プロダクトマネージャー?

勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。

勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。 CSM は(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。なるほど。


[ 12月20日全て ]

2017年1月6日 (金)

Android スマートフォンで Dropbox 上に記事原稿を書くなら iA Writer

image:/nDiki/2017/01/06/home-banner.svg

Android デバイスから Dropbox 上のプレーンテキストファイル/Markdown ファイルを直接編集するライティングアプリとして現時点では iA Writer が最高です。

スマートフォンでちょっとした時間に使うライティングアプリとしては

  • 勝手に Dropbox 上に自動保存してくれる。
  • 他のアプリから Dropbox 上にあるファイルが変更された時に自動再読み込みしてくれる。

という機能が個人的には必須だと思っています。 iA Writer はこのあたりの Dropbox 処理が良く(安定した読み書き・自動保存・他で更新した時の自動再読み込み)、ストレス無く使えます。

Jota+ や JotterPad も併用してきているのですが

  • Jota+ Connector for Dropbox V2 が自分の環境だと良く保存に失敗する(手動保存・自動保存)。
  • JotterPadDropbox 上で変更されても自動再読み込みしてくれない。明示的に再読み込みする方法もない。

という点で現時点では iA Writer がベストかなと。

Mac アプリケーションiOS アプリとしてはメジャーな iA Writer ですが、 Android 版はビジネス的に儲からないのか開発が活発ではないようなところが心配な点ではあります。ぜひユーザーが増えて発展していって欲しいところです。

(画像https://ia.net/writer より)


[ Android アプリレビュー ]


[ 1月6日全て ]

Related term

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS の企画開発を行うグループのマネージャーをしています。CS 向上・コミュニティマネジメント・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス

Process Time: 0.123634s / load averages: 0.44, 0.56, 0.52
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker