こんばんは、フナコ氏です。

最近その場で知り合った人とグループワークをする機会がありました。
まあ勿論難しかったです。同じ日本語でも、使ってる言葉も文脈も違います。
自分の主張を出しつつも全体に寄せていくのは大変でした。

話し合いって実はかなり入念に準備しないと得る物ないよなーっていつも思います。
集団における意思決定が難しいというのはSSSRCの活動でもたびたび感じているところで、非常に難しいです。
何で難しいんだろうかと今更ながらに思ったので、考えたことをまとめてみたいと思います。



意思決定はリーダーが一人で決める場合とみんなで決める場合があります。
この二種類に絞ってまずは一般的な問題点を挙げたいと思います。

前者は素早く内容が決められるものの独りよがりだと非難されることも多く、
後者はメンバーの合意は得やすいものの議論に時間がかかります。
この辺りはトレードオフの関係ですね。

そして独断はメンバーの人数が多いほど非難されやすい一方で、
話し合いはメンバーの人数が多いほど時間がかかります。
話し合いの議題そのものの難しさに依らず、
人数が増えるほど問題そのものが困難になる気がします。



意思決定を行う上では決定の機会の外にも難しさが広がっていきます。
個人的な経験も加味して書くならば、以下の通り。

独断だと決定者の能力に強く依存する上に、自信が持てません。
所詮学生です。衛星開発の意思決定に自信がある方が不自然です。
それに一回の意思決定で上手くいくはずがないからフィードバックをもらって修正したいと公言しても、そのフィードバックすら返さず文句を言われることも多々あります。
寧ろ文句を言われればまだマシで、無言の抵抗を感じることも多々。
自信がない上に不条理な目に合うのでかなり堪えます

話し合いは参加者の予定を合わせると、話し合いの機会そのものが遠くなってしまい一週間後とかになることもザラ。
これがしかも一発で決まらない場合、遊休時間がさらに増えてしまいます。
間が空いた分、議論の内容も薄まったり振り返りに時間がかかったり…。
話し合いの間で別のタスクができる、という言い分が上手く機能しているのはSSSRCだと見たことがないです。
あと不思議とアイデア出しとかで面白い意見がいくつかあっても、全員の意見を取り入れて意見を平均するとクソつまらないアイデアに収束します。

独断の方の話は僕個人の能力の低さと弊団体の集団的知性の低さから来て
話し合いの方は弊団体の個々のレベルの低さから来ているのでしょう。
あるいは、そのどちらも両方が影響しているのでしょう。



と急に自団体批判に収束してしまいましたが、別に文句が書きたいわけではないです(最近そんな機会もないし)
結局問題そのものの難しさだけでなく、難しいポイントが個人や集団のレベルにまで話が広がってしまうというわけです。

話し合いは解決したい問題そのものだけでなく、意思決定の方法自体にも、さらに話し合いの外にも課題が山積みで、雪だるま式にどんどん問題が大きく膨れ上がっている、というのが考えた結論でした。

独断でも話し合いでも、意思決定のマネジメントをきちんと行って、
意思決定におけるフォロワーシップもきちんと養いたいです。


AD
こんばんは、フナコ氏です。
用事がひっきりなしに入っててスケジュール帳とToDoリストが真っ黒です。
最近は土日にも予定が入ることも多く、なかなかやることが片付きません。
自転車操業気味になんとか食いつないできたのでそろそろどっかで破綻しそう…。


土日に予定が入ると言っても遊んでいるわけではなく、例えば先日はUNISEC絡みで久々東京にお邪魔していました。
用事が終わってから某大学の方と
「プロジェクト管理者がシステムを管理するべきではある一方、実際にやるのは難しい」
という話をしていたせいか、最近はよくその話題について考えています。
今日はそんな話をダラダラと書くので、興味がある方はお付き合いいただければ幸いです。



まずプロジェクト管理者がシステムを管理すべきかどうかという点を調べてみました
情報処理推進機構の「組込みソフトウェア向け開発プロセスガイド」のプロジェクトマネジメントの頁によると
「開発対象およびそのシステム要求仕様を把握する。」「また組込みソフトウェアの開発の場合、ハードウェア開発との整合性などについても注意する。」
とあるので、システムを設計するかどうかは別として、システム要求を整理したり、機能の整合性を判断して管理する能力は求められるようです。

一般的に求められる能力であることはなんとなく分かりましたが、それがなぜ必要なのか、どうして学生団体でそれを行うのが難しいのか、と言ったことは流石に書いてないのでそこについて考えていました。
筆者の思う「プロジェクト管理者がシステムを管理」するべき理由、できない理由は以下です。

やるべき理由
「タスクを発見し最適に割り当てるためには、まず問題の性質を把握する必要がある」

できない理由
「現行のタスク管理だけでも手一杯」「経験がないから難しい」「ソフトウェアにも手を出す自信がない」
「システム全体を見始めるとプロジェクトが炎上した場合そのど真ん中に行くのが分かってしまって手が出せない」

これらに対する具体的な行動や解決策にまで考えを下すことができれば良かったのですが、そこまで思い至りませんでした。
なんとなく方針は思いつきますが、具体的な解決方法が思いつきません。
(方針についてもだらだらと書いてましたが、途中で執筆を断念)
まだ原因の分析が足りなさそうです。


現段階で思いつく長期的に見て役に立つアドバイスを挙げるとしたら「ソフトウェア開発やシステム開発の本を読もう」でした。管理者に限らず読んだ方が良いと思います。
大規模な組織や大規模なシステムの開発手法は役に立たない、と言い張る人もよく見かけますが、管理できないなら自分たちにとって「大規模」なシステムだと思います(私見です)
なので、視点や勘所くらいは真似てもいいんじゃないかなと思います。
本を読んだうえで「違う」と思う場合は「何故違うのか」をしっかり考えたら自分のチームが抱える状況を見直すきっかけになるので、そういう意味でもおススメです。

あと管理者はハードを含めたシステム全体から逃げても、開発環境を含めてソフトウェア開発から逃げないことは推したいです。
組織の体制づくりやルールづくりは集団に対するプログラミングです。
パソコンやマイコンへのプログラミングも組織でやるべきことの一部を機械に委ねているだけなので、自分の指示した情報がどのように伝達されていくのか末端まできちんと把握したほうがいいと思います。


ただこれも結局「~すべき」止まり…。「~すべき」で話が終わってしまうと役に立ちません。小学校のときにあった全校集会での校長先生の話と同じレベルです。
そもそも組込み開発でハードを無視してソフトだけ関わるってのができるかどうかと言われるとできない気はしますが、逃げないというスタンスは最低限取るべきだと思います。

具体的な解決策がないということは、現実的には「やらなくてもいいこと」に降格してしまうのかもしれません。
ただし、「やらなくてもやらなきゃいけないことがなくなるわけではない」です。
サッカーでゴールキーパー誰もやりたがらないからって、ゴールを守らなくていいわけじゃないですよね。
逃げる手段じゃなくて解決策をどうにか考えたいです。
AD
こんにちは!!今日は我がセンターのマスコットキャラクター"おぷー"について書いていきたいと思います.


上の画像がそのおぷーです.

おぷーは当センターの人工衛星1号機,『OPUSAT』のマスコットキャラクターとして誕生しました.
いまではOPUSATだけでなく,SSSRCを盛り上げるために日々活動を行ってもらっています.

例えば,TwitterやFacebookでSSSRCの宣伝を行ったり,何か催しがあるときにはおぷーにも参加してもらっています.良かったらフォローしてあげて下さい.
Twitter: @_opu_
Facebook: おぷー


おぷーにはいろいろなバリエーションが存在していて,すべてをおぷーと呼んでいいのかは僕にもわかりません.おぷーにはまだまだ謎が多いようです.









おぷーの当面の目標は「スーツの似合う男になること」だそうです.


今年の新歓でもスーツを着て新入生に勧誘したかったそうですが,断念したようです.
来年はスーツ姿のおぷーが見れるといいですね.



青島でした.
AD