オープンソースシステム科ブログ

日本電子専門学校「オープンソースシステム科」の最新情報を発信しています

2010年12月09日

カテゴリー: イベント

学科間コラボ! -技能五輪プロジェクト-


前回の予告どおり、他の学科にちょっかいを出したがる
オープンソースシステム科の2年生が、
その好奇心を最大限に生かしてWebデザイン科
見事な共同作業を成功させました。
そう、あの技能五輪プロジェクトです。


立役者は2年生のクラス委員、皆川敦紀君です!

P1010042_U_U.jpg


Q.まずはじめに、自己紹介をお願いします。

A.オープンソースシステム科2年の皆川です。
  高校卒業後は迂余曲折ありまして、
  この道に進む事を決断しました。現在23歳です。
  入学当初はITに関する知識はほぼ皆無だった為、
  この学科では全ての知識をゼロから
  (初実習でのLinuxインストールから)
  学ばせていただきました。

  現在は電設部というコミュニティで活動する中で、
  オープンソースプロジェクトとして
  SetucoCMSプロジェクトにも参加しています。
  あと、学科ではクラス委員をやっています。
  今回の技能五輪全国大会への参加は、
  電設部にお話をいただいた事がきっかけでした。


Q.技能五輪ってどんなものだか知っていましたか?
  昨年の先輩たちの活躍は知っていましたか?

A.技能五輪自体がどんな大会なのかは正直言って知りませんでしたが、
  Webデザイン科の学生が出場している
  「ウェブデザイン」部門の競技内容については知っていました。
  先輩達の実績については、学校のフロア内に
  デカデカとパネル&横断幕が飾られているので、
  学校に出入りするたびに技能五輪の文字を目にしますし、
  昨年かなり精力的に活動していた姿をいつも見ていました。


Q.今年なぜ技能五輪のサポートを志願したのですか?

A.色んな理由がありますが、一番大きな理由は電設部への恩返しです。
  昨年度は先輩達から様々なことを教えていただきましたが、
  受けることばかりで人に何か与える活動は出来ていませんでした。

  しかし、最上級生となった今年度は
  自分にとって在学中最後の年でもあり、
  なんとか電設部の財産となるような活動をしたいと考えていました。
  そんな中、元々”人に伝える”といった事に興味もあって、
  技能五輪プロジェクトへの参加を決断しました。
  実は、去年から興味があって「来年は五輪やりたい」なんて
  言ったりもしていました。


Q.当初Webデザイン科の学生に対してどのような
  印象を持っていましたか?

A.一番に出てくるのは真面目でメモ魔というイメージです。
  Webデザイン科の二年生については元々交友があったのですが、
  いつもメモ帳を持ち歩いていて学ぶ姿勢を全面に押し出しているので
  かなり熱い人達という印象を持っていました。


Q.技能五輪サポートプロジェクトははじめどのように
  スタートしたのですか?
  あまりメンバーがいなかったようですが。

A.スタートはよく覚えています。
  6月上旬の放課後のやりとりがきっかけで
  プロジェクトが立ち上がりました。
  N先生「皆川~最近はPHPどう?」
  皆川 「いや~やっと仲良くなってきました(苦笑)」
  N先生「技能五輪の話あるけど、どう?」
  皆川 「興味あります」

  こんな流れから、じゃあWebデザイン科の小山内先生に
  伝えておくから!ということで、気が付いたら決まっていました。
  実は当時PHPをはじめたばかりでHTML構文との融合に
  苦手意識もあった事から不安一杯だったのですが、
  先ほど挙げた電設部への恩返しという理由もあって、
  挑戦することにしました。

  立ち上げ当初は電設部の仲間でもある他学科の三年生(先輩)と
  二人でプロジェクトをスタートしました。
  その後、セミナーのサポートという形で同級生と、
  後輩がひとりずつ参加してくれました。

  しかし、一ヶ月が過ぎた7月頃から一緒に始めた仲間が
  プロジェクトに時間を割けない状態になってしまい、
  セミナーの資料作成や講師は自分一人でやるようになった
  時期もありました。


Q.プロジェクトの目的、目標とおおまかなスケジュールを
  教えて下さい。

A.大会本番では、ネット環境を利用出来ないため、
  課題に含まれるPHPの部分を選手たちが理解して
  自力でプログラミングしなければいけません。
  そこで、選手が課題に対応できるようにPHPを教えていく
  というのが今回のプロジェクトの使命であり、目的でした。

  スケジュールは、6月にプロジェクト立ち上げのお話をいただいた後、
  10月22日~25日にかけて開催される大会に向けて、
  5ヶ月間の間に夏期休暇も利用しながら
  合計8回のPHPセミナーを実施しました。

  P1000681_U.jpg


  具体的には7月に2回、8月は夏休み中に1回、
  9月に2回、10月に3回です。
  大会前日の10月21日からは会場の近くではられた
  四泊五日の選手団合宿に同行しました。

  目標としては、日本一になることと、
  去年の先輩達のチームと違う色を発揮することを
  当初から掲げていました。
  あとはやるからには選手だけではなく自分達の成長にも繋がるよう、
  効率追求だけでなくみんなで取り組めるように
  妥協せず努力するようにしていました。


Q.具体的にプロジェクトではどんな作業をしたのですか?
  進め方を先輩に訊いたりしましたか?

A.ウェブデザイン部門では大会の約1ヶ月前に
  一度課題が発表されるので、
  それ以降は課題の解説やつくり方を教えます。
  課題発表以前にはPHPを基礎から教えていました。

  約2週間おきにセミナーを行っていたので、
  まず講義内容を決めてから本番で使用する資料を作成します。
  具体的にはセミナー用のスライド、おさらい問題、
  演習問題や参考用のリファレンスマニュアル等の作成です。
  資料がある程度完成すると実際に本番を想定したリハーサルを行い、
  修正や変更を加えて本番に臨んでいました。
  リハーサルでは学科の後輩や同級生などに
  参加してもらったりもしました。

  P1000682_U.jpg


  セミナーは短くても3時間と長時間にわたるものだった事や、
  選手がセミナー後に自習する必要があったので、
  資料作りにはかなり注力しました。

  (参考)今年の第4回セミナーの資料(PDFファイル)


  先輩達にはかなりお世話になりました。
  昨年サポートで参加していた先輩や、
  実際に選手として出場していた先輩には
  大会への対策やプロジェクトとセミナーの
  運営に関することだけでなく、
  PHPの技術的な点でも色々とアドバイスをいただきました。
  また、昨年使用した完成度の高い資料を
  たくさん残してくれていたのでかなり参考になりました。


Q.初めて教えた時、Webデザイン科の学生に対する印象は
  変わりましたか?

A.真面目で熱いという点で根本的には変わりませんでしたが、
  こちらの考え方の甘さや準備不足等、
  至らなかった点に関して沢山ツッコミをもらい、
  彼らは誰の為に学んでいるかのをしっかり理解していると感じました。

  P1000678_U.jpg


  改善点を相手に伝えるのは多分気持ちのいいことではないと思いますが、
  それを相手に伝える事が自分の学びに繋がる事になるはずです。
  もし伝えずに放置した場合、
  恐らく相手の話に耳を傾けなくなるのではないかと思います。


Q.プロジェクトを進めていくうちにどんな変化がありましたか?
  メンバーも入れ替わったようですが。

A.先ほど触れたように、実際にプロジェクトが動き始めて
  1ヶ月が過ぎた頃に、一緒にはじめた仲間が
  徐々に参加できない状態になりました。
  そこで、それまで二人でセミナーの準備を行っていた仕事が
  倍になった事で精神的にかなり追い込まれた時期がありました。
  急激に忙しくなってきた事でプロジェクトへの参加を
  敬遠する人も増えましたが、
  その逆にサポートを申し出てくれた人達も出てきてくれたお陰で
  一番辛かった時期にチームが8人にまで膨らみました。
  大半はセミナーサポートのみという条件での参加でしたが、
  実際に参加して選手たちにも刺激を受けたようで
  忙しい中たくさんの時間を割いて一緒に参加してくれるようになりました。


Q.いちばん苦労したことはなんですか?

A.大きなトラブルこそありませんでしたが、
  初回のセミナー直後が一番苦労しました。
  自分自身PHPを始めてから日も浅かったこともあり、
  どのようにセミナーを運営するべきかわからないまま
  昨年の先輩達の資料を用いて初回のセミナーを実施しましたが、
  結果は散々なものでした。
  そこで、もっと自分らしいセミナーをやった方が良い、
  セミナーを通じて自分自身の成長に繋がらなければ意味が無い
  といった選手や先生のアドバイスを受けて
  今年のチーム独自のものを心がけるようになりました。
  独自路線に手応えを感じるころまでは不安しかなかったです。


Q.今年は大会直前に出題が発表されました。
  どんな印象を持ち、どのように問題に取り組んだのですか?

A.課題発表の時期が予想していた時期より1週間近く遅かったことで、
  短い時間の中で、どれくらい選手に習得させてあげられるかが
  一番の課題でした。
  課題内容がCMS制作ということで作りこみの幅が広かったのですが、
  求められている仕様を満たすといった点と、
  短期間でどの程度身につくかを重視して取り組みました。
  実装ポイントについては、作成した機能一覧表を元に
  選手個人との面談でそれぞれ対策を練りました。


Q.大会本番のことを教えて下さい。選手の宿泊先に
  同行したそうですね。どんな役割だったのですか?

A.我々のチームからは2名が選手団に同行しました。

  P1000689_U.jpg
  (選手団出発直前の壮行会で、Webデザイン科のサポーターから
   チームの証であるジグソーパズルのピース一片を受け取る。
   目標を達成した時には、全員のピースが組み合わされて
   一枚の絵が完成する。)


  宿泊先でも競技終了まではとにかく練習漬けだったので、
  これまでと同様に選手たちのPHPのサポートが僕らの役割でした。
  四泊五日だったのですが、食事なども含めて
  一日のうち20時間以上みんなと一緒に行動していたかと思います。
  過酷でしたが楽しく長い五日間でした。


Q.選手たちは大会期間中どんな様子でしたか?

A.みんなの前では普段どおり明るかったですね。
  それでも各々の部屋に戻ると極度の不安と緊張で
  眠れなかったりという事もあったようです。
  焦れば焦るほどPHPの内容が飛んでしまったり、
  寝ている状態でも意地だけでパソコンに向かう選手には
  寝るように説得したこともありました。
  あとは、会場への移動中も座って数分もしない内に
  みんなぐっすり寝てました。


Q.大会本番中、皆川君は緊張しましたか?
  特にプレゼンの前後はどうですか?

A.緊張はしませんでしたが、選手たちがエラーにはまっていないか
  不安でいっぱいでした。
  PHPへの不安などが普段通りの力を発揮する妨げにならないか
  など心配は絶えませんでしたが、
  選手が不安にならないような振る舞いを意識していました。

  プレゼンの時には制作部分の競技が終わっていたので、
  PHPサポートとして参加した自分の役割は終わったかと思いました。
  しかし、最終競技であり、Webデザイン科が重視しているプレゼンの
  直前練習チェックの際に小山内先生から選手一人を託された時は、
  PHPを教えるだけでなく五輪に挑むチームに参加できたんだという実感が
  こみ上げてきて、とても嬉しかったです。

  P1000726_U.jpg
  (10分後に始まる最終プレゼンに向けて、昼食会場で
   最後のプレゼンリハーサルを行なう出場選手)


  P1000729_U.jpg
  (いざ、プレゼン会場へ、チーム一丸となって)


Q.選手たちのプレゼンを見て、どう思いましたか?

A.選手たちも自信を持って臨んでいたと思いますが、
  始まってみるとみんな別人のようで圧倒されました。
  喋り方も声も時間も上手く使って
  良いプレゼンが出来ていたと思います。
  他の選手なども見ていましたが、
  説得力やインパクトが強いプレゼンは印象に残ります。
  全ての結果には根拠があって、
  それをいかに相手に納得させるかですよね。大変なことです。

  P1000763_U.jpg
  (金メダリスト、永井君のプレゼンの様子)


Q.結果発表の瞬間のことを教えて下さい。

A.ウェブデザイン部門の発表は20以上ある競技の
  最後から2番目だったこともあり
  かなり長い間緊張しっぱなしでした。
  会場の脇に表彰者が移動する為の席が別に用意されていて、
  ウェブデザイン部門には8席用意されていましたので
  金1,銀2,銅2,敢闘賞3かなと勝手に予想をしたりしていました。

  そして待ちに待った発表がはじまり、最初の敢闘賞は2名でした。
  その中に一年生の齊藤さんの名前があって、
  まわりから歓声が上がりました。
  次は銅賞なのですが、予想と反してこちらが3名でした。
  しかし我々のチームからの受賞者はいませんでした。
  自分を含めた周辺がどよめきました。
  残りは銀賞と金賞のふたつ。枠は3つです。
  祈るような気持ちで発表に食いついていました。
  銀賞が発表され、
  今年が学生最後の挑戦となる二年生の室津くんが受賞しました。
  残るは金賞の一枠。
  これは銀賞が発表された瞬間に名前が無かった事で
  みんなが確信を持ったことと思いますが、
  金賞は二年生の永井くんでした。
  大会連覇と同時に来年ロンドンで開催される世界大会への
  切符をゲットしたわけです。凄い。


Q.どんな気持ちでしたか?

A.悔しかったです。発表が終わってから悔しくて涙が溢れました。
  選手たちは半年間、5月から大会に向けて必死に練習を続けてきました。
  休暇中もです。
  きっと、自分自身でも競技に手応えもあって
  賞を信じていたに違いなかったと思います。
  長期間一緒にやってきて、受賞した選手も他の選手もサポーターも
  みんな同じ気持ちだったのではないかな、と思ってます。
  でも二年生がふたりとも受賞したことはとても嬉しかったです。


Q.プロジェクトを終えて、何を得ましたか?
  思い出してみてどんな感慨がありますか?

A.改めて思い返してみると、
  まずは大変だったなぁというのが一番に挙がってきますね。
  10月は殆んど寝る時間もなく、
  電車では毎日のように立ったまま崩れ落ちていました(笑)
  というのも、選手たちが泣きそうな顔しながら頑張ってる姿を思い出すと
  自分ももっと頑張らないとって思うんです。
  泣き顔こそみせないですけど、きっと家なんかでは大変だったはずです。

  一緒に戦ってきて、新しい仲間が増えたし、
  学科の同級生の色んな面も見られたし、
  他学科の下級生に先輩なんて呼ばれちゃったりして。

  たくさんの事を得ましたが、成長の機会は色々とあるかと思います。
  そういった意味では、Webデザイン科という文化に深く触れられた所が
  五輪独特な部分ではないのかなと思います。
  他文化の懐に入って学べる機会って多分そう多くはないですよね。
  彼らの学ぶことへの姿勢や考え方、取り組み方などを
  吸収させていただきました。

  20101124_06_s.jpg


Q.Webデザイン科の小山内先生に対して、
  どんな印象を持ちましたか?

A.Webデザイン科に持っていた印象そのものでした。
  エネルギーの塊で情に熱い人です。
  あと、生徒を追い込むというか、その気にさせるのがとても上手いです。
  勢い良く笑顔でお願いされた時には悩む隙すら与えさせません(笑)。
  五輪を通じて僕らの成長も考えてくれていたのかなと思います。
  とてもお世話になりました。


Q.今選手たちにメッセージを伝えるとすれば、
  どんな言葉が出てきますか?

A.技能五輪が終わってから1ヶ月が経とうとしていますが、
  立ち止まる事なく走り続けるバイタリティは本当に凄いです。
  今回の活動を通じてWebデザイン科から
  色んなことを学ばせていただきましたし、
  今後も制作だけではなく、様々な活動を通して
  たくさんの人に伝えていくことを期待しています!


Q.その他関係各方面に何か言いたいことがあればどうぞ。

A.今年の五輪プロジェクトに参加する機会を与えてくださった
  小山内先生とN先生をはじめとする教職員の方達や、
  昨年の活動を今年の電設部五輪プロジェクトに繋げてくれた先輩や仲間達、
  そして今年一緒に戦ったチームのみんなや
  活動を応援してくれた全ての方達に感謝します。
  みなさんのお陰で、素晴らしい活動をすることが出来ました。
  ありがとうございました。



皆川君、ありがとうございました。感動が伝わってきます。

でも驚くべきことに、成績発表の直後皆川君はなんと
悔し涙にくれていたのです!

選手の金メダル獲得の報せはすぐに学校にも伝わってきて、
こちらでは歓喜の声が上がっていたのに、
選手全員が入賞できる事を信じて疑わなかった皆川君は
その目標が達成できなくて、悔しくて泣いていたのです。

本当に選手のそばに寄り添ってサポートしてきた皆川君にとっては、
全員が入賞できなければ、それが敗北を意味するのです。

でも、入賞を逃した選手たちも、ともに歩んできたサポーターたちも、
入賞以外の何か大きなものを得たように思われます。
皆川君の言葉からそれを感じ取ることができます。
今回の技能五輪本番への歩みは、きっとみんなにとって
素晴らしい思い出になるに違いありません。

Webデザイン科の選手たちもお見事!
Webデザイン科のサポーターたちもお見事!
そしてオープンソースシステム科のサポーターたちもお見事!
みんなお疲れさま! そしておめでとう!

2010年11月19日

カテゴリー: 就職

みんなで仲良く!・・・できるのかなあ?
-プログラマとデザイナーの間に横たわるもの-


オープンソースシステム科の学生が卒業すると、
多くの学生が「Webシステム」に関わることになります。

業務処理システムのユーザインターフェースが
昔の専用端末からPCのWebブラウザに変わって行き、
その高い表現能力のために操作画面の設計も
複雑なものになっていきました。

その結果、システム開発をプログラマとWebデザイナーが
協力して開発するようになりました。

プログラマとWebデザイナーは手に手をとって
仲良く協力し合い、理想的な開発工程を経て
矢継ぎ早にWebシステムを完成していくのでした。
めでたしめでたし・・・

って、そんなにうまく行くわけない(笑)!

現実は厳しかったのです。両者の間には暗くて深い溝が
あったのです・・・


現場で活躍するプログラマにはエンジニアリング思考が
できる人が多く、問題にぶち当たると論理的思考の
持続によって壁を乗り越えようとします。

一方プロのデザイナーは直観力に優れ、問題に対して
表現能力を駆使してコミュニケーションの中から
解決への糸口を見つけることができます。

さあ、この両者が協働しようとするとどうなるか、
なんかお互いの能力を補完し合ってうまく行きそうに
思えるのですが・・・


◆プログラマ寄りのディレクターがデザイナーに指示をする

「今回入力項目が3つほど増えたから、
 その隙間にフォームを突っ込んどいて」

 ちょっとー、全体のバランスが悪くなるでしょ!
 画面レイアウト見直しだってば!


「そのボタン目立った方がいいから赤くしといて」

 おい! キーカラーに赤なんてねーよ!
 ボタンのデザインやり直しだよ!


「なんでそこ隙間なんか空いてるの? 明日までに
 ちょちょっとロゴでも作って差し込んどいて」

 雰囲気出すためにマージン取ったんだろ!
 ロゴがそんなちょちょっと作れるくらいなら、
 今頃おまえとなんか仕事してねーよ!

 
◆デザイナー寄りのディレクターがプログラマに指示をする

「ああ、ちょっともっさりしてますねえ。
 あと0.3秒早くして欲しいなあ」

 0.3秒ってどんな根拠なんだ?


「ここ、パスワード入れる必要ってあったっけ?
 ユーザがイライラしないかなあ?」

 じゃあどうやってセキュリティ守るの? 顧客情報さらすのか?
 そもそもセキュリティ要件最初に決まってるじゃん。


「おお、ほとんどオーケーだね、さすがぁ。でもさあ、
 ここさあ、なんかこうやって画面がグーッとか動かないの?
 グーグルマップみたいに。」

 今回の仕様のどこにAjaxの文字があるんだよ。
 要件定義からやるのかよ。お前とはやってられねえ。 


ちょっと極端でしたが、思わず笑ってしまう現場の方も
きっといるはずです。

実際には大規模開発ではフレームワークが導入されており、
画面デザインと内部処理の部分が切り離されて、
お互いの領域に侵犯できないようになっているようです。
そうなればあらかじめ決められたことしかやらなくて済むので、
上記のようなやり取りも行われないことになります。

ところが、上記の笑い話のような経験をしたことのある
開発者たちは、別のアプローチを取ろうとしました。
「自分は両方の気持ちをわかるようにしよう」

上記のやり取りは、お互いの仕事の内容や気持ちの揺れが
全く理解できないことから発生しているわけです。
ならばお互いの気持ちをわかるようにすれば良い、
そのためには自分が両方を少しずつでもいいから経験してみよう、
というわけです。

(脇道にそれますが、「プログラマ」を「プログラマー」と
 表記することはあまりありません。同様に「デザイナー」を
 「デザイナ」とはほとんど言わないのですが、
 この辺にも文化の違いが表れているようです。)


今活躍している人の中には両方の経験を持っている人が多くいます。
そんな人たちが作業の指示をする立場に立った時、
相手のことを考えて指示を出せるようになり、
プロジェクトの進行もスムーズになってきます。
そして何より両方できる人は2倍の仕事ができるわけですから、
大変良い条件で仕事を進めることができます。

でも2つの専門分野の技術を身に着けるのは
簡単なことではありません。
特に専門学校ではおおよそ2年間しか在学できないのですから、
お互いの分野のことを学ぼうと思っても時間が限られてしまいます。
実際のカリキュラムでも自分の専門外の科目については
ほとんど取り上げられません。

そんな中、日本電子専門学校ではエクステンション科目という
共通選択科目を放課後に受講することによって
専門外の勉強をすることもできるようになっていますが、
学生たちは他にも独自に工夫をして専門外の分野に
アクセスしようとしています。

オープンソースシステム科の学生の場合、
よその学科との交流がある(ちょっかいを出したがる)ので、
そんなチャンスにも恵まれるようになります。
昨年度は学科間コラボレーションの事例がありました。
今年度もそんな「他の専門分野の人と交流するぞ!」
チャンレンジがありました。つい最近です。
次回にその事例を取り上げてみましょう。

2010年11月05日

カテゴリー: イベント

おめでとう月間 -10月のビッグニュース-


先月(10月)は、オープンソースシステム科の学生にとって、
2つのうれしいニュースがありました。

ひとつめは、昨年度にオープンソースシステム科の
チューターを務めてくれた高度情報処理科OBの塚田朗弘君が、
2010年度日本OSS奨励賞を受賞したことです。

チューターの役割については、過去の記事をご覧いただくとして、
直接チューターにお世話になった昨年度の1年生、
つまり今年の2年生たちは、今回の塚田君の受賞を
わが事のように喜び、お祝いムードでいっぱいです。

塚田君の受賞理由を見ると、2年生たちが先輩に引っ張られて
一緒に活動したことが評価されていて、
これはもうみんなにとっておめでたい受賞だったのです。


DSC00470_U.jpg


DSC00492_U.jpg
藤江一正IPA理事長(左)と記念撮影する塚田君


塚田君のすごいところは、大きな賞を受賞しても
「去年関わっていただいた全ての方に心から感謝です。
全員で受賞した気持ちです」(本人のコメントより)
と語ってしまう謙虚なところ。
コミュニケーションの力で受賞しただけに
決して感謝の気持ちを忘れません。

でもなんといっても塚田君の積極性とライティング能力は
特筆すべき資質と言えます。

大御所の集う勉強会やパーティーにものおじせずどんどん出かけ、
自分にできることを次々に探し当てて後輩たちをその場に引きずり込む、
さらにすごい勢いで目にしたことを一気にテキストにまとめ情報発信を行う、
その蓄積によってさらに後からついてくるものがどんどん現れる。
塚田君パワーを中心としてコミュニティ発展のスパイラルが生まれました。

塚田君の初期の活動における珠玉の成果といえば、
TOMOYO Linux メインライン化記念勉強会 レポート
を挙げないわけにはいきません。
塚田君が電撃ショックを受けたかのように何かを感じ
スパイラルが始まったその瞬間に立ち会ったような臨場感が
そこにはあります。是非リンク部も含めてじっくりご堪能ください。

塚田君が愛して止まない電設部の後輩たちが、
いずれ先輩の独占インタビューをする予定です。
お楽しみに。


さて、ふたつめのうれしいニュースは、Webデザイン科の学生が
技能五輪全国大会ウェブデザイン部門で、金メダル、銀メダル、
敢闘賞を獲得したことです。

なぜWebデザイン科の学生の受賞なのにオープンソースシステム科で
盛り上がっているかというと、これも過去記事にヒントがあります。

そうです、今年もオープンソースシステム科の学生が
Webデザイン科の出場選手たちのシステム開発スキル向上のために
全面的にバックアップしたのです。

具体的にはプログラミング言語のPHP言語での開発技術を
まだWebデザイン科での授業を受けていない1年生を中心に
セミナーを通じて伝授したのです。
セミナーの内容についてはこちらの下の方で資料が公開されています。
今年もバッチリ公開しちゃいました。
手の内を見せてしまってもそんなことはお構いなしに
選手たちは堂々と優秀な成績を収めたのです。
資料をよく見てみると、大会中エラーであわてないための
細やかなアドバイスが載っています。
これを身に着ければ本番に安心して制作に集中できます。
この安心感が選手たちにもいい影響を与えたようです。
見事なサポーターぶりでした。

それにしてもWebデザイン科の選手たちの活躍は見事のひとこと。
昨年度金メダリストの永井君を始めとした毎年の活躍ぶりから
今年度も好成績を取って当然かのような恐ろしいプレッシャー。
さらにわずか1日半でCMSを作らなければならないという、
審査員いわく「私がこの条件で仕事を依頼されたら断る(笑)」
ほどの恐怖の制作課題。
Webデザイン科の選手たちはそんな困難にもめげず、
鉄板のチームワークと圧倒的なプレゼン能力を発揮して
見事優秀な成績を収めました。
金メダリストの永井君はついに来年ロンドンで行われる
技能五輪世界大会への切符を手に入れました。おめでとう!

そのWebデザイン科をサポートするオープンソースシステム科の
学生たちも、本番に向けて徐々にチームワークを固め、
Webデザイン科の学生との信頼関係を築き上げてきました。
その中心にいたのが2年生の皆川君、これまた近いうちに
彼に技能五輪の熱きドキュメンタリーを語っていただくことにしましょう。
これまたお楽しみに。

2010年10月31日

カテゴリー: 学習

オープンソースプロジェクトを立ち上げて見よう!
    -再び、リーダー登場!-


本日はSetucoCMSプロジェクトの熱血リーダー、
三上さんに2度目のインタビューを行いました。

前回熱く熱く語っていただいた三上リーダー、
プロジェクト始動から半年以上経って、
まだあの情熱は保たれているのでしょうか?
入社一年目で会社でも大変な時期に差し掛かるだけに、
ちょっと心配です。


問.まず、最近お元気ですか(笑)?


答.元気です!といいたいところですが、んーまあまあですね(笑)
  先月辺りは少し調子を崩していました。
  が、そんなときでもSetucoCMSプロジェクトのみんなが
  頑張ってる姿を見て元気をもらいました。
  心はとっても健康です!体は・・・運動不足です(笑)


問.プロジェクト発足後半年以上経っていますが、
  振り返ってみていかがですか?
  予想通りに進んでいますか?
  意外なことってありましたか?


答.半年以上・・・経ったんですねぇ。
  あっという間でした。楽しいことだらけです。
  開発のスケジュール自体は当初の予定からは大分遅れています。
  ですが、ここまでほぼ一定のモチベーションを
  保ってこれたのはすごいことだと思います。

  意外なことは、私が思っていた以上にみなさんが
  素晴らしい方々ばっかりってことですかね。
  浅い付き合いだとわからないけど、一緒に何かやればやるほど
  その人のいいところにたくさん出会えます。
  いつも驚いてばかりです、みんなすごいなって。
  あとは思ってたより、リリース前に周りに広まってきましたねー。


問.メンバーの多くが入社1年目とのことですが、
  みなさん会社は大変じゃないのでしょうか?
  もちろん三上さんもです(笑)。


答.先輩社会人2名
  新社会人6名
  学生5名

  おお、確かに多い。
  いやー大変ですね。
  半年たったところで、それぞれ仕事も慣れつつ、増えつつ、
  色んな事情を抱えつつですからね。


問.本業をそれぞれ持っているメンバーにとって
  SetucoCMSプロジェクトって、どんな存在なのでしょう?


答.私自身、会社の仕事に慣れてそちらも楽しくやらせてもらってますが、
  仕事が終わってから今度は仕事じゃないモノづくりができるって
  それはまた素敵です。

  学生だったころにはわからなかった感覚ですが、
  SetucoCMSやれて幸せです。
  だから、大変でももっともっとやりたくてしょうがないですね。
  休みの日にもみんな「もっとせつこやってたいー」
  とか言ってますから。

  みんなにとってそういう心の支えなのかなーって、
  そうだったらいいなーって思ってます。

  私にとってこのプロジェクトは
  人生かけて大事にしていきたいと思ってる
  相棒?子供?嫁(笑)のような存在です。
  ようは一生つきあっていきたいってことですね。


問.ところでリーダーの三上さんって、実はメンバーの中で
  かなり年下の方だって聞いたんですが、本当ですか?


答.そうですね!まだ若いですよ!ハタチですから。
  最近若いメンバーがまた新たに加わったので、
  12人中3番目の若さですかね。


問.年上のエンジニア軍団に囲まれて、ビビりませんか?


答.そうですねー・・・・・
  在学中も年上が多かったのですが、
  あまり年齢での上下がないクラス柄でしたので、
  特に気になりませんかね。
  年上だからっていうか、すっごいエンジニアたちに囲まれて
  正直ビビッてはいます(笑)


問.少しメンバーの入れ替わりもあったようですが、
  改めて三上さんから見たSetucoCMSプロジェクトのメンバーって
  どんな人たちですか?


答.いい人たちです、本当に。
  時々楽しんでくれてるのかな?とか続けてくれるのかな?とか
  不安になることがありますが、
  よくよく話してるとみんな本当に素直なんです。

  純粋に興味とか楽しいとかを
  エネルギーに変えていける人たちです。
  技術とか知識とか人柄とか体力?とか、
  常に感心することばかりです。

  でも、一番すごいのはやっぱり情熱なのかも。
  大人しくみえる人も、大人しく見えない人も(笑)、
  それぞれの「作りたい」気持ちがキラキラメラメラしてます。
  それがとってもとっても素敵で、
  一緒にモノづくりができることが本当に幸せですね。


問.プロジェクト管理を実際に体験してみて、
  学んだなあと思うことなどあれば是非教えて下さい。


答.プロジェクト管理ってスケジュール調整とかのイメージでしたけど、
  何より大事なのはやっぱり「人」なんだなって思いました。

  人をどう動かすか、その人をどう活かすかって難しいけど、
  プロジェクトをやっていく上で一番大事なことだと学びました。
  特に学校の課題でも会社の仕事でもない、
  つまり必然ではない制作をこなす上では。

  そのことをプロジェクトのみんなに教えられて、
  モノづくりの原点に立ち戻ったようです。
  大きな学びです。


問.今後しばらくするとSetucoCMSのファーストリリースに
  なると思いますが、うまく行きそうですか?


答.いきます。いかせます。
  開発バリバリできるメンバーが少数になってきて、
  厳しいところではありますが、
  お互い盛り立てながら頑張っています。
  必ず今年度中にはリリースします。


問.SetucoCMSの完成を待ち望んでいる人たちへひとこと。


答.まだまだつたない生まれたてのCMSですが、
  私も、メンバーも、SetucoCMSも応援してくれる皆さんと
  一緒に成長していきたいと思います。
  皆さんにとって楽しい・役に立つ、
  プロジェクト・CMSになれるよう頑張ります。
  よろしくお願いします!


問.電設部の後輩たちへひとこと。


答.最初は見てるだけでもいいので、
  ぜひもっと参加して欲しいです。
  学生のうちからこういったプロジェクトに参加することは
  とても勉強になると思います。
  就活を控えてる学生は就活にも役立つと思います。

  そんなことよりもOSSとっても楽しいから
  一緒に楽しいことしましょう。
  皆さんと一緒に制作がしたいです!


問.その他、熱く語りたいことがあれば是非!


答.このプロジェクトは私にとって
  「開発するだけのプロジェクト」ではなくて、
  「モノづくりの大切さを知る、楽しむ」
  プロジェクトとなっています。

  「オープンソースソフトウェアの世界では
  もともと苦労して開発した成果を独り占めせず共有しよう、
  という思想があります」という、N先生の言った
  この言葉に感動して、OSSの世界に踏み込みました。
  OSSだけじゃなくて、モノを作る人にとって
  大事な言葉であると思っています。

  フロントエンドに携わる私がバックエンドの開発から
  たくさんの学びを得たように、多くの人に
  この気持ちや想いを伝えていきたいです。
  ファーストリリースを終えたら、もっと積極的に
  外へも広がっていこうと思ってます。

  開発メンバーも増やしたいですし、
  開発じゃない多種多様なメンバーとも一緒にやりたいです。
  勉強会やイベントも開く予定です!
  告知用のサイトも制作スタートしたので続報にご期待を!


三上リーダー、ありがとうございました。
いやあ相変わらず熱いですねえ。
半年経って情熱が失われるどころか、
ますますものづくりへの情熱が燃えさかっているようです。

三上さんはメンバーの中で年下の方に位置する、
しかもプロジェクトリーダーです。
その三上さんがリーダーを務めるプロジェクトは、
さまざまな悪条件にもめげず、今のところ間違いなく
目標に向けて着実に歩み続けいています。

プロジェクトのリーダーに求められる資質を
もしひとつだけ挙げるとすれば、
豊富な経験でもないし、完成された人格でもないし、
ましてや海千山千、手練手管の単なる
コミュニケーション術でもありません。

なんと言っても、三上さんのように
「情熱を持続する力」こそが、
リーダーに求められるのだと思います。

プロジェクトを続けていると、いろんな障害に出会います。
自分の体調不良や忙しさなどから
自身のモチベーションが下がることもあるし、
メンバーの不調、メンバー間の衝突、外部との調整など、
多くの壁が立ちはだかっています。

その時に壁を突破するための原動力が、
「こんな楽しいプロジェクトを途中で放り出してたまるか!」
というひと踏ん張りなのです。

長く続けていればこそ得られる充実感というのが、
とてもたくさんあるはずです。
その充実を得られるのは、ピンチの時に踏ん張った人だけです。
三上リーダーはそのご褒美を得られる資格を持った人です。
そしてプロジェクトメンバーにそのご褒美を与えられる資格も持っています。

SetucoCMSプロジェクトのブログをのぞいてみると、
そんなリーダーへの感謝の気持ちが、
これまた熱い語りで展開されています。
http://design1.chu.jp/setucocms-pjt/?p=1245

メンバーたちも多くの障害を乗り越えながら、
熱いリーダーと一緒にプロジェクトを進めていたのですね。
ちょっと感動しました。


果たしてさらに半年後、このプロジェクトがどうなっているのか、
いよいよファーストリリースを控えて楽しみになってきました。
さらにさらにご期待ください!


つづく

2010年10月22日

カテゴリー: 学習

オープンソースプロジェクトを立ち上げて見よう!
   -母は見守ってます-


さて、前回に引き続き、SetucoCMSプロジェクトの進め方について、
同じ質問をこの欄でおなじみのみずき先輩にぶつけてみましょう。
プロジェクトの母の目線からは、また違った見方もあるかもしれません。


問.SetucoCMSプロジェクトを実施にするに当たって、
  開発プロセスをウォーターフォール型で行くのか、
  それともアジャイル型で行くのか、事前に
  話し合われたのですか?


み.話し合いました。
  でも単純にどちらでいくかということではなく、
  もっとざっくりどういうふうに
  開発を進めていこうかということから始まって、
  結局は基本的にウォーターフォールでもアジャイルでもなく
  ごちゃまぜでSetucoCMSらしくいこうということになりました。

  塚田さんは当時こんなことを言ってましたね。
   「実際のところ、まずウォーターフォール的に進めようとして、
    でもSkypeやMTGでけっこう密に相談しながら
    柔軟に手戻りしたりして、結果的にアジャイル的な要素が
    入ってくることになると予想」

  そして以前私がアジャイルとウォーターフォールについて
  まとめた文書があり、それをリーダーに読んでもらったら
   「どちらも一長一短。単に少数精鋭向け、大規模向けと
    考えるのではなく、 どちらの長所も短所も理解して、
    オリジナルの開発モデルがあっても
    良いのではないでしょうか。」
  という部分に共感していただけました。

  だからいろいろと名前付けされた開発プロセスがありますが、
  自分たちに合うようにそれぞれからいいとこ取りして、
  「コミュニケーション密にしてやっていきましょう」とか、
  「ドキュメントは必要なものだけ最小限にしましょう」とか、
  そういう1つ1つのスタンスが出来上がっていったのだと思います。


問.今までの開発経験では、どのようなプロセスを
  経験しましたか? またその経験でどのような
  手応えを感じましたか? 失敗談などもあれば
  是非お願いします。


み.ウォーターフォール系と、アジャイルの一種の
  スクラムというのをやったことがあります。

  ウォーターフォール系は設計がうまくできるなら
  楽な手法だと思います。
  自分はそのとき設計はしませんでしたが
  コーディングするとき詳細設計書を見ながら
  書いてあることをやるだけなので非常に楽です。

  でも楽だと感じるうちはいいのですが、
  設計が下手だと、設計書からしてバグだったとか
  不十分だったということがあって設計書の信頼性が無くなるので、
  結局コーディング中に設計を一から見直さなくてはならなくなります。
  そうならないように設計するには
  かなりの経験やスキルがいるのだろうと思います。

  その時に設計した上司ですら、
  100%の設計書を作るのは不可能と言っていたので、
  完璧な設計をしようとして時間をかけるより、
  ある程度で止めておいてコーディングに入ってから
  時間をかけた方が得策のような気がします。
  ある程度という度合いがきっと経験を積んで
  見極められるようになるのかなと思いますけど、
  自分は経験が無いので分かりません。

  スクラムでの経験の前にスクラムについて説明すると、
  2週間とか短い期間で段階的にリリースしていくのが特徴です。
  その短い1サイクルをスプリントと言って、
  各スプリントの最後には必ずレビューをして、
  個々やプロジェクトのKPTなどを整理します。
  さらに毎日短い時間で会議を開き、全員が昨日何をしたか、
  困っていることは何か、今日は何をするかを話します。

  私の経験談としては、そういうまだ珍しい手法を
  積極的に取り入れるプロジェクトマネージャの姿勢に
  まず驚いたと同時に勉強になりました。
  毎日全員の状況をみんなで把握できたり問題点を
  すぐに共有・解決できるのはとてもいいなと思いました。
  
  SetucoCMSプロジェクトでもそんな風にできたらと思うのですが、
  会う機会が少なく、メールやSkypeでも限界があるので
  難しいところです。


問.開発プロセスと言う観点からは、今回の
  SetucoCMSプロジェクトってどういう位置づけに
  なるのでしょうか。特徴として少人数、なかなか
  集まれない、同窓生、社会人1年目が多い、など
  かなり個性的です。


み.良く言えば柔軟。悪く言えば収拾がつかない。
  そんな感じでしょうか。

  リーダーはみんなの幸せを願っておられますので、
  好きなことややりたいことをできるときに
  楽しくやっていこうという心意気なんです。
  ですから自分がまず楽しくやるということと、
  メンバーそれぞれが楽しいと思えるような
  雰囲気作りとかタスク配分を心掛けたいです。

  開発スキルでいうと、みんなまだ駆け出しですから
  正直まだまだです。
  だから個人的には数年間は納得いくものができないと思っています。

  逆に言うと、自分もみんなも成長が待ち遠しいところで、
  メンバーの成長とともにシステムも成長していくと思うので、
  将来を楽しみにしています。


問.今回のプロジェクトの開発プロセスでは、
  「タスク管理」「コード管理」が重要に思える
  のですが、それぞれタスク管理ではRedmine、
  コード管理ではGitHubと言うツールを使い、
  それらを今回のプロジェクトに合わせて
  カスタマイズしているそうですね。その
  カスタマイズのポイントなどを是非教えて下さい。


み.タスク管理は最初にタスクのワークフローを定義しました。
  チケット(タスク)を誰が発行できるのか、
  作業が終わったらどうするか、チェックはするか、
  誰がするかなどを考えました。

  あとはチケットの分類分けが効率的にできるように模索しました。
  事によってはRedmineに項目を追加したり、
  分類ごとのチケット一覧が見られるように
  カスタムクエリというものを作りました。
  Redmineの機能を使って行うカスタマイズ以外に、
  チケット作成画面のソースをいじって
  楽に入力できるようにもしました。

  GitHubに関してはそのまま使ってるだけですが、
  強いて言えばGitHubを選んだこと自体が
  コード管理のカスタマイズですね。
  SourceForgeにもGitリポジトリが作れるのですが、
  学校からアクセスが制限されるので現役生のために
  学校からも開発ができようにと思ってGitHubを使っています。
  正確にはSourceForgeとGitHubの2段構成ですけどね。


問.ペアプログラミングってまだ現場ではあまり
  浸透していないようですけど、そのやり方、
  特徴、メリットなどはどんなところなのでしょうか。


み.やり方は二人で1つのモニター・キーボードを使って開発します。
  一人が書いて、一人が口出ししてって感じです。

  効果としては書くと同時に相方のレビューを受けるので、
  個人で書いたものよりもコードの質は高くなると思います。
  常に二人の頭から知恵を絞るので精度が上がります。

  さらに、もう一つ効果が高いなと思うのは集中力です。
  一人の時は気が散った時には思考停止したり、
  ブラウザで遊びに行ってしまったり、
  無駄な事してるのに気づかなかったりしますが、
  二人だとそういうことが一切無くなって
  あーだこーだ言いながらものすごく集中できます。
  もし脳科学者の茂木先生が知ったら
  「これは脳に非常に良い!」って言いそうです。
  そのおかげであっという間に時間が過ぎてどっと疲れるので、
  適宜休憩をおすすめします。


問.今回いろいろなメソッドを導入していますが、
  今のところどれくらいうまくまわっていると
  思いますか? 良い点、改善したい点などを
  お願いします。


み.タスク管理はとても良い体制だと思います。
  Redmineやタスクフローなどは一つ一つのルールを
  複雑になりすぎないようにも考慮して常時改良していってるので、
  この先テスト・リリースが終わるころには
  世に言いふらしたいくらい良いものが出来ていると思います。
  一方で遅れぎみのタスクや困っていることへの
  フォローがしやすい体制をもっと強化したいです。


問.今までの成果物(コードに限らず、各種ドキュメント
  を含む)で、公開してよいものがあったら、是非
  URLを教えて下さい。これから新たにプロジェクトを
  始めたい人がいるようです。
  

み.SourceForge.JPのプロジェクトwiki
  http://sourceforge.jp/projects/setucocms/wiki/FrontPage
  SetucoCMSプロジェクトのルールや技術情報(Gitなど)をまとめてあります。

  ブログ
  http://design1.chu.jp/setucocms-pjt/

  メーリングリスト
  http://lists.sourceforge.jp/mailman/listinfo/setucocms-public
  興味のある方は誰でも是非登録してみてください。


問.今後の開発プロセスにおいて、新たなメソッドの
  導入予定、野望などがあれば教えて下さい。
  個人的にはテストをどうするのかに興味があります。


み.やろうと思っていてまだちゃんとやってないのは
  単体テストツールのPHPUnitですね。
  導入コストを鑑みて次期リリースくらいから
  ちゃんとやりたいと思ってます。

  結合テストツールは今のところ予定はしていませんが、
  Seleniumとか行く行くは使っていきたいと考えています。

  開発プロセスはプロジェクトの様々な要因によって
  ベストな形が変わってくると思うので、
  現在はこんな状況だからこうしようっていうのを
  継続的にやっていって、常に、「今はこれがベストです」って
  なるようにしていきたいと思います。


みずき先輩、ありがとうございました。
年下のリーダー三上さんを心から尊敬しているのがうかがえて、
なんか素敵です。
みんなの成長を楽しみにしているあたり、さすが母です。
スクラムって面白い名前ですね。みんなで一緒にやって行くぞ、
っていう感じがしてやる気が湧いてきますね。

先週からお二方のお話しをうかがっていると、
どうやらペアプログラミングって、手っ取り早い
作業効率改善方法になりそうですね。
とりあえず2人いればすぐできるわけですし、
しかも効果がすぐに表れそうです。
学校の実習でやってみるのも面白そうですね。

タスク管理やソースコード管理は、プロジェクト進行において
非常に重要だということがわかります。
先回りしていろんな取り決めをしてきたメンバーたちは
みんなよほど勘が鋭いのでしょうか。
初めてのオープンソースプロジェクトとは思えません。

お二方が紹介してくれたリンクを見てみると、
新たにプロジェクトを始めるために必要なノウハウが
既にたくさん上がっていてびっくりします。
後輩たちがこれらを利用してまた新たなプロジェクトを
立ち上げていくと、先輩たちもきっと喜んでくれるでしょう。

おっと、その前にまだSetucoCMSプロジェクトでは
メンバー募集中でした。
これからやってみるならそっちが先ですね。
実際に現役学生の電設部メンバーも何人かこのプロジェクトに加わって、
先輩たちの圧倒的なパワーから何らかのエキスを吸入しているようです。
後輩たちの成長ぶりも楽しみですね。

2010年10月15日

カテゴリー: 学習

オープンソースプロジェクトを立ち上げて見よう!
   -祝・日本OSS奨励賞受賞!-


前回プロジェクトの開発プロセスには「ウォーターフォール」と
「アジャイル」という2つの手法があることをご紹介しました。
この欄でおなじみの「SetucoCMSプロジェクト」では、
どのような開発プロセスでプロジェクトを進めているのでしょうか?

本来オープンソースプロジェクトには終わりはなく、
一度システムが完成してもその後多くの人の手が加えられ
どんどん改良されていくその様子はアジャイル的に見えますが、
ほとんどのオープンソースプロジェクトでは
開発メンバーが各地に(世界に)散らばっているので、
いわゆるアジャイル的な手法は使いにくいはずです。

SetucoCMSプロジェクトは、まだ最初のリリースを行っていず、
結成後1年での初リリースまではメンバーが電設部関係者に限定され
(本当は限定するつもりはないのですが当面積極的な募集はせず)、
しかも大半のメンバーが社会人1年目という、特殊な形で
進められているオープンソースプロジェクトなのです。

そんなSetucoCMSプロジェクトでは、果敢に新しい試みに
チャレンジしています。アジャイルにだって興味津々です。

プロジェクト管理に大きな力を発揮しているメンバー数人に
ちょっといくつかの質問に答えていただきましょう。

まずはおなじみチューター(OB)塚田先輩

(緊急ニュースが入ってきました。塚田先輩が
 2010年度日本OSS奨励賞を受賞しました!
 おめでとうございます! 受賞理由のところに
 SetucoCMSプロジェクトの名前が!)


問.SetucoCMSプロジェクトを実施にするに当たって、
  開発プロセスをウォーターフォール型で行くのか、
  それともアジャイル型で行くのか、事前に
  話し合われたのですか?


塚.プロジェクトを進め始めるときに簡単に話し合いましたが、
  「基本的にウォーターフォールのようなフェーズの区切りを設定しながら、
  でもコミュニケーションをとって柔軟にやりましょう」
  という程度だったと思います。
  「柔軟にやりましょう」という点が既にアジャイル的なのかも知れませんが、
  タイムボックスとかイテレーションとかインクリメンタルとか、
  いわゆるアジャイル開発プロセス用語みたいな言葉を
  意識していたわけではありませんでした。


問.今までの開発経験では、どのようなプロセスを
  経験しましたか? またその経験でどのような
  手応えを感じましたか? 失敗談などもあれば
  是非お願いします。


塚.これまで、個人で半分趣味として開発しているものは除外するとして、
  ある程度まとまった単位で開発した経験といえば
  高度情報処理科2年次の実習で一人で開発するC/Sのシステム(1)、
  3年次にグループで行う卒業制作(2)、
  そして現在仕事で携わっている現場での開発(3)です。
  プロセスで分類するとすれば、
  (1)はウォーターフォール、
  (2)はプロトタイプモデル、
  (3)はウォーターフォールと言えます。
  手応えとしては、
  「開発未経験者だけで集まってウォーターフォールで
  分担して開発するのは無理」
  ということですね。たとえウォーターフォールでなくても
  未経験者しかいなければ開発を進めるのは難しいと思いますが、
  「各フェーズで漏れなく設計をしておいて原則として手戻りしない」
  ということを守るのは、一度ウォーターフォールで失敗して
  手戻りを経験した人でないと無理なのではないかと。

  業務で開発しているのは大規模な(開発者90〜110人くらい)
  金融システムですが、あれだけ大人数で、ウォーターフォール開発の
  ノウハウがある組織であれば、主に管理のしやすさといった面から
  ウォーターフォール型開発を取るメリットはあると思います。
  ただそれもプロジェクト全体としては、という話であって、
  プロジェクト内に数個存在する各チームや、
  チーム内での細かいタスクのやりくりについては、
  結局のところ日々発生する変化にチームリーダーや
  マネージャーを筆頭に対応している毎日ですし、
  個々のタスクをイテレーティブに回しては進捗確認して
  評価を行っていますし、つまりは
  「柔軟にうまいことやろうとすればアジャイル的アプローチが生まれる」
  ということなのかなと思ってます。

  と同時に、ウォーターフォールモデルの元になったW.W.ロイスの論文
  「Managing the Development of Large Software Systems」では、
  現在普及している典型的なウォーターフォールモデルとは違って
  反復的なアプローチもするべきと提唱しているそうなので、
  「実はウォーターフォールの元はけっこうアジャイルなんじゃないのか」
  と思ったりしてます。その辺ちゃんと論文読んでないので
  はっきり言えないのですが。


問.開発プロセスと言う観点からは、今回の
  SetucoCMSプロジェクトってどういう位置づけに
  なるのでしょうか。特徴として少人数、なかなか
  集まれない、同窓生、社会人1年目が多い、など
  かなり個性的です。


塚.今回の開発は、OSSプロジェクトと言ってもまだまだクローズドですし、
  目標として今年度中に第一リリースを行うことを優先しているので、
  全体としては個々のフェーズの区切りがはっきりした
  (≒ウォーターフォール的な)プロセスになっているところが
  あると思います。
  とはいえ、採用している開発技術(PHP、Zend Framework)の
  有識者も少ないですし、そんなにみんな作業の時間が取れなかったり、
  開発作業を進めながら仕様を詰めていくところがあったりで、
  結果としてアジャイル的なアプローチになっている部分が
  あるのではないかと。少人数ですし。こうしないと無理、みたいな。

  なかなか集まれないのは、痛いところではあります。
  やはり直接会って話しながら進めるのは、
  情報伝達の効率の面もありますが
  何よりモチベーションアップに直結するので。
  ただ、その辺は三上リーダーがエネルギッシュに
  マネジメントしてくれているので、
  みんなやっていけていると思います。

  個人的には、今後もっと電設部員含め開発者が増え、
  各所で柔軟にパッチが生み出されて
  メインリポジトリへのマージリクエストが送られてくるような、
  よりOSSらしい開発プロセスというのも取ってみたいなぁ、
  と妄想しています。


問.今回のプロジェクトの開発プロセスでは、
  「タスク管理」「コード管理」が重要に思える
  のですが、それぞれタスク管理ではRedmine、
  コード管理ではGitHubと言うツールを使い、
  それらを今回のプロジェクトに合わせて
  カスタマイズしているそうですね。その
  カスタマイズのポイントなどを是非教えて下さい。


塚.Redmineでは、ミーティングなどで相談して決めたタスク管理ルール
  (http://sourceforge.jp/projects/setucocms/wiki/ルール_タスク管理ルール
  が運用できるように、チケットに設定する項目の種類や、
  中身の値を増やしたり変更したりしています。
  例えば、Redmineのデフォルトでは
  「チェック担当者」という項目がないのですが、
  SetucoCMSプロジェクトでは一枚のチケットに
  複数人のチェック担当者を設定できるようにして、
  各タスクに関して、ふさわしい人が、複数人で相談しながら
  内容を精査して、チケットを完了にするようにしています。
  チケットの期日が過ぎても担当メンバーが多忙で
  対応できなかったりしていますが、その情報はRedmineによって
  いつでも適切なメンバー間で共有されているので、
  みんなでフォローをし合いながらやっています。

  GitHubは、カスタマイズというほどのことはしていないのですが、
  Collaboratorsという設定を使って、
  現在のプロジェクトの開発メンバーは全員、
  本番リポジトリに直接コミットを反映できるようにしています。
  これは第一リリースまでの運用で、
  その後より広く開発者が参加するようになれば、
  各自のGitHubリポジトリでSetucoCMSの開発を進めてもらって、
  何か追加機能を開発したら本番リポジトリに対して
  「Pull Request」を発行してもらい、
  本番リポジトリにコミットできる現行の開発メンバーたちが
  その内容をチェックしてマージする、というような、
  よりGitHubの機能を活用した流れになっていくのではと思っています。
  そうなったら、今いるSetucoCMSの開発メンバーはいわゆる
  「メンテナ」とか「コミッター」ですね。
  それと、GitHubではありませんが、Gitの利用方法に関するTipsを
  Wikiやブログにまとめ、メンバー内でバージョン管理のノウハウを
  共有しています
  (http://sourceforge.jp/projects/setucocms/wiki/Git_Git導入/操作まとめ)。


問.ペアプログラミングってまだ現場ではあまり
  浸透していないようですけど、そのやり方、
  特徴、メリットなどはどんなところなのでしょうか。


塚.やり方は、ふたりで一台のPCを使って、30分とか1時間交代で
  交互にプログラミングしていくというものですね。

  最近興味深く見ているページで、ペアプログラミング用語の
  和英辞典のようなものがあります
  (http://www.mightyverse.com/phrase_lists/pair-programing)。
  これを見ると、なんとなくどんな作業をするのか想像つきますね。
  (Can I drive for a bit? に関しては、
  Rubyのまつもとゆきひろ氏と高橋征義氏が
  「これはドライブじゃなくて『少し先に進めてもいい?』みたいな
  ニュアンスじゃないか」とどこかで話していた気がします。)

  ペアプログラミングの大きな利点は「プログラムの共有」だと思います。
  ソースコードは開発者個人のものではなく
  チームやプロジェクトのものなのに、
  うまく共有できていないと「俺はそこ知らないですから」とか
  「私のところ勝手に直さないで下さい」とか、不調和のもとになりがちで、
  それを解消する手段としてペアプログラミングは有効だと思っています。

  プログラマのモチベーションコントロールもできます。
  「一人で作業しているとついニコニコ動画を見ちゃって作業進まない」
  というような経験は誰にでもあるのではないかと思いますが、
  ペアで作業することでサボれなくなり、
  でも楽しいので心に負担がかかりません。
  やっぱりコミュニケーションは重要ですよね。

  それ以外にも、Wikipediaに色々と利点が列挙してありました。


問.今回いろいろなメソッドを導入していますが、
  今のところどれくらいうまくまわっていると
  思いますか? 良い点、改善したい点などを
  お願いします。


塚.あまり意識して「●○という手法でやろう」ということは
  していないのですが、導入、してるんですかね????
  どちらかというと、例えば「キャップ制
  (http://design1.chu.jp/setucocms-pjt/?p=1219)」とか、
  自分たちで決めた方法で進めるという感じでやっています。
  良い点としては、100%自分たちの意思で決めて進めていることなので、
  やりがいがある、楽しい/勉強になるということが大きいと思います。
  やりがいがあって楽しければ、プロジェクト全体のテンションが上がりますし。

  実際うまくまわっているかといえば、どうしても各人で時間が取れずに
  タスクが終わりきらなかったり、という点はありますが、
  決めたことはそれなりに守ってやれていると思います。
  やっぱりそこ(消化しきれないタスクがあること)が
  現在の一番大きな問題だと思いますが、それは改善点というよりは、
  第一リリースまではスケジュール、先に進めることを優先するという
  優先順位に従ってタスクの期日等を設定していることの結果なので、
  その後のフォローを頑張ってやっていくのみかな、というところです。

  あとは、どうにかしてもう少しメンバー間で
  直接コミュニケーションを取る時間を増やしたいですねー。
  毎週○曜日の19時から2時間はルノアールで何かをする
  「Setuco.Cafe」をやってみようかな、と最近すこし思ってます。
  来たい人は来る、みたいな。。


問.今までの成果物(コードに限らず、各種ドキュメント
  を含む)で、公開してよいものがあったら、是非
  URLを教えて下さい。これから新たにプロジェクトを
  始めたい人がいるようです。
  

塚.プロジェクトを始めたいというと、何か立ち上げようと
  している人がいるんでしょうか。素晴らしいですね。

  ◆プロジェクトのブログ
  http://design1.chu.jp/setucocms-pjt/
  ◆ソースコード
  http://github.com/densetubu/SetucoCMS
  ◆プロジェクトの拠点
  http://sourceforge.jp/projects/setucocms/
  ◆情報共有用のWiki
  http://sourceforge.jp/projects/setucocms/wiki/FrontPage
  ◆誰でも入れるメーリングリスト
  http://sourceforge.jp/projects/setucocms/lists/archive/public/

  上記以外にも、設計書類をGoogleドキュメントで共有しているのですが、
  それは今のところメンバー限定になっています。
  ただ、Googleドキュメントも公開しちゃっていいよね、みたいな声が
  三上リーダーからあがっているので、近々公開できるような気がします。


問.今後の開発プロセスにおいて、新たなメソッドの
  導入予定、野望などがあれば教えて下さい。


塚.上述しちゃいましたが、第一リリース完了後、
  ゆくゆくはもう少しOSSらしい形態を取れたら、
  より広まりやすいし参加しやすい、面白いプロジェクトになると
  思っています。

  テストについては、今回は、mitchangという
  心強いQA(品質保証)担当が居るので、彼が舵を取ってくれています。
  今後の予定というか野望ですが、
  Zend FrameworkにPHPUnitが組み込まれているので、
  ぜひテストコードを内蔵して、仕様をテストコードに
  反映しておきたいところです。
  さらに妄想としては、Gitの機能と連携して、
  テストにパスしないとコミットを却下するとか
  やろうと思えばできるはずなので、やってみたいですねー。

  それにやはりドキュメントの充実化です。
  ドキュメントキャップの高橋氏を筆頭にして、
  SetucoCMS利用者/開発者双方の役に立つドキュメントを
  作っていきたいです。
  OSSとしてドキュメントがしっかりしているというのは大きな魅力ですよね。
  国際化も考えていきたいです。とりあえず私は英語を勉強します。

  そんなSetucoCMSをみなさんよろしくお願いします。
  (今だったらプロジェクト立ち上げメンバーになれるよ!)



塚田先輩、ありがとうございました!
さすが日本OSS奨励賞を受賞するだけあって、
十分な調査をした上でツールを導入し、
さらにそれらを積極的にカスタマイズして、
しかも楽しさを忘れずにプロジェクトを進めているのですね。
勉強になります!

今後のさらなるメンバー拡大、ドキュメント公開、
そしてもちろんファーストリリース、そして国際化を期待してます!


さて次回は同じ質問をSetucoCMSの母、
いつもプロジェクト進行を気にかけてくれている
みずき先輩にもしてみましたので、そのお答えを
聞いてみることにしましょう。


つづく

2010年10月08日

カテゴリー: 学習

プロジェクトの進め方 -すばしっこさがウリです-


■2つの開発プロセス

一定規模のITシステムを開発しようとすると、
当然行き当たりばったりではうまくいきません。
プロジェクトとなると何人かのメンバーで開発するわけで、
当然首尾一貫した手順、ルールといったものが必要です。

ITシステムの開発プロセスでは、大きく分けて
2種類の考え方があるようです。
「ウォーターフォール」と「アジャイル」です。


■ウォーターフォールモデル

「ウォータフォール」とは滝のことで、
滝は必ず上から下へ流れます。逆流はありません。

ウォーターフォール開発ではまず要件を固めて
設計書を書き、プログラムを書いたら
単体テストの後に結合テスト、
というように全体の流れを重視します。
それぞれの段階で成果物を慎重にチェックしてから
次の段階に進んでいきます。
つまり来た道を戻らなくて済むように気をつけながら
進んでいくわけです。

滝の場合は上から下ですが、ウォーターフォールモデル
による開発では、よくシステムを建築物に例えるようです。
つまり強度の設計をきちんと行い、基礎を固め、
下層から上層へと積み上げていくわけで、
滝とは上下反対ですね。

この場合10階まで作った段階で基礎工事の欠陥が
見つかったりしたら大変です。上から全部壊して
やり直すなんて、大変な損失になってしまいます。
なのでそうならないように各段階のチェックを
慎重に行うはずです。このあたりがノウハウが
システム開発にも当てはまるのですね。


■現実の問題

さてこの欄で触れてきた「プロジェクト炎上」では、
このウォーターフォールモデルが破綻している
場合がかなりあるようです。
例えば初期段階で慎重に要件を固めたはずなのに
かなりプロジェクトが進んだ時点でそこに後から
大きな変更が生じてしまう、という事が
よく起きるかららしいのです。
これでは完成間近のビルを上から壊していって
基礎からやり直さなければならないのと同じで、
プロジェクトの「大炎上」ですね。

建築物なら基礎が間違っているなんて
有り得ないのでしょうが、ITシステムでは
よく起きるようです。
この原因は大きく2つあって、ひとつは今まで
お話しして来たとおり、要件を固める段階で
コミュニケーションがうまくいってなくて
実は要件固まっていなかった、という点と、
もうひとつはITシステムの賞味期限が非常に短い、
建築物なら一度建てたら数十年は価値がありますが
ITシステムはすぐに陳腐化する、長期プロジェクトの
完成を待っている間に環境が変わって、
システムに求められる要件も変わってきてしまう、
という点が挙げられます。特にWebシステムの陳腐化は
あっという間にやってきてしまいます。

ひとつめのコミュニケーションの問題は、伊本さんのような
スーパープロマネがたくさん登場することに期待するとして、
もうひとつの問題、ITシステムの賞味期限の問題は
他の業界に比べてかなりシビアな問題といえます。

現在Webシステムの構築では、規模にもよりますが
納期が3ヶ月などというものも多く、どんなに長くても
1年以内でシステム全体を作り上げなければならなくて、
かつてのメインフレームのシステムのように数年にわたる
プロジェクトというのはまず有り得ません。

このWebシステムのような短期プロジェクトでは、
建築物の考え方ではうまく行きません。
まずは非常に短い期間でとりあえず画面を作って動かしてみて、
そこにまた短納期で少しずつ機能を追加していき、
そのサイクルを何回も繰り返していくというやり方が
どうやら効果的らしいのです。


■アジャイルの登場

このように非常に短いサイクルを繰り返して
完成に近づけていくやり方を「アジャイル開発」
と言います。アジャイルとは「機敏な」「いきいきとした」
「すばしっこい」という意味を持った言葉です。

アジャイルの強みは変更に強い、ということです。
アジャイル開発では、比較的少ない人数で、
頻繁に顔を合わせながら進捗や問題点を全員で共有し、
現実に動くシステムを柔軟に組み上げていきます。
まさに激動の時代のシステム開発にピッタリです。

もちろんアジャイルにも弱点があって、
あまり仕様書や設計書を残さない傾向があるので、
大規模開発や長期プロジェクトには向かない、とも
言われています。要は適材適所なのですね。

ちなみにアジャイルのような短期の開発プロセスを
繰り返す手法では、ソフトウェア制作を建築業に
たとえるのではなく、造園業にたとえるべきだ、
と言われています。
(本当は逆で、造園業にたとえると短期プロセスを
 繰り返すことになる、ということです。)
これについては日本語では村上雅章さんの
すばらしい文章があるのでご紹介しておきます。

「変わりつつあるソフトウェア開発の価値観」
http://web.me.com/masaaki.murakami/sites/SoftwareDevelopment/twentyfirstcentury.html

(もう5年も前の文章なのですね。)


■SetucoCMSプロジェクトでは・・・

さてここでSetucoCMSプロジェクトの登場です。
このプロジェクトではアジャイル開発のキーワードが
頻繁に出てくるようです。

まだプロジェクトメンバーの就職先では、
そんなにアジャイルが浸透しているわけでもなく、
当然メンバーも経験がないはずなのですが、
どうやらこのアジャイルに興味津々のようです。

どのようにメンバーがアジャイルに取り組んでいるのか、
次回に確かめてみることにしましょう。


つづく

2010年10月01日

カテゴリー: 学習

プロマネの営業力? -ピンチの後にはチャンスあり-


今回はプロジェクトの開発プロセスについて
お話しする予定でしたが、
ちょっと寄り道してプロジェクトマネージャーと
営業のお話をしてみましょう。


実は「伝説の火消し人」伊本さんが、
ちょうどプロジェクトが大爆発した頃の後日談を
教えてくださったのです。
そこにはお客様の驚くべき態度の変化が見られます。

火消しの現場ではお客様の罵声が飛び交う
殺伐とした光景も見られますが、
その時のサポートのしかたひとつで
光景がガラッと変わってしまうのです。
火消しの大好きなエンジニアが存在する理由も
ちょっとだけわかった気になります。


■大爆発の直後に・・・

以前にこの欄でご紹介しましたが、
伊本さんが火消しをした中で最大級のプロジェクト大爆発は、
大手プロバイダの数万人の顧客データが消えてしまい
担当プロジェクトマネージャーも「消えて」しまった事件でした。

伊本さんが代わりのリーダーに任命され
最初にお客様のところに謝りに行った時、
伊本さんは意外なお客様の視線を感じたそうです。

もちろんお客様はカンカンです。数億かけたシステムの
不具合で会社の信用がガタ落ちしかけていたわけです。
罵声が飛び交って当然です。
でもお客様は明らかに怒りながらも伊本さんにに対して
ある種の「期待」の視線を投げかけていたのです。

当時はIT案件がたくさんあり、お客様もこのトラブルが
収拾したらすぐに取り掛からなければならない案件を
たくさん抱えています。いかにもトラブルを解決して
くれそうな頼もしい伊本さんに対して期待の目を向けるのも
当然だったのかも知れません。

そこで伊本さんは今回のトラブル対策作業の説明ついでに、
あろう事か翌年度の予算確保について談判したのでした。
「次年度はこれだけの予算を確保しておいてください
 そうすれば次期システムを構築することができます。」

プロジェクト炎上の真っ最中に営業活動! 大胆不敵です。
でもそれは伊本さんの深いシステム理解力がなせる業です。
伊本さんはちょっとした規模のWebシステムならば
フレームワークを駆使して
「仕様さえ決まれば1日か2日で完成させる」
のが当然と言ってのける豪腕エンジニアなのです。
「人間が考えられることは全てシステムで実現できる」
と心の底から思っているのは、本当に実現してきた
多くの実績があるからです。

そんな伊本さんが火消しに現れれば、カンカンに怒っている
お客様も態度が変わってくるというものです。
大爆発が起きたその翌年、同じお客様からの売り上げは
倍(!)になったそうです。

伊本さんはおっしゃいます。
「大規模の炎上はある意味チャンスなんです。
 謝りに行った時、向こうの偉い人が出てくるから。」
確かにそうですが・・・
ピンチの後にチャンスあり、なんですね。

「向こうの偉い人」というのは要するに
お客様企業の中で次期予算執行権限を持っている方です。
その人の信頼を得られれば確かに絶好の営業チャンスと
なります。でもよほどの自信がなければ修羅場の最中に
営業トークを切り出せないでしょう。

提案をしてみたらお客様は、
「前の方はどんなシステム要求を出しても『できない』
 としか言わなかったんですよ。」
と苦情をおっしゃったそうです。せっかくのチャンスを
誰も知らないうちにたくさん逃していたわけです。
伊本さんはそこを逃さずすぐに予算確保を切り出して、
大幅な売り上げ増につなげたわけです。

ある意味では幸運もあったのかもしれません。
でもお客様の期待の視線を見逃さなかった伊本さんの
コミュニケーション能力が、幸運を実際の利益に
つなげていったことは間違いありません。


■これからこの業界に入っていく人たちへ。

伊本さんは、最近この業界に入った若手が
「システムインテグレート」部門と「サポート」部門で、
サポート部門に配属されることを嫌う傾向にあることを
残念がっています。

中には「ああ、サポートに回された、サポートに来た時点で
俺のキャリアは終わりだ。」と嘆く若手もいるそうです。

でも伊本さんによれば、
「サポートの現場はトラブルシューティングの宝庫」
だとのことです。そのトラブル収拾の体験が、
上流のシステムインテグレーションに生かされるのです。

確かにお客様から電話がかかってくる時は、
たいてい「困っている、すぐ来てくれ!」
というせっぱ詰まった状態ですから、
こちらもプレッシャーを受けるわけで
若手にとってはすぐに「3K」職場というイメージが
浮かんでくるかも知れません。

でもそのトラブルを解決する過程で様々なレベル
(レイヤー)の知識を要求され、場合によっては
非常に深いシステムの知識を身に付けられる
絶好のチャンスともなるのです。
もちろん素早くサポートが完了すれば、
お客様からも厚い信頼を得ることができます。
今時お客様で「コンピュータシステムの不具合なんか
1秒たりとも許さん」などという方も少ないでしょう。
重要なのはトラブルが起きた時どう対処するか、なのです。
そしてそのピンチの時にどう振舞ったかが、
本当のお客様との信頼関係につながっていくはずです。

サポートが嫌われるからローテーションするのではなく、
サポート部門のモチベーションを上げることが重要だ、
と伊本さんは熱くおっしゃっています。

そう言えば前回お世話になった櫻井さんも、
「お客様の中に入り込んで、現場で一緒に仕事をする
 コンサルである」事を誇りにしてらっしゃいました。

システムは会議室で動くのではなく現場で動く、のですね。
良いシステムを作るためには、お客様と一緒に現場で
トラブル対処をしていく経験は欠かせないでしょう。


さあ、オープンソースシステム科の現役学生、
及び卒業生の若手エンジニアたちにも、率先して
火消しの現場に飛び込んでいってもらいましょう。
いざ行かん、トラブルの最前線へ!

え? 火だるまになって燃え尽きそう?
うーん、やけどに効くのはiPhoneアプリ開発、かな?
なに? やってみたらやけどが余計悪化した?!

2010年09月17日

カテゴリー: 学習

プロジェクトのかたち -プロジェクトの原料は?-


前回はプロジェクトマネージャーに必要なスキルとして
「妄想力」(!)というのを教えていただきました。
面白かったですね。櫻井さん、ありがとうございました。
わかりやすい表現でとっても参考になりました。


さて、今回はプロジェクトそのものについて
ちょっと考えてみましょう。


■プロジェクトに必要なもの

プロジェクトというのは別にITシステムに限らず、
どんな分野にでも使われる言葉ですね。
例えば「技能五輪金メダル獲得プロジェクト!
なんていうのも考えられます。
五輪に勝つために、大会で要求されるスキルを身に着け、
本番でも確実の能力を発揮できるように、
選手、監督、サポーターたちが一丸となって
一定期間目標に向かって突き進むわけです。
そう、プロジェクトには「期間」と「目標」が必須なのです。
(ちなみに技能五輪、今年は今まさにプロジェクトが
 佳境に入っているところです!)

一定期間といっても、スポーツの五輪のように
4年単位の長期プロジェクトもありますが、
うまく動いているプロジェクトというのはたいてい
長い期間をいくつかに区切って、短期または
中期の目標を段階的に設定しているものと思われます。
いずれにせよわかりやすい期間と目標が
プロジェクトには欠かせません。

2つの要素のうちもし「期間」だけあって「目標」がなければ
何のためにメンバーが集まったのかわからなくなり、
すぐにプロジェクトは迷走を始めるでしょう。

もし「目標」があっても「期間」がなければ、
踏ん張りの効かない漫然としたプロジェクト進行になり、
なかなか成果が上がらなくなるでしょう。

ところでこの「期間」と「目標」の2つはプロジェクトにとって
必須であるにもかかわらず、実は意外とあやふやな
存在だったりするのです。

大事な柱があやふやになればやはりプロジェクトは危機に陥ります。
でも変化の激しい現代にあっては、「目標」すらあっという間に
変化してしまう、変更せざるを得ない場合があります。
「金メダル獲得」のように確固たる目標を、長期間にわたって
掲げ続けるのは、今の時代にあっては難しいことなのです。
でも逆にこれら「目標」や「期間」をこちら側が
自律的にコントロールできれば、難しいプロジェクトを
うまく回すことができるかも知れないのです。


■卒業制作プロジェクト

日本電子専門学校では来週から後期授業が開始されます。
オープンソースシステム科では2年生後期に卒業制作を行います。
いよいよです。2年生にとって一大イベントです。
約半年かけて3~4人のグループでひとつのシステムを完成すべく、
力を合わせて制作作業にまい進するのです。

今年の2年生は非常にこころざしが高く(?)、
9月下旬から始まる卒業制作のチーム決めを、
担任のN先生にお願いして4月(!)にしてもらいました。
ほぼクラス全員の要望だったのです。なんかすごいです。
半年も前からチームワークを醸成しようとしたのでしょうか。
夏休み中もチームで合宿を組んだり、
学校に集まってミーティングをしたり、
とにかく制作に入る前にできることはなるべくやっておこうという
熱い想いが伝わってきました。
となれば後期の授業スタートが待ち遠しかったはずです。
どんなシステムができあがるのか今からとても楽しみです。

さて上述の「期間」と「目標」について、卒業制作では
「期間」はこれはもうはっきり決まっています。
来年2月には完璧に動くシステムを完璧にプレゼンする、
これはもう確定です。変更はありません。

もうひとつの「目標」ですが、各班が独自に設定することが
できるにもかかわらず、これが意外に定まらないのです。
もちろんいったん設定したシステム完成予想図は
常にメンバーの手元にあるはずなのですが、
チームで作業しているうちにいろんな事が起こります。

しょっちゅうあるのが、作業遅れによる機能縮小。
遅れの原因は作業時間の見積もりの甘さ、風呂敷の広げすぎ(笑)、
メンバー間のいざこざ、リーダーがストレスのため一時的現実逃避(笑)、
意外な障壁が新作ゲーム発売日(苦笑)、学生の性(さが)でしょうか。

こういった遅れによって当初描いていたシステム完成予想図が
規模の縮小を余儀なくされます。つまり「目標」の変更です。

もうひとつ、エンジニアにありがちなのですが、
システムの完成そのものよりも、開発技術そのものに
興味を強く持つようになり、メンバーみんなで開発環境整備に
熱中するパターンが表れてきます。

この業界には「インストールマニア」という、
ちょっと素人さんには理解しがたい人種が存在します。
メンバーみんなでOSや開発環境のインストールに
まい進してしまうと、もちろんシステムの完成ははるか彼方へ。
「あのディストリビューション入れちゃったよ!」
「××××ツールが動いているんだぜ!見て見て!」
システムの完成度がどんなに低くても、
メンバーはなぜか妙な達成感。「目標」そのものが
すっかりすり替わってしまいました。

これらの目標変更は、単にメンバーの都合で身勝手なものです。
もちろんツール周りの豊富な知識は就職後別の場面で
大いに役立ちます。インストールマニアたちはもちろん
ITの現場で大活躍しています(笑)。ですがこの変更は
前述の「目標」の自律的なコントロールとは違います。
卒業制作ではこのパターンにはまるとほぼ失敗と言えます。
どうやら今年の2年生はそれを良く知っているみたいです。
半年も前からメンバー間のコミュニケーションを図るのは、
そのパターンから逃れるためなのかも知れません。


■人生最長のプロジェクト

さてここでちょっと脱線です。「期間」を考えてみると、
人生最長のプロジェクトって何でしょうか?
人生そのものがプロジェクトだ、っていう考え方も
ありますが、人間は生まれてすぐはプロジェクトを
意識できませんよね。

ほんの10年くらい前までは、ほとんどの(主に)男性が
学校を卒業して就職する際に、人生最長のプロジェクトを
意識したはずです。

それは、企業内での「立身出世」プロジェクト、です。

20代後半で係長になり、30代半ばで課長になり、
40代のうちに部長になり、あわよくば定年前に
役員まで登りつめる、30数年に渡る壮大なプロジェクトです。
多くの男性が「期間」と「目標」を明確にして
プロジェクトに取り組んでいたはずです。
これは言うまでもなく、「年功序列」「終身雇用」の
企業人事制度を前提としたプロジェクトです。
一見プロジェクトメンバーが存在しないように見えますが、
実際には自分の出世のために上司、同僚、家族など
周りの人たちも協力してくれたはずです。

さて、今はどうでしょう。まず「終身雇用」がすっかり
影を潜めてしまった今、そんな長期のプロジェクトは
存在し得なくなっています。
さらに企業形態そのものが大きく変化しているようです。
つまり「会社に通う」、「会社に勤める」という
スタイルが大きく変化しようとしており、ますます
企業生活を長期間で捉えるのがむずかしくなってきます。

先日米国調査会社ガートナーが10年後の労働環境を予測した
面白い記事がWebにアップされました。是非ご覧下さい。
ガートナーが予測する2020年の労働環境

その記事によると、10年後には

「各人はそれぞれの能力に応じ、離合集散して仕事をする社会に」

なるだろうとのことです。
変化するビジネスニーズに対応するために、

「寄り集まって働く機会が増え、単独で働く人の割合は減るだろう。
 ほとんど顔も知らない相手とともに仕事をし、
 チームには企業と雇用関係のない人々が含まれるようになる」

という予想を読むと、まさに会社形態そのものが変わっていく
という印象を受けます。人によっては不安になるかも知れません。
立身出世プロジェクトの考え方はまったく通用しそうにありません。

でもよく考えてみると、様々な立場の人たちが離散集合し
一定の期間共に仕事をするスタイルになるのなら、
それはまさにプロジェクトの繰り返しということになります。
つまり今のうちから期間と目標を定めてプロジェクトを
うまく回すことができるスキルを身につけておけば、
将来の会社形態の変化にも適応していけるのでは?
という気がします。

短い期間のプロジェクトの繰り返しの中では、
「期間」と「目標」の自律的コントロールが重要になります。
次回はITシステム開発プロジェクトの現場で用いられる
開発プロセスについて見て行きたいと思います。


■今週のおまけ

「東京ゲームショウ2010」を見に、幕張まで行ってビックリ!
会場最寄り駅の海浜幕張駅のエスカレーターに謎のポスター。

「タイトルの乱開発からプロジェクトマネージャーを守りたい」

なんてデカデカと書いてありました。
ゲームショウの日にこんなの見るとドキッとします。
仕掛け人はカプコンさん。
海浜幕張駅に展示されている「ゲームクリエーターの剥製」とは?【TGS 2010】
(日経トレンディネットより)

そういえばゲーム開発のプロジェクトマネージャーは、
最も過酷な現場のプロマネと言えるかもしれません。
ゲームの世界でもプロマネに元気になって欲しいですね。

ちなみに東京ゲームショウ2010では、
もちろん日本電子ゲーム関連学科の展示も行われていました!
日本電子の学生大活躍です。その模様はゲーム系学科の
学科ブログを是非ご覧ください。

ゲーム制作科
ゲーム制作研究科
ゲーム企画科

個人的にはiPadゲームの学生作品が超お気に入りです。
App Storeに出したらどれくらい売れるかなあ?

2010年09月11日

カテゴリー: 学習

プロジェクトをスムーズに進めるキモは? -続・先生、教えてください!-


前回はコンサルタント会社にお勤めの、元日本電子教員
櫻井さんのインタビュー前半をお届けしました。

後半の今回は、いよいよ櫻井さんの経験から得られた
「プロジェクトをスムーズに進めるキモ」を教えていただけそうです。


Q.火消しの経験もある櫻井先生にとって、
  「プロジェクトがなぜ動かないのか」に対するお答えは?

A.それはプロジェクトマネージャーがマネジメントの仕事に
  専念していないからでしょうね。

Q.マネジメント以外の仕事をしてしまう?

A.はい、本来ならプロマネは管理の仕事に専念すべきですが、
  多くのプロマネはマネジメントの仕事をメインだとは
  思っていないんです。

Q.へぇ、どうしてでしょう?

A.どうも会社の姿勢にあるようです。小さい会社って
  管理という仕事を「コスト」だと思ってるようです。

Q.ありゃりゃ、じゃあ上司から「コスト削減!」なんていう
  号令がかかったら、管理の仕事が吹っ飛んでしまいますね。

A.そう、トラブルの現場を見ていると、実は管理だけしている人がいて
  その人がてきぱき指示をしている方が早くトラブルが収まるんですが、
  実際には管理だけの人ってあまりいないんですよ。
  自分で作業をしない、っていう点がポイントなんですけどね。

Q.なるほど、プロマネが自分で作業しちゃうとまずいんですね。

A.プロマネってもともと優秀なSEだったりプログラマだったり
  するわけですから、トラブルが発生すると自分がやっちゃった方が早い、
  って思ってしまうんですね。

Q.その気持ちはなんとなくわかります。

A.でもプロジェクトがうまく回らないのって、プロマネがそんなふうに
  目の前のことしか見ていないからなんですよ。
  プロマネはもっと先の方を見てなければならない。

Q.予想すること?

A.私にとってプロマネのスキルと言えば、まず「リスク管理」です。

Q.ふむ。

A.そして、その元になっているのは、ズバリ、「妄想力」です!

Q.「妄想力」!

A.そう、例えばこんな場合・・・
  直属の上司から仕事を頼まれた、
  あなたはどうしますか?

Q.なるべく早くその仕事に取り掛かって、片付けたい・・・

A.妄想力のあるプロマネは、
  「上司に言われた仕事、今すぐやる必要あるの?」
  「それより1ヶ月先のお客様の事が気になるなあ」
  「このまま行けば1ヶ月先にお客様から××してくれって
   頼まれるかも知れないぞ」
  「あ、そしたらプロジェクトメンバーの1ヶ月先の
   スケジュールってどうなっているんだっけ?」
  「あ、その直後にお客様の方でイベントがあったような気がする」
  「じゃあその時期お客様の方のスケジュールってタイトなんだなあ」
  「すると打ち合わせするなら少し前倒しかなあ」

Q.あれれ、自分の上司はどっか行っちゃった(笑)。

A.実は今すぐにやらなくてもいい仕事って結構あるんですよ。

Q.頭の中に何が浮かぶかが大事なんですね。

A.イベントも含めて全てのステークホルダー(利害関係者)の
  スケジュールを常に頭に入れておく必要がありますね。

Q.管理の仕事ってちょっと違うイメージだったかも知れない。

A.管理っていうと「何があったか」「何が起きたか」を
  しっかり把握するっていうイメージがあるかも知れないけど、
  それより大事なのは常に先手先手で準備をしておくっていう事なんです。
  そのために必要なのが「妄想力」です。

 ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・

Q.なんとなくプロマネにとって大切なことがわかってきたような
  気がするんですけど、では何故現場のプロマネにはそういった
  スキルが備わっていないんでしょう?

A.それは教わらないままプロマネになっていくからです。

Q.なるほど。

A.リスク管理を知らないままプロマネになると、
  「何でリスクなんて気にするの?」
  「今何も起きていないじゃん?」
  という考え方になります。
  妄想力のあるプロマネなら、「3日間でやれ」
  と言われた仕事は必ず1.5日でやります。

Q.ああ、残りの1.5日は何かあった時のために取っておくんですね。

A.はい、常に前倒しです。

Q.教わらないでプロマネになると大変そうですね。

A.他にもいろいろと知っておく必要があります。
  まずプロマネとかリーダーって偉くないんだ、っていうことです。
  常に縁の下の力持ちなんです。

Q.縁の下の力持ち、なるほど。
  そう思えれば管理の仕事に徹することができそうな気がしますね。

A.あと、元優秀なエンジニアだった情報系のプロマネは、
  コミュニケーションが苦手な人が多いですね。
  そういう人はメンバーの事が見られない。
  「本来のゴールはどこだったのか」を見失う人も多いです。

Q.うーん、なんだかうちの学生の事を聞いているような気が・・・

A.ああ、卒業制作でハマる学生がいましたねえ(笑)。

Q.そうなんですよ。技におぼれて目的を見失う・・・

A.でもそれがいい経験になるんですよね。

Q.ええ。

A.あと情報系のプロマネって、自分の担当している製品の
  細かいところまでしゃべれない人って多いんですよ。

Q.それはなんとなくわかります。情報系のシステムって
  大規模で機能分割が進んでいて分業化が徹底している
  イメージがあります。細かいところまで全部知るのは難しそう。

A.でも普通のメーカーの営業さんが自分の製品をしゃべれないって
  聞いたことあります?

Q.あっ! 私以前メーカーに勤めていましたが・・・

A.有り得ないですよねえ。

Q.営業の人も専門分野の知識を必死に勉強してました。
  かなり高度な化学の知識を要求されていたし、
  製品も多品種少量でひとつひとつ機能が違います。
  知識が足りなければ・・・売り上げゼロ、ですねえ。

A.でも情報システムだとよくあるんですよ。

Q.なるほど・・・
  プロマネになるにはやはりいろんな事を知っておく
  必要がありますね。
  そんな現場での経験が、人事・教育系の
  今の会社への転職につながっているのですね?

A.そうですね。
  わたくしども株式会社エル・ティー・エスでは
  現役のプロジェクトマネージャーの方を対象とした
  半年間の「PM実践塾」を開催しております。

Q.ここからは宣伝タイムです(笑)。
  プロマネの研修は半年間ですか・・・
  やっぱりそれくらいかかるんですね。
  パンフレットを見てみると、お、実践重視。
  最後の方に「失敗事例ケーススタディ」「プロジェクト人間学」
  とありますね。いやあ、これは興味深いです。

A.それから弊社のサービスラインにはeラーニングもあるのですが、
  東日本旅客鉄道株式会社様で採用された
  「実践可能なスキル習得のためのヒューマンエラー防止プログラム」
  が、第7回日本e-Learning大賞「経済産業大臣賞」を
  受賞しました。

Q.さすが! 教育系に強いエル・ティー・エスさんですね。

 ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・

Q.長い時間ありがとうございました。
  最後に、櫻井先生の今後の展望は?

A.コンサルと言えばお客様の会社経営のサポート
  ということになりますが、せっかくなので自分の会社の
  会社づくりに内部から関わってみたいです。
  来年設立10年目、60人という会社規模、
  社長・取締役がほとんど30代という環境ですから、
  自分も経営に興味を持つことができます。

Q.若くて勢いのある会社にいると考え方も柔軟になって
  可能性が広がって来ますよね。是非役員になって下さい!
  2人目のお子様も生まれたことですし(笑)。

A.はい(笑)。



櫻井さん、忙しい中ありがとうございました。
教員からコンサルへの転進というのは
珍しいパターンかもしれませんが、
教育という筋が一本通っている櫻井さんの場合、
転進の際の障壁なんか、ものともしなかったのでしょう。

今後のますますのご活躍を期待しております!
そしてプロジェクトをきちんとドライブできるプロマネを
次々と輩出していって欲しいです。
良いプロマネが増えれば、そこで働くSE・プログラマ
みんなが幸せになれるかもしれません。
日本電子の卒業生のためにも、よろしくお願いします!