初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど)
NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。
仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。
仕事をする上ではコミュニケーションが欠かせませんが、特に社内のコミュニケーションは口頭による指示が中心になると思います。何か指示をするにしても、「なぜ今その指示をするのか」「これをすると何のためになるのか」と言った背景が全ての指示で語られることはありません。実際、すべてを説明している時間は無いはずです。
しかし、理由や目的の伝わらない指示は、なかなか思うとおりに実行されません。ここにメンバー間でしっかりとした共通認識があれば「この指示はこの部分に必要なんだろうな」と目的を推測したり、「ここは私ならこう思うから、違う理由を聞いてみよう」などの、アクションが取りやすくなると思います。
そこで、せっかく個人では無く、会社員として仕事をするので、この共通認識の部分をプレゼンにまとめて、これを基盤に仕事の方針を決めていきたいと思います。とは言っても、初めてこういう事をやるので、まだまだ全然なダメダメな資料です。しかし明示することによって、おかしいところも気がつきやすく、見直しもしやすくなるだろうと思って、ブログに公開することにしました。
オンラインとPDFで公開しているので、もし良ければご覧下さい。
一緒に仕事をする人には、この資料を読んで「masuidriveなら、こういう風に考えるだろうから、こうしておこう」とか「この指示は、こういう考えでだしたんじゃないかな」と考えて貰えるようになれば大成功だと思っています。
なにせ会社員経験が浅いので、一般的な会社の仕事の進め方が分からず、この資料のどこに違和感を感じるか、実行するのに何が難しいのか、もっと良い方法はどういう事があるのか、など分からない事だらけです。
もしこのプレゼン資料をみたら、何かコメントを残して貰えると嬉しいです。ぜひお気軽によろしくお願いします。
JRubyを中心に活躍されている、大場 光一郎さん <koichiro@meadowy.org>には、資料作成とブログの校正でご協力いただきました。この場を借りてお礼をさせていただきます。
wizardofcrowds
素晴らしいドキュメントだと思いました。なになぜ意思決定を、開発メンバー一人一人にさせている点が、私の勤務先にはそぐわないのですが、そんなことはどうでもよく、むしろ、すぱっと、していて、美しく思いました。参考にさせていただきます。
masuidrive
うぉ、早速のコメントありがとうございます。
これは自社サービスを作るときの物なので、通常の開発案件とはちょっと違うかもしれません。
「意志決定をメンバーにさせている」と思った部分ってどこでしょうか？メンバーに考えては貰うけど、最終的な決定は私が行おうと思ってたんですがｗ
nay
こんにちは、大場嫁です。
とても参考になるし取り入れていきたいなと思いました。
気づいたことがありますのでちょっと長いですが書き込みします。
この資料で言いたいことのひとつは、「質の高いコミュニケーションをしよう」ということだと思うのですが、ここは注意が必要かもしれません。というのは、日本の会社や開発現場では、そもそもコミュニケーション自体が不足しているケースが目立つと個人的には思っているからです。質の低いコミュニケーションすら確立していない場でこの資料にある体制をいきなり目指すと、萎縮・脱落する人が出るかもしれません。つまり、「無駄なコミュニケーションするな」が過剰に受け取られてしまうかもしれないと。
・ステップ１：とにかくコミュニケーションをする
・ステップ２：コミュニケーションの質を高めていく
という具合にステップを分けて、チームの構成員が今どこの段階かをみながら進めていくと良いのではないかと感じました。
のりお
多人数で作業をしたことがないので、とても参考になりました。とてもシステマティック（死後かなw）で合理的ですばらしいと思いました。
もろはし
テストの部分、UnitTestを書いてintegrationを書かない、というのは逆にしたほうがいいと思います。
一番外側からのテストがちゃんとある(たとえ自動化されてなくても、それをどっかで振り返る業務フローがある)のは、ちょっとやそっとその時点でのコードがきれいなことよりも価値があると思いますYO。
コミュニケーションは難しいですよね。オッサン好きする飲ミニケーションwは嫌いですけど、お酒飲みながら話すのは好きだし。あ、それは会議じゃなくやれってことか。
いまの書き方だと対面でのコミュニケーションを拒否してるように感じられちゃうかもです。
masuidrive
この資料自体が、ある程度のコミュニケーションスキルを持っている人を対象にしてしまっていました。既に今のコミュニケーションの方法に不満がある人とか。
コミュニケーションに慣れていない人には、まずは積極的にコミュニケーションを進めていくのは必要ですよね。そもそも私は話すのが大好きなので、この視点は抜けていました。
確かにこの資料だと、過剰に対面コミュニケーションを拒否しているように取られちゃいますね。対面のコミュニケーションは大事だと思っているのですが、必要のない、質の悪いコミュニケーションは減らしたいってだけで。
この辺はnayさんの意見を参考に書き直してみます。
テストは、Railsで組んでいるとモデル層が厚いので、UnitTestを中心にしてしまっています。どうもIntegrationテストは書きづらい気がするのは、私のコードが良くないからかなぁｗ
shachi
おお。コミュニケーションしないと仕事した気にならないおいらが来ましたよ。
ナニからナニまでsubversionとか、とりあえず、IM&Mailとかってのは激しく同意。
でも、Mailは「重要な件だけ」IMは「呼び止めるものだけ」っていう感じが根強い日本だと….どうかなぁ??
と、ちょと不安になりました。
コミュニケーション能力って日本だとかなり低いですよ。喋るのが「悪」って感じの時期長かったしね。
ブレインストーミングは大好きなのですが、会議は寝ます。間違いなく。
catch
大変面白うございました。
ちょうど、Getting Realを読み終わったところだったので、なおさらでしょうか。
私は、自分ではソフトウェア開発をしないので、そういう現場はよくわからないのですが、バグトラッカーとコード管理システムを使わないソフトウェア開発って、どのくらいあるのでしょう？ オープンソースの少し大きめのプロジェクトを眺めていると、それなしのタスク管理なんて成立しないように感じます。でも、それは実は少数派だったりするのかなぁ、と思いました。
こういうところから遠いところで仕事をしている人向けに、Joel on Softwareの「やさしいバグトラッキング」とか参考資料としていいかも知れませんね。テスト関係のところは、よくわかりませんでした。
あと僭越ながら
「品質が高いアプリケーションを早く作る」
⇒品質の高い or 高品質の
*” 品質が、高いアプリケーションを早く作る” と読めなくもないので。
take-sa
増井さんども。
プレゼン面白かったヨ。細かい所はよくわからんが、意思疎通のやり方は羨ましいなーと。自分もそうなりたい。
あと、『作業工程全て記録』はやりたくても「出来ない」or「出来なかった」ので、これから気になったらポイントをどんどんポストしてくれると参考になってうれしいかも。
josswest
会議に費やす時間が長いのはかなり無駄だと思っているので、このプレゼンはとてもためになりました。
これからまさにプロジェクト開始しようという状況にいるので参考にさせていただきます。
dot
どうも。
たいへん興味深くスライドを見させていただきました。
まぁ道具なので、tracにこだわっているわけではないと思いますが、気になるのはtracのチケットのところでした。
エビデンスを残す目的でtracのチケット駆動で使いたいという意図はよくわかるんですが、自分がいろんなプロジェクトでtracを使ってきた経験で言うと、なんか今イチしっくり来た事がないんですよね。
誰に対するコミュニケーションであるか、がミソのような気がするんですが、顧客に見せることを考えてしまうと、チケットの粒度感を合わせるのが難しいですね。顧客だと要求レベルのチケットが一番理解しやすいと思うんですが、開発メンバーで考えると、作業タスクにまで落とさないと、チケットの滞空時間が長くなってしまったり、複数人で作業分担をしにくくなったりします。
あと、masuidrive wayというか、トータルな開発のスタイルを宣言するというのは面白いし、非常に価値があることだと思いました。
kawara
masuiさんのようなスタイルを持つ人がプロジェクトリーダーだと
仕事がしやすそうですなー。うらやましいですわ。
会社で仕事をしていると、どう考えてもこの進行じゃ危ないよなぁ
と思えるような状態でもガンガン仕事が進んじゃいますよね。
転ばぬ先の杖という点でもスタイルについて伝えられるような資料を
手元に持っておき、仲間や相手にいつでも見せられるように仕込むことは大事なことなんだろうな、なんて感心させられました。
このようなプレゼン資料を見せて反応を見ることで相手との温度差なりを計るというのも一つのメリットかもしれませんね。
本当は大事なこういう仕込みに掛ける時間を惜しんで損していることはたくさんあるなぁ。 (-_-)
masuidrive
意外にちゃんと使ってない会社があるんですよーw < バグトラッカーとかソース管理 校正ありがとうございました＞catchさん Tracの使い方については、私がお客さんの中に入って開発する形式だったので、あまりその辺が問題にならなかったんだと思います。＞dotさん 温度差とか見るとか、あのときからこう言ってたじゃん、って言うためにもプレゼンっていいですよｗ＞kawaraさん
もぎゃ
あれ。トラックバックが飛んでいないような。
えいっ。
http://d.hatena.ne.jp/mogya/20070713
参考になるお話ありがとうございます。
「コマンドも含め全てのファイルはSubversionで管理」のくだりをもう少し詳しく知りたいです。
masuidrive
トラバがスパム扱いになってましたー。Askimet誤動作おおいなぁ。
了解です。数日中に詳しく書きます。
つかもと
大変参考になります。
個々の項目も（Integrationテストはあきらめる、以外）かなり同意できますし、最後にフィードバックと改善に言及しているのが素晴らしいと思いました。
Ken.O
誇りを持って自分がした仕事をみんなに公開する
・批判される恐怖心
・自分が不要になる恐怖心
30分調べても分からなかったら○○に聞く
・プライドが許さない
・馬鹿にされるのが怖い
という事で、うまく行かない事が多いような。
あと、このポリシー以前に真逆の企業文化や体質が根付いていて、
無駄は多いながらとりあえず実績を積んでいると抵抗が生まれる。
安定した方法から、未知の方法に変わる事への恐れの克服が大事。
頭をカラッポにして、利害関係抜きで考える柔軟性があれば、
こんなに詳細に具体的に書かなくても、スムーズにいくのでしょう。
それには虚栄心を捨てて、相手が言った事を素直に吸収しあう意思が必要ですが、
経験が長くなるほど自分のやり方を外れる相手とやりづらくなるようです。
このドキュメントは自分の目指す所と一緒ですし、今の方法論としては
ベストだと思いますが、「これは最善、これ以上変えたくない」という
暗黒面に堕ちると、うまく機能しなくなるかもしれません。
H.Asano
オレンジニュースから来ました。
自分も１年くらい前に旗振ってtracを導入して、いろいろその運営に苦労しました。
スライド、大変興味深く拝見させていただきました。
自分のところでは、情報の整理や構成管理の面ではかなり改善しましたが、コミュニケーションの部分ではトップダウンで積極的に変わらないと難しいですね。チケットが未だ上手く活用できていないです。
各人のプロジェクトの掛け持ちが多く、個人用のツールを別途使うなど、組織、プロジェクト、個人の情報の１元化が出来ず、全体最適なカタチが未だ見えていません。
また、以前は「○○やっておいて」的な指示でも動けていたものが、チケットになると終わるまで残留します。
何を持って終了とするかを明確化する作業は、非常に上流のコストがかかりますが、彼らは彼らで他の調整事などが多く、なかなかその余裕が無いのが悩ましいところです。
「最低限こんな事態は防ぎたい」レベルがクリアされていれば、あとは使いやすいモノをみんなで使ってくレベルでいいのかな、と最近思っています。
Googleスプレッドシートなんか、Excelで管理の文化からも以降しやすくて良いですよ。
foursue
このプレゼンは馬鹿には実践できない。同じようなことを考えていた人たちの中でしか実践できない。だから、どこでも実践できるようなものではない。
馬鹿でも実践できるんだろうか。