masuidrive的プロジェクトの方針

Comments:19

wizardofcrowds 07-07-11 (Wed) 16:20

素晴らしいドキュメントだと思いました。なになぜ意思決定を、開発メンバー一人一人にさせている点が、私の勤務先にはそぐわないのですが、そんなことはどうでもよく、むしろ、すぱっと、していて、美しく思いました。参考にさせていただきます。

masuidrive 07-07-11 (Wed) 16:52

うぉ、早速のコメントありがとうございます。

これは自社サービスを作るときの物なので、通常の開発案件とはちょっと違うかもしれません。

「意志決定をメンバーにさせている」と思った部分ってどこでしょうか？メンバーに考えては貰うけど、最終的な決定は私が行おうと思ってたんですがｗ

nay 07-07-11 (Wed) 17:44

こんにちは、大場嫁です。
とても参考になるし取り入れていきたいなと思いました。
気づいたことがありますのでちょっと長いですが書き込みします。
この資料で言いたいことのひとつは、「質の高いコミュニケーションをしよう」ということだと思うのですが、ここは注意が必要かもしれません。というのは、日本の会社や開発現場では、そもそもコミュニケーション自体が不足しているケースが目立つと個人的には思っているからです。質の低いコミュニケーションすら確立していない場でこの資料にある体制をいきなり目指すと、萎縮・脱落する人が出るかもしれません。つまり、「無駄なコミュニケーションするな」が過剰に受け取られてしまうかもしれないと。
・ステップ１：とにかくコミュニケーションをする
・ステップ２：コミュニケーションの質を高めていく
という具合にステップを分けて、チームの構成員が今どこの段階かをみながら進めていくと良いのではないかと感じました。

のりお 07-07-11 (Wed) 18:10

多人数で作業をしたことがないので、とても参考になりました。とてもシステマティック（死後かなw）で合理的ですばらしいと思いました。

もろはし 07-07-11 (Wed) 18:18

テストの部分、UnitTestを書いてintegrationを書かない、というのは逆にしたほうがいいと思います。
一番外側からのテストがちゃんとある(たとえ自動化されてなくても、それをどっかで振り返る業務フローがある)のは、ちょっとやそっとその時点でのコードがきれいなことよりも価値があると思いますYO。

コミュニケーションは難しいですよね。オッサン好きする飲ミニケーションwは嫌いですけど、お酒飲みながら話すのは好きだし。あ、それは会議じゃなくやれってことか。
いまの書き方だと対面でのコミュニケーションを拒否してるように感じられちゃうかもです。

masuidrive 07-07-11 (Wed) 19:17

この資料自体が、ある程度のコミュニケーションスキルを持っている人を対象にしてしまっていました。既に今のコミュニケーションの方法に不満がある人とか。

コミュニケーションに慣れていない人には、まずは積極的にコミュニケーションを進めていくのは必要ですよね。そもそも私は話すのが大好きなので、この視点は抜けていました。
確かにこの資料だと、過剰に対面コミュニケーションを拒否しているように取られちゃいますね。対面のコミュニケーションは大事だと思っているのですが、必要のない、質の悪いコミュニケーションは減らしたいってだけで。

この辺はnayさんの意見を参考に書き直してみます。

テストは、Railsで組んでいるとモデル層が厚いので、UnitTestを中心にしてしまっています。どうもIntegrationテストは書きづらい気がするのは、私のコードが良くないからかなぁｗ

shachi 07-07-11 (Wed) 19:42

おお。コミュニケーションしないと仕事した気にならないおいらが来ましたよ。
ナニからナニまでsubversionとか、とりあえず、IM&Mailとかってのは激しく同意。
でも、Mailは「重要な件だけ」IMは「呼び止めるものだけ」っていう感じが根強い日本だと….どうかなぁ??
と、ちょと不安になりました。
コミュニケーション能力って日本だとかなり低いですよ。喋るのが「悪」って感じの時期長かったしね。
ブレインストーミングは大好きなのですが、会議は寝ます。間違いなく。

catch 07-07-11 (Wed) 19:54

大変面白うございました。
ちょうど、Getting Realを読み終わったところだったので、なおさらでしょうか。
私は、自分ではソフトウェア開発をしないので、そういう現場はよくわからないのですが、バグトラッカーとコード管理システムを使わないソフトウェア開発って、どのくらいあるのでしょう？ オープンソースの少し大きめのプロジェクトを眺めていると、それなしのタスク管理なんて成立しないように感じます。でも、それは実は少数派だったりするのかなぁ、と思いました。
こういうところから遠いところで仕事をしている人向けに、Joel on Softwareの「やさしいバグトラッキング」とか参考資料としていいかも知れませんね。テスト関係のところは、よくわかりませんでした。

あと僭越ながら
「品質が高いアプリケーションを早く作る」
⇒品質の高い or 高品質の
*” 品質が、高いアプリケーションを早く作る” と読めなくもないので。

take-sa 07-07-12 (Thu) 6:32

増井さんども。
プレゼン面白かったヨ。細かい所はよくわからんが、意思疎通のやり方は羨ましいなーと。自分もそうなりたい。
あと、『作業工程全て記録』はやりたくても「出来ない」or「出来なかった」ので、これから気になったらポイントをどんどんポストしてくれると参考になってうれしいかも。

josswest 07-07-12 (Thu) 9:20

会議に費やす時間が長いのはかなり無駄だと思っているので、このプレゼンはとてもためになりました。
これからまさにプロジェクト開始しようという状況にいるので参考にさせていただきます。

dot 07-07-12 (Thu) 14:42

どうも。
たいへん興味深くスライドを見させていただきました。

まぁ道具なので、tracにこだわっているわけではないと思いますが、気になるのはtracのチケットのところでした。

エビデンスを残す目的でtracのチケット駆動で使いたいという意図はよくわかるんですが、自分がいろんなプロジェクトでtracを使ってきた経験で言うと、なんか今イチしっくり来た事がないんですよね。
誰に対するコミュニケーションであるか、がミソのような気がするんですが、顧客に見せることを考えてしまうと、チケットの粒度感を合わせるのが難しいですね。顧客だと要求レベルのチケットが一番理解しやすいと思うんですが、開発メンバーで考えると、作業タスクにまで落とさないと、チケットの滞空時間が長くなってしまったり、複数人で作業分担をしにくくなったりします。

あと、masuidrive wayというか、トータルな開発のスタイルを宣言するというのは面白いし、非常に価値があることだと思いました。

kawara 07-07-12 (Thu) 19:07

masuiさんのようなスタイルを持つ人がプロジェクトリーダーだと
仕事がしやすそうですなー。うらやましいですわ。

会社で仕事をしていると、どう考えてもこの進行じゃ危ないよなぁ
と思えるような状態でもガンガン仕事が進んじゃいますよね。

転ばぬ先の杖という点でもスタイルについて伝えられるような資料を
手元に持っておき、仲間や相手にいつでも見せられるように仕込むことは大事なことなんだろうな、なんて感心させられました。

このようなプレゼン資料を見せて反応を見ることで相手との温度差なりを計るというのも一つのメリットかもしれませんね。

本当は大事なこういう仕込みに掛ける時間を惜しんで損していることはたくさんあるなぁ。 (-_-)

masuidrive 07-07-13 (Fri) 3:50

意外にちゃんと使ってない会社があるんですよーw < バグトラッカーとかソース管理
校正ありがとうございました＞catchさん

Tracの使い方については、私がお客さんの中に入って開発する形式だったので、あまりその辺が問題にならなかったんだと思います。＞dotさん

温度差とか見るとか、あのときからこう言ってたじゃん、って言うためにもプレゼンっていいですよｗ＞kawaraさん

もぎゃ 07-07-13 (Fri) 7:24

あれ。トラックバックが飛んでいないような。
えいっ。
http://d.hatena.ne.jp/mogya/20070713

参考になるお話ありがとうございます。
「コマンドも含め全てのファイルはSubversionで管理」のくだりをもう少し詳しく知りたいです。

masuidrive 07-07-13 (Fri) 7:36

トラバがスパム扱いになってましたー。Askimet誤動作おおいなぁ。

了解です。数日中に詳しく書きます。

つかもと 07-07-13 (Fri) 10:27

大変参考になります。

個々の項目も（Integrationテストはあきらめる、以外）かなり同意できますし、最後にフィードバックと改善に言及しているのが素晴らしいと思いました。

Ken.O 07-07-13 (Fri) 17:40

誇りを持って自分がした仕事をみんなに公開する
・批判される恐怖心
・自分が不要になる恐怖心

30分調べても分からなかったら○○に聞く
・プライドが許さない
・馬鹿にされるのが怖い

という事で、うまく行かない事が多いような。
あと、このポリシー以前に真逆の企業文化や体質が根付いていて、
無駄は多いながらとりあえず実績を積んでいると抵抗が生まれる。
安定した方法から、未知の方法に変わる事への恐れの克服が大事。
頭をカラッポにして、利害関係抜きで考える柔軟性があれば、
こんなに詳細に具体的に書かなくても、スムーズにいくのでしょう。
それには虚栄心を捨てて、相手が言った事を素直に吸収しあう意思が必要ですが、
経験が長くなるほど自分のやり方を外れる相手とやりづらくなるようです。

このドキュメントは自分の目指す所と一緒ですし、今の方法論としては
ベストだと思いますが、「これは最善、これ以上変えたくない」という
暗黒面に堕ちると、うまく機能しなくなるかもしれません。

H.Asano 07-07-13 (Fri) 21:31

オレンジニュースから来ました。
自分も１年くらい前に旗振ってtracを導入して、いろいろその運営に苦労しました。

スライド、大変興味深く拝見させていただきました。

自分のところでは、情報の整理や構成管理の面ではかなり改善しましたが、コミュニケーションの部分ではトップダウンで積極的に変わらないと難しいですね。チケットが未だ上手く活用できていないです。

各人のプロジェクトの掛け持ちが多く、個人用のツールを別途使うなど、組織、プロジェクト、個人の情報の１元化が出来ず、全体最適なカタチが未だ見えていません。

また、以前は「○○やっておいて」的な指示でも動けていたものが、チケットになると終わるまで残留します。
何を持って終了とするかを明確化する作業は、非常に上流のコストがかかりますが、彼らは彼らで他の調整事などが多く、なかなかその余裕が無いのが悩ましいところです。

「最低限こんな事態は防ぎたい」レベルがクリアされていれば、あとは使いやすいモノをみんなで使ってくレベルでいいのかな、と最近思っています。

Googleスプレッドシートなんか、Excelで管理の文化からも以降しやすくて良いですよ。

foursue 07-07-13 (Fri) 21:46

このプレゼンは馬鹿には実践できない。同じようなことを考えていた人たちの中でしか実践できない。だから、どこでも実践できるようなものではない。
馬鹿でも実践できるんだろうか。

Trackbacks:5

Trackback URL for this entry

http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/trackback/

Listed below are links to weblogs that reference

masuidrive的プロジェクトの方針 from @masuidrive blog

trackback from もぎゃんだいあり。 07-07-13 (Fri) 7:20

Re:プロジェクトの始まりはTracから…

masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針:http://blog.mas (more…)

trackback from まちゅダイアリー 07-07-14 (Sat) 0:11

設計書を Subversion で管理したい…

masuidrive的プロジェクトの方針を読んだ。
ちょうど今、 Trac + Subversion で本格的に作業管理を初めていたところなので、タイムリーな内容だっ (more…)

pingback from ぽっぺん日記@karashi.org - プロジェクトに関連するWikiドキュメント、タスク管理もTracでやることにした 07-07-14 (Sat) 12:28

[...] という訳の分からない感じで、プロジェクトを進めていたんだけども、masuidrive的プロジェクトの方針に影響されまくって、とりあえず、プロジェクトに関連するものは一括してTracで管理することにした。 [...]

trackback from prefabolic 07-07-14 (Sat) 20:41

プロジェクトの進め方…

[[masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針]]http:// (more…)

pingback from ぱんぴーまっしぐら » 今日のチェキ 2007-07-14 10-07-03 (Sat) 16:27

[...] ■masuidrive的プロジェクトの方針 [...]