グループ開発は難しい

精神的に未熟なせいか、グループ開発がものすごく難しく感じる。

少人数で、ある1つのシステムを開発する事を考える。

情報共有
BlogなりWikiなりを利用して、情報を1カ所に集める。
利用するツールに必要な条件は、『誰でも編集できる』、『どこからでも閲覧できる』、『必要な機能が揃っている』こと。必要な機能はケースによって違う。大体共通して必要な機能を考えてみると、『フォーマットを作る』、『分類補助』、『更新通知』、『検索』など。
一定ルールの元で情報共有を進める事を考えると、文書を作る際に自由度を出来る限り制限する必要がある。テンプレートや、文法などを指定する事でこれを実現する。
文書を置く場所を機械的に行う事も大切。この作業も出来る限り負担が小さくなるような仕組みが必要。
更に、情報が作られたり変更された場合に、何らかの手段で通知する必要がある。事を安全に進めるためにも、情報欠落を防ぐ仕組みが必要。
また、必要な情報を簡単に探す事が出来る仕組みも必要。これは、検索だけにとどまらず、構造自体がこれに適した物である必要がある。

ルール作り
集団で行動する場合、当然ルールが必要になる。
ソースの記述ルールから、情報管理のルールまで。神経質なくらいルールを作り、これの尊守を徹底する。定期的にルールを見直して、行動を阻害するようなルールは適宜改善していく必要がある。
ルールを作る際に、何にどのようなルールを適用するか考える必要がある。常に業務フローを監視し、どのような弊害があるか、何をしたら改善されたかをまとめる。
個人的に、全体を見渡す余裕がないので、ここが致命的に弱い。最低限、自分が行って来た作業に関して定期的に所感をまとめる必要がある。

知識共有
業務情報にとどまらず、技術情報なども出来る限り共有する。これによって、グループ全体の底上げを図り、生産性の向上につとめる。
技術勉強会や便利なツール、OSの機能など、自分が知っている事でも他人は知らないかもしれない。もし、それを知る事で生産効率が向上すると思うなら、さりげなく披露する事が大切。かしこまった場を設けずとも、ふとした会話に織り交ぜてはどうだろう。酒の場にまで持ち込む事は無いと思うが、仕事の合間であれば技術者同士その手の会話をいとう事は無いだろう。
個人的な事になるが、OSのショートカット機能やテキストエディタなど、普段多く使うものに対する知識の不足を実感している。コピー&ペーストはともかく、ほぼマウスで作業しているため、可能な限りキーボードで作業を行うこつなどはぜひとも知りたいところ。
知識面にオープンな雰囲気を作る事で、グループの底上げや活性化が期待できる。

グループ作業と単独作業の見極め
これは現時点での所感にすぎないし、分かっていて当然の事だろうと思う。
ある機能に関する開発を担当を決めず、その都度担当可能な人員で受け持つ状態だとする。その場合、回転は良くなる。ただし、その後何かあった場合に、改変部分などの情報共有が徹底していないと、情報が不確定に分散する事になり余計な手間が想定される。細かな変更などまで文書として残す必要があるか、線引きが難しい。ルール作りは大切だが、それが煩雑になりルール管理で負担を強いられる事は避けたい。
機能を限定して担当を決めた場合、担当の都合次第では相当に回転が遅くなる。ただ、その分野に特化した作業を続ける事になるため、短期間にノウハウが蓄積される事になる。そのノウハウを披露する場を定期的に設けるようなルールを作れば、一定水準の情報共有は保たれる。全体のノウハウを全員で同時に作るよりも、各人で受け持って作った物をまとめる方が効率的な場合もある。

定期的な意見交換
定期的にミーティングを開き、特定の事柄について議論する。これはどこでも行っている事。どのような事柄について、どのような情報を提出するか。各人がそれぞれ目的を理解し、やるべき事を明確にする必要がある。
時間的な都合から、細かく設ける事は難しいかもしれない。それでも、出来る限り最小限の議題にまとめ、目的ごとのミーティングを行う事が望ましい。大きな分類の中でまとめてミーティングを行うとして、各議題の関連性が低いと印象の薄い議題は頭に残らない事が予想される。議題が増えれば、必要な時間も増える。一度に大量の情報を処理するためには、多大な労力が必要になるため、効率的な意見交換を行うためにも、議題は最小限にまとめる必要がある。
あまりにもミーティングの数が増えるのも逆効果なので、必要なときに必要な人員で行う突発的なミーティングで対応する方法もある。ただし、意見や所感をまとめるためにも、一定の期間で行われた方がより効果的な議論が期待できる。

書く習慣
プログラミングの場合、仕様や設計、コーディングなど『書く』仕事。それでも、多くのプログラマはドキュメントやマニュアルを作る事が嫌い。
これは頭の使い方が違う事が原因の一つ。ある種、設計やコーディングは感性に頼って行える。もちろん、全てが勘頼りな訳ではないが、慣れている事は考えるより先に手が動く。その状態であれば、特に苦に感じる事は無い。
ドキュメント類を書く場合は、プログラミング言語の様な明確なルールが定まっていない事が多いため、ルール作りから始める必要がある。また、同時進行でドキュメントを作っていれば問題は無いが、大抵実装作業が先行してしまう。個人の資質の問題の場合もあるが、作業計画の都合上の場合もある。正当な理由で実装が先行した場合、一度に膨大な量の不慣れなドキュメント制作を行う事を考えると、トラウマ的な印象を持ってしまう。
問題点は『文書の定型化』と『古い情報の再現』、『異なる性質の"考える"』だろう。文書フォーマットに関しては、事前に型を準備する必要がある。テンプレートやツールを利用して、後の作業を簡単にするために先に苦労する事はどうしても必要。
古い情報の喪失を防ぐためには、細かなメモが必要。ソースコードのコメントや、作業記録など。作業中に必要ない情報であっても、先に必要でないとは限らない。見極めは簡単ではないが、経験によって上手く線引きできる世に努力する必要がある。見極めが出来ないのであれば、明らかに不要な情報以外は何かしらの形で残しておく。
業務フローに関する『考え』と開発に関する『考え』とは関連性はあるが、性質的には異なる。両方があって生産的な業務が可能になるというのは事実だが、純粋にプログラミングによって物を作る事だけを考えていると、業務フローは見逃しがちになる。業務に関する所感などを書く習慣を付ける事で、必然的に業務について考える時間を作る事になる。

グループで作る
ある機能開発の担当を決め、担当者が作業する。これは自然な流れだが、最後まで担当者だけで行うよりも、最終的に仕上がる物が複数人で作り上げられる事が理想的。
グループ開発の形を取っていても、別個に分類した時に結局単独で開発を行っているとすれば、それは足し算的な効果しか期待できない。これは複数人を担当にするという単純な事ではなくて、作り上げる過程に複数人の意見が介在するという事に意味がある。
開発効率を考えれば、実装作業(コーティング)は単独で行った方が効率が良い。しかし、プログラムを作る過程はいくつかに分ける事が出来る。仕様を決定し、設計を行う。動作検証用のテストをつくり、コーディングを行う。ドキュメントを作成し、情報共有をはかる。大雑把に考えてもこれだけの作業が存在する。
全てを単独で作業するとなると、どうしても成果物が主観的なものになってしまう。作業中は集中しているため、どうしても視野狭窄となり客観的に考える事が難しくなる。気分転換や、レビューなどを挿む事で避けられる事ではあるが、そこに第三者を介入させれば、より効果的な結果を得る事が期待できる。
ソース自体をドキュメントとして成立させるためには、どうしても客観的な視点が必要になる。主観的な情報を共有できる場所においてとしても、それを理解する事は難しい。客観的な情報であれば、比較的容易に理解できるため情報共有もはかどる。
複数の頭を利用できる機会があるのであれば、これを積極的かつ有効に使わなくては勿体ない。全ての場合ではないにしろ、客観的な意見が必要な場合に、自分で客観的に考えようとせず第三者の力を借りるというのも一つの手段。

コミュニケーション
グループで作業する以上、複数の意見・立場・行動などが存在する。これらを全てルールで統制する事は不可能。結局、コミュニケーションを取る事が大切になる。
一度に理想的な方法が見いだされる事は無く、トライ&エラーで常に改善していく必要がある。この流れを止めず円滑に進めるために、積極的なコミュニケーションが必要になる。
結局、全ての基本はコミュニケーションにある。これまでに挙げて来た事柄について言える事。何かを発信し受信する事はコミュニケーションと同義。複数人のパワーを利用して何かをしようとする場合、これの生産性を上げたいのであれば、効果的なコミュニケーション方法を考える必要がある。
各人に任せるのも一つの方法だが、手助けとして一定のルールや仕組みを考える事で、より良い環境を築く事が出来る。

まとめ
とりとめの無い事をだらだらと書いてしまったが、これは誰に言うでも無く自分に言い聞かせる事が第一の目的。目立つところにばかり興味を持ち、地味でも本当に重要な部分をないがしろにしている事に今更ながらに愕然としている。
グループ開発に関する手法は色々考えられており、それらを調べる事で生産性の高いグループ開発を行う事は出来るだろう。しかし、根幹部分はどの手法であっても同じ事で、『集団で作業する事の意味』すら理解しきれていない自分にはまだ荷が重い様に思える。
表層部分を読み取って、猿真似をするだけなら今でもなんとかできるだろう。ただし、その場合は自分が置かれた環境に合わせた最適化を行う事が出来ない。柔軟に対応できる様になるためにも、その手法を調べると同時にその意味についても自分なりに意見をまとめていこうと思う。
『(Blogを)書く』ための時間を作った事で、『考える』習慣が身に付きつつある。ライトな雑文を書く事が基本で、それは今後もその予定だが、機会を見つけてそれなりにまとまりのある文章を書いていこうと思う。

プロフィール

このブログ記事について

このページは、koshigoeが2005年11月 4日 00:44に書いたブログ記事です。

ひとつ前のブログ記事は「MyWeb2.0Betaからはてなに出戻る」です。

次のブログ記事は「リリースまでに追いかける情報」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。