20070629 会議内容まとめ
議題
- 作業管理部署の役割を明確化する
- 改善作業などについての意識の共有化を行う
- 出仕時間の偏りを改善する方法をさぐる
参加者
- Ｋ２＠準官長（改善担当）
- シコウ＠護民官３級（作業管理部署長）
会議時間（2007/06/29 22:00 ～ 翌1:00）3時間
会議場所：ＭＳＮメッセンジャー
目次
作業管理部署の作業についての質疑
部署の作業内容確認
全体指揮
吏族チェック対応部署・その他案件対応部署
- 実働グループ。案件の受付から活動終了報告まで、実際の護民官活動。
作業管理部署
- 実働グループが動きやすいように事務面（wiki管理、各種書式、データベース整理）のフォローをする。縁の下の力持ち、総務的な動き。
連絡業務はどこに属するのか？
- 各藩国に連絡を回す仕事はどこが行うのか
- 作業チーム→人数が足りない
- 作業管理部署→作業チームの依頼で管理部が動くと時間がかかる。空き時間が発生する。
- 護民官ＭＬで募集→護民官メール登録率が不明。お手伝いが集まらない可能性がある。
必要な作業人数などはその案件によって変わる（例１：このイベントについて全藩国に聞き込み、例２：このイベントで同じ裁定が下った国に調査に行く）ため、作業チームから必要な人数を募集してもらった方が動きやすい。
ターン７までは出仕義務がなかったが、ターン８には強制出仕となるので作業人数は多い。また、何の作業をしていいのか分かりにくいため実働できないという方がいたが、連絡貼り付けなどの作業はガイドも要らず時間もかからない為、出仕時間の少ない方へ積極的に作業を振る事で、人員不足は回避できる。
ナンバリングについて
案１：wiki管理を前提
○ナンバリング体制の見直し（案）
→ ＦＥＧが６月２３日に訴え、護民活道全体で３２番目の案件で吏族チェックに対する訴えだった場合
→ 1-03-32-0623：案件名
部署名は １吏族チェック ２その他案件 とする。
２重管理体制とする。
・総合番号による一覧をまとめたページを作成。
・部署情報ページにも対応案件として部署の案件を記載
- 利点
- 通し番号なので案件のぬけなどが確認しやすい
- 受付日情報がナンバ内にあるので、お待たせしている時間が一目で分かる
- wiki管理、データベース作成時に検索しやすい
- 欠点
- 初心者にはナンバリングしにくい
- ナンバを間違えやすい（２重登録、ナンバリング時点でのぬけなど）
- wikiに偏ると随時更新が難しい
- 打開
- 作業管理部署がスケジュールを組んで管理をwiki管理を行えば即時性は高い
- 作業の偏り、負担は４、５、６級のwiki作業可能者を募る事でフォローできるのは
- 受付時にはナンバなし→作業管理部署が拾う時にナンバ割り振り→作業リーダーが掲示板記事を修正する。という流れで正しいナンバがふれるのでは。
案２：掲示板管理を前提
最低限の情報だけをナンバーで表記することを提案します
案件種類＋受付ツリー番号＋ツリー内の連番(＋必要な場合のみ枝番)
とすると短くなると思います
例１
吏族チェック関連案件、申告ツリー2で3番目に受付した案件の場合
R申02-03
例２
吏族チェック関連案件、相談ツリー1で2番目に受付した案件を3分割した1件目の場合
R相01-02-1
この方法なら長くなりすぎず、受付時のナンバリングも簡単だと思うのですが、
いかがでしょうか？＞ＡＬＬ
- 利点
- 作業者が簡単にナンバリングできる
- ナンバが長くならない
- 間違えにくい
- 受付た場所がわかる
- 現場作業者の作業性を考えてあるので初動が早い
- 欠点
- 盛り込まれている情報が作業中に必要なものではない（実作業中、管理作業中にはどこで受け付けたかはあまり問題にならない）
- ＢＢＳ管理では古い情報が大量に表示される為、視認性が悪い
- 初心者が情報を探しにくい
- 打開
- 作業進行状況については案件の申込順になっているので、慣れれば確認できる
- 人手がかからないため作業負担が少ない
- フォローのためにwikiに拾えば視認性もよくなる
最終的に
- 本当にナンバリングが必要なのか。何のためにナンバリングが必要なのかなどを交えて、話し合う必要がある。
- →wiki管理について
後日、協議での議論
- ナンバリングが必要なのは管理者であって作業者ではない。
- 何の為にナンバリングが必要か→通し番号をふることで案件抜けを防ぐ為・同名の案件が合った場合に混乱しない為
- 今までは作業者が管理ナンバをふるため、現在のようなシステムになっている。
- 新規案件発生→作業ＢＢＳに案件ツリー→管理部が拾ってｗｉｋｉ反映（この際に単純な通しナンバをふる）→管理部が作業ツリーに案件ナンバの報告「タイトル：【管理ナンバ0123】：本文：この案件の管理ナンバは0123です」
- １プランとして検討。最終的には作業者へのアンケートを。
wikiトップページについて
聞き取りでわかったこと
- 利用者視点
- どこから申し込んでいいかわからない
- 申告掲示板への入り口がトップにありますが、「いきなりＢＢＳに書くの？説明とかは？」と、多少うろたえる
- 護民官活動がどういう流れで行われるのか利用者向けの説明がない。結果は何時もらえるのか、どういった作業をするのかわからなくて、待っている時間が不安。
- 必要な作業
- テンプレの書き方、通常の護民官活動の流れについての説明が必要。
- 訴え方のガイドページを作り、そこから申告相談ＢＢＳへリンクを貼る。
- 作業者視点
- 「人員募集中の案件」にあっても人員を募集していない事がある。
- 作業募集していないので、仕事が無いと思った。
- 作業ツリーやToDoから飛んでも、色んな案件並んでいて、何をやっているかわからない。
- 問題点の確認
- トップページ情報の即時更新ができていないため、内容に信用性が無い。
- 案件が細分化しているのにちゃんとした管理が出来ていない
- ＢＢＳが１ツリー多案件になっているので、視認性が悪い。また、時系列を意識してないので、古い情報と新しい情報が混在してる。長いツリーの上下も手伝い、把握するのが大変。
- 解決策
- コメント付き進捗管理ページ（特殊作業担当者向け進捗メモページみたいな）をつくり、作業者は作業の進捗を書き込む。
（例「【案件名】新規案件作業２終了、人員募集中ー！作業ツリーURLはこちら！」「【案件名】調査に人手が要ります。URLにてあと２名臨時募集」「【案件名】申告者様に護民官作業を確認してもらいました。活動終了です。」等）
管理作業班は決まった時間にwikiの管理ページ更新作業して、更新完了したコメントは削除していく。
更新タイプスタンプ以降の作業進捗は作業者コメントをみればすぐわかるため、作業進捗状況の管理と視認性の向上ができるのでは。
- wikiを触れるのが一部の人で、管理できる人がいないからＢＢＳで、という状態なら、管理部でチームを作ってスケジュールを組んで作業すればよい。作業者に、指揮ライン、どちらもに整理された情報を提供できる。クロスチェックも行える。→wiki管理について
- 管理が確実に行われるなら、１案件１ツリーにした方が視認性が良い。同時進行する案件は各部署５、６件なので、最初のページ内に収まる。古い案件は沈んでいくので、現在進行中の作業の確認がたやすい。
- 携帯電話作業者
- トップに載っている情報が多いため、表示、必要な部分の取り出しに時間がかかる
- 一部携帯ではＢＢＳの内容が表示できない
- 解決策
- トップに載せる情報を整理する。必要の無いと思われるコンテンツは別ページに。
- @wikiに実装されている携帯やＰＣでのみ表示する機能を使ったコンテンツデザインを行う。
実働者不足について
- 護民官活動の難しさ
- 案件によって求められる作業が異なるため、フレキシブルな対応が求められる。
- 護民官の仕事は救済である以上、作業量はもとより判断の的確さが求められるので、精神的な負担が大きい。
- 持ち帰り仕事
- 作業時間が確保できる反面、作業スキルの伝達、経験の継承が行えていない。
- 作業リーダーとチームが別々に作業するため、方針の確認・質問・作業相談する先が全体チャットになる。
- 上級者のチャット常駐
- 権限があいまいなため、全体指揮者に全ての判断をゆだねている。
- 全ての質問に２級以上の人が答える形が常態になっている。
- 指揮ラインは個別案件の全把握が求められるため、作業時間が加速的に増える。
救済案の方針、作業の進め方などを作業班長と指揮ラインで相談、作業チーム内への方針説明、質問相談などは作業リーダーにしてもらうという形にできないか。
- 作業人員の育成が必要
wiki管理について
- 現在の作業者
- リバーウィンドさん、ゆうみさん、シコウ、そのほか２級以上の人。トップページの更新は実動の方がされる事もある。
- 管理者の募集
- 指揮ラインの負担が高い。やる事が決まっている更新作業などは４、５、６級の方におまかせしたい。
ＢＢＳ、ＭＬでwiki作業経験者、またはwiki作業経験は無いがやってみたい方を募集し、wiki管理チームを作る。
チームに登録された方には案件対応部署のほかに管理部署のお手伝いもしてもらう。
- 実際の作業は案件の進捗状況管理、クロスチェックなど。経験上、３０分程度のお仕事なので、複数人数でローテーションを組めば負担は少ない。また、確実に出仕時間を確保できるため、出仕時間不足で困っている方には最適。
- 初心者の方が迷わないように作業ガイド、また、wiki作業未経験者のための講習会が必要。
- 想定される作業
wiki管理によるナンバリング
wikiトップページの管理
- 作業訓練できる場所が必要。→案件データベースについて
案件データベースについて
データベースに必要な内容。データベースの形態。
- 案件タイトル、法官の裁定、処罰発生イベント名、ナンバリング、作業ツリーＵＲＬ、以上を拾ってｗｉｋｉのページにまとめる。一番簡単で更新が容易。ブラウザの検索でどうぞ。
- 事務所とは別のwikiに１ページ１案件で案件を保存。
ナンバリング、案件タイトル、法官の裁定、処罰発生イベント名、作業ツリーＵＲＬ、護民官活動の流れまとめ（報告書）をまとめる。ナンバリングから処罰発生イベント名までをタイトルに格納しておけば、タイトルのみ検索、本文込み検索の２パターンを使って柔軟な検索を行える。
- どこかにサーバーを用意しＰＨＰ＋Ｍｙｓｑｌを設置する（現実的では無いので却下）
- 要点のみまとめるか、あらすじつけて報告書をまとめるか（過去の案件では報告書のまとまっていないものもあるので、新規に書き起こす必要がある）のどちらか。
- 最初は案件の整理と報告書からのコピペ（あるいはリンク）、次の段階で報告書をまとめるなどのタスク割りが必要。
- 締切りの無い作業なので、実働をしたことが無い方に護民官作業のご理解いただくとともに出仕時間を稼いでいただくことが可能。
- 報告書をまとめる事で、案件対応部署作業の仮体験が行える。
- 案件の整理やwiki登録を行う事で、管理部署作業の仮体験が行える。
- 人材の育成につながるのでは。
外部への応対について
- ログの管理、対外的な文章などについて苦情が出ている
- 対外活動について、実働作業用ではなく意識統一のためのガイドが必要なのでは。
- ログの管理
- プライバシー案は、許可のないログを公開した話というのはある程度広まっている可能性があるので、信用回復のために、ラインを明確に、多少厳しく作成してある。
- 官長（組織長）準官長（改善担当）の許可をもって、プライバシー案の正式採用。
- 対外文章
- 指揮ライン、実働ラインの分割を行い、指揮ラインが作業方針や対外文章のチェックを行う。外部へコンタクトを取るときは上級者に確認とってからという体制により、クロスチェックを行う。
- 対外文章の為のガイド作成。ビジネス文章ガイドなどを参考に。
作業改善案資料に関する質疑
資料の概要
作業者と指揮者の明確な線引き、級ごとの権限と義務を明確に。
- 作業レイヤー：３・４・５・６級の方たちを指します。
- 指揮レイヤー：１・２級の方たちを指します。
- ３級をリーダーに、作業レイヤーで案件を担当。対応方針は指揮レイヤーと相談。案件対応についての質問は案件の指揮を取る３級の方へ。
- ３級は現場作業指揮。案件ごとの調査や作業について指揮、方針を１・２級と相談して決めた後、案件進行、案件把握、報告を１・２級の方へ。
- 指揮レイヤーは部署内案件指揮、部署内案件把握、案件の対応方針決定（官長・準官長と相談）、進行状況・作業時間の管理、報告書の文章チェックなどを行います。
連絡体制の構築
- 一部の人がチャット常駐しなくてもよいように対応していく。
- スケジューリングによる当番制度の導入。
実作業を行いやすいよう環境を整える
- wiki整理：情報過多による視認性の低下がいちじるしい
- トップページに載せる情報の厳選
（詳しくは後日発表されるＫ２さんの作業改善案を）
最終更新：2007年07月04日 15:45
