スマートフォン用の表示で見るカイゼンにっき。twitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。この広告は、90日以上更新していないブログに表示しています。~」に参加して〜こちらに参加しました。Doorkeeperプロジェクトを円滑に進めることを、かなり高い視点から考える機会になりました。江端さん、皆様ありがとうございます!以下に私なりの解釈をまとめます。聞いた話と若干違う気も。人が陥りやすい罠と闘う「プロジェクトの成否ってのはなァ・・・仕組み次第なンだよ」スクラムは人が陥りやすい「罠」の解決を目指すフレームワークとも言える。スクラムを選択しない場合も、下記の罠と闘う仕組みを考えよう。他にも罠はたくさんあるので、日々の中で見つけていこう。◇考えを知り合おう!自分と相手の「当たり前」は違う。考えの違いを知ることは成長の鍵だ。自分と相手の考えをどう知り合えばよいのか?人は、「相手に確認してみる」ことをしない傾向がある。劇的な改善が得られるかも。「常識」は中々再考しないもの。◇改善をしていこう!改善の重要性は誰でも知っている。日々の雑務(改善以外の行動)に忙殺されがち。我々にとっての成功とは何だろうプロジェクトの成功とは何か?一緒に考えよう。黒字化?納期内にシステム完成?顧客の要求を満足すること?それとも、メンバーが楽しむこと?成長すること?そしてその中で、本当に大切なものはどれ?*1ルールというベースラインルールはプロジェクトの成功に必要か?答えはYes。ルールはベースラインになる。適切なルールは、柔軟に改善していくために必要。働き方のルールは、話し合われることは少ないが、プロジェクトの最初に決めるべき。働き方を話合うベースラインになる。プロジェクトの成功の定義を満たすため、人が陥りがちな罠の解決するために、ルールを考えよう。Change!*1:1か0かで言えるものでないので、トレードオフスライダーとか便利ですね。読んで〜共通部門に在籍しているものの、何をやれば価値を提供できるだろう、と思考の迷路にいる私が、「独創はひらめかない」を読んで琴線に触れた点の一部をまとめてみる。以下は、一番心に残った部分の引用。そのアイデアを同僚やスポンサーに説明する場面を想像する。皆が「すごいこと、考えたなあ」と驚いた顔をする。その場面が鮮やかに思い浮かんだら、いいアイデアだ。「説明しても、あまり納得する人はいないだろうな」と思うときは、あまりいいアイデアではない。見直せて、やる気も出て、よい本だと思います。見る素人発想ごく身近にある問題に対して、純粋にこうあってほしい、という思いをスタート地点にする。アイデアは出やすくなるし、具体的な目標があるので、「研究が有用な場面を探し求める」必要もない。本質的部分を除いて「省略」する。価値がある研究は、価値ある部分問題を解決する、ちょうど十分な研究である。本質理解の試金石として、論文のメッセージを1つに絞り込めているか確認する。現在の部分問題をちょうど示す、よい例題を作れるとよい。やりきってみる周りの目を気にせず、楽天的にやりたいことをやってみる。ためらわずにやりきることで、「何が困難か」わかるようになる。arclampにインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。制作(および詳細設計・結合テスト)フェーズの全体スケジュールを見通しやすい確かに、全体スケジュールの完全なコミットメントは不可能です。少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作(および詳細設計・結合テスト)フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。ウォーターフォールにはフェーズゲートがあります。想定よりも制作が難しいようであれば、単に制作フェーズに進まなければよいだけです。2個実装」したりすればよいはずです。アジャイルな開発では、実際に数イテレーション回した結果としてのベロシティと、リリースまでに実現したいストーリーポイントの総計を元に、全体スケジュールを立てる形かと思われます。ベロシティは所詮「まだ作っていないフィーチャ」とは直接関係のない実績にすぎません。作っていないフィーチャについては、まだ大した設計すら行っていないのです。想定していなかった技術的な困難が存在しない保証は、どこにもありません。必要充分なアーキテクチャを吟味できるシステム全体の段階的詳細化を繰り返せば、必要充分なアーキテクチャを構築することが可能となります。必要以上に緻密でもなければ、YAGNIと無責任に叫んで、明らかに必要な部分を後回しにするわけでもありません。アジャイル型の開発では、アーキテクチャを充分に吟味する前にいくつかのフィーチャを構築しがちです。cost」となり、最適なアーキテクチャの実現を妨げる可能性があります。実際に実装を行ってみないとアーキテクチャの妥当性が分からないのであれば、事前にコアドメインだけを実装してみる、などの手段もとれるはずです。ステークホルダ間の利害関係の調整をじっくり行うことができるステークホルダ間の利害関係の調整は、非常に重要かつコストも高く、失敗しやすいポイントです。調整し、明文化し、何度も推敲と議論を重ね、全体のコンセンサスを得る必要があります。そのコストの高さから、何度も行うのは得策とは言えません。アジャイルな開発では、この困難な部分を、お金を支払う顧客(PO)に一任し、短いタイムボックス毎のアップデートを要求します。「ステークホルダ間の利害関係の調整」を「(例えば)2週間おきに」「顧客が」行う。これは現実的とは思えません。開発チーム側に顧客プロキシを立てる、といった代替案もありますが、社外の人間が利害関係の調整を行うと、ますます調整のコストは高くなります(というより、大抵は不可能ではないでしょうか)。責任の分担・階層化ができるシステムの全体が見通せて、必要な仕様が決まっていれば、適当な単位で各チームに責任を分担出来ます。問題が発生した場合も、どのチームが何をすべきか/すべきだったかは明確です。これによりオフショア・ニアショア開発が可能になります。これは大きなメリットと言えるでしょう。大規模な開発では、このような分担なしには、プロジェクトのカオス化を防ぐ事は困難です。「自己組織化チーム」の集合では、プロジェクト全体として上手く回っているかどうかは、誰が担保するのでしょうか。プロジェクトリーダーでしょうか。各チームに自律的に行動してもらっているのに、どうやって担保するのでしょうか。カオスに陥りそうです。うまく回るイメージがわきません。出来る人もいるのかもしれません。少なくとも、自分がこのプロジェクトリーダーになると思うと、胃に穴が開きそうです。並列度を高めることができ、完成された製品を素早く提供できる前項と関連しますが、分担出来れば開発の並列度を上げることができます。これにより、完成した製品をいち早く顧客に提供することが出来ます。※もちろんチームが増えるほど複雑度は増すので、CIや全体での定例mtgなどは必要で、線形オーダで効率が上がる事はないでしょう。言うアジャイル型開発の「迅速なデリバリー」は、全体の一部分のデリバリーに過ぎません。エンタープライズなシステムは、一部分だけでは利用価値がない場合がほとんどです。一部分だけを先行導入してしまうと、後々データ移行等が苦しくなります。そもそも、先行導入したシステムの運用は誰が行うのでしょうか。その後、インクリメントがリリースされるたび、運用方法が変わって行くのでしょうか。リーンスタートアップのbuild-measure-learnのループを回す、という話もあります。エンタープライズなシステムで、短いループで「システムの価値」を継続的に検証していく必要があるのでしょうか。事前の検証で十分な場合の方が多いのではないでしょうか。洗練された形式知が手に入るウォーターフォールのフェーズゲートは、ほとんどの場合「形式知(大抵は仕様書などのドキュメント)」を要求します。フェーズゲートをくぐりぬけるうち、これらの形式知は何度もレビューされ、洗練されていきます。「洗練された形式知」の存在は、人やベンダーを交換可能にします。これは属人性・べンダーロックインの問題を解決します。プロジェクト毎にこのような「洗練された形式知」が生成されることは、標準化の実現や、ノウハウ・ベストプラクティスの蓄積など、組織としての成長を支援します。アジャイル型の開発では、知見はチームメンバーの中に暗黙知として蓄積します。確かに暗黙知は形式知よりも「帯域幅」が広く、近視眼的には効率もよいです。上記の理由から、大抵のSIerでは「洗練された形式知」を選ぶのではないでしょうか。いうより、大抵のSIerには既にこのようなノウハウが蓄積されています。これらを放り投げてまで、新しい開発手法を適用するほどの価値があるのでしょうか。専門分野の単位で作業分担ができるアジャイル型の開発を行うのであれば、開発チームはユースケース単位(あるいはストーリーでもフィーチャーでも呼び方は何でもよいです)で開発することが必須といえます。よって、コンウェイの法則から、チームは職能横断型であることが望ましい、という結論が導かれます。職能横断型のチームというのは、基本的に組織として管理しづらいです。メンバーが抜けたらどう補充するのでしょうか。それに、薄く広く知っている開発者よりスペシャリストの方が、ある特定分野では明らかに技量が上です。いったスペシャリストの個性を活かすことこそが、組織の強みにつながるのではないでしょうか。追伸はてなブログに若干悪戯されましたが、本日は4月1日です。私の中に新しいペルソナを生み出して記事を記述してみました。いえ、(若干知ったかぶり感はあるものの)内容は真面目に書いています。2月のツイートをまとめた備忘録。グルーピングは非常に適当。実践メモ先週の教訓:ベロシティは有用な指標だけど、一番大切な「スケジュールへのコミット(直感的に出来そうと感じて、それを(ある程度)約束出来る)」を軽んじてはいけない。「今それどころじゃない」とかいってタイムボックスを無視して、よかったと思った経験は今のところ一度もない。Free初期の見積もりの当てずっぽう感と、初期の設計の想定漏れの量がやばい。初期に正しく想定出来るべきだと考えて、「失敗」して自分を責める技術者はどのくらいいるのだろう。少なくとも私はその一人でした。webストーリーのテンプレの冒頭「(ペルソナ)として、」を、「(ペルソナ)は、」にした方が個人的にしっくりくることを発見した。「(ペルソナ)は」の方が、仮説が嘘っぽい時に違和感を強く感じる。web「仕様とシナリオは相補関係にある」とどこかで習ったが、同じように、「要点を絞った完結な説明」と「ストーリー」もきっと相補関係にある、はず。webポモドーロテクニックのタイムボックスの使い方を誤るとケアレスミスを招く(というか招いて後輩に迷惑をかけた)。スプリントのスプリントデモのような「抑止力」を取り入れられるとよいのだが。webenergize「リーダーの大切な資質を一つだけ挙げるとすれば、明るいこと。Buttonこの視点は面白いですね。Button「○○やりたい」と「これがあれば○○できる」との間はだいぶ合って。後者は色々お手伝いできると思うんだけど(しなくてもできるだろうけど)、前者は正直難しいなぁと最近特に思う。TweetDeck◯◯できたらいいんですけどねぇ...ってのは、やってみたら良いと思う。全部思い通りにならないから、その時には一旦それを前提として受け入れて、デザインすれば良いわけで。やってるうちに最初のことができるようになるかもしれないし、そもそも不要になってるかもしれないし。Buttonとても心にしみますねー。Buttonagileこれはとてもいい資料だなー。Buttonどんな方法論も、最初は知って試してみる時期があり、自分の現場でうまくいかないことにヘコみ、それを一旦は忘れて、自分の頭で問題の本質から考えるようになって、そうして少しずつ理想に近づいていくうちに、そのうちに外からは、その方法論を実践しているように見えるようになる。