« 2015年9月 | トップページ | 2015年11月 »

2015年10月の記事

クワドラプル・コンボ!

男子フィギュアスケートのジャンプ&回転で、「4回転」を英語で聞いている記憶が無い...ような気がします。
「トリプル」や「トリプルアクセル」は聞きますけど(女子競技しか観ていないからか?)。

Pict278710月の定例会の最初で、共済会から結婚祝い金を手渡された長部さん

そして、定例会コンテンツとして現場実務からスクラムの話」で盛り上げてくれた長部さん
これ[↑]は前々回に書きました

Pict2794Pict2795先月から繰越の誕生日祝い(10月生まれの人がいないので)で、小さいながらもホールケーキを1人占めした!
(と言うわけではありませんが)長部さん
先月は(先月も?)業務都合で帰社できなかったので、「1ヶ月だけ繰り越す」ルールの元に無事に誕生日祝いが出来ました。

あ、ちなみに...
ケーキ入場の時に室内の照明を消して、本人以外の全員で「ハッピバースデイ、トゥーユー♪」を毎回歌うんですが、
9月頭に入社した中里さんは始めてその様子を目の当たりにしたわけです。
「男の大人の人達が大勢でこの歌を歌うのって、珍しいですよね」と言われましたー。

うん、確かに!
見ようによっては不気味かも?!.....

いやいや!、外人さんとか普通にこーゆーことやってない?
別におかしくないよ、大人達が、野郎共が、オジサン達が歌ったって。
うん。 大丈夫、大丈夫!.....
(まあ、確かに、毎回ちょっと恥ずかしいんですけどね。実は)

あ、今回は長部さんの話でした。

定例会の中では以上の「トリプル・コンボ」だったのですが、

その後に、10/28日から読売新聞の夕刊の「しあわせ小箱」というコラムに、長部さんのフルネーム入りで
記事が連載(多分3回くらい)されています!

こちらはプライベートの活動でアサカツが起点になっている「東京シャボン玉倶楽部」http://shabons-with.me/blog/)のことが
記事になっていました。

いやー、見付けたときはビックリ!

この件[↑]も加えると、10月としては「クアドラプル・コンボ」で、何かと出番が多く大忙しの長部さんなのでした!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

デザイナーでなくてもCSS!

10月の全社定例会では、
社内での業務案件群に対して横串で稼動している、主にデザイナー(CSS、JavaScriptコーディングを含め)の役割を務めている、若手のトミー佐藤さん; アスペア内には「佐藤さん」が4人います...ので、旧姓で呼んだり、あだ名で読んだりして混乱を回避してます)が、
CSSの無名クラスの利用例、メリットの説明などをしてくれました

Pict2790コンシューマー向けのサイト構築・大幅改変などの場合、外部のデザイン専門会社に発注することが多いかと思いますが、
一定レベルまでイメージを詰めた後は、デザイン系のソースコードも開発者側の管理下に入ってしまうことが多いかと思います。

勿論、最初のコンセプト詰めの段階からデザイナーとステークホルダーが適宜・リアルタイムで話し合いながらデザイン、UI/UXなど詰められれば良いのでしょうが、
自社の開発部署の中にデザイン選任グループまで抱えられるのは、ゲームやゲーミフィケーション要素の高いサービスを展開しているような場合に限られるのではないでしょうか。

或いは、複数プロジェクト/サービスのデザインを兼任するか、外部からのデザイン受注も並行して行うか、などのパターンになるかと思います。

外部のデザイン会社から、最終稿として受け取ったHTML/CSSファイル群などは、適宜でプログラムコードを埋め込んだり、プログラム側に一部取り込んだりなど(使用言語&フレームワークにも依存)してしまうので、
再度、デザイン会社に依頼し直すには、いろいろと無理があります。

Pict2793なので、開発者にも(全員に均等に、という訳ではありませんが)UI/UX、デザインの基本原理の理解とセンスが必要になります。
サイトのフロント&バックエンドの両方を自在に開発/メンテナンス出来るメンバーである為には、
CSS/JavaScriptの突っ込んだ実戦的な知識が不可欠になります

アスペアの中で、デザイナーと開発者の間を取り持ったり、最終稿以降のメンテナンスを行ったり、新規にページを追加したり、画面遷移を変えたり、その他諸々...
勿論、新規でサイトを構築する場合も含まれるのですが、
そういった役割をほぼ1人で背負って立つのがトミーですっ!

必然的にCSS周りは社内で(恐らく)一番詳しいでしょうし、クラスやファイルの構成ガイドライン、コーディング・ガイドラインも独自に整理・集約して適用してくれています。

定例会でのコンテンツとしては、10分間の枠で「IT-Tips or 5分間スピーチ」(質疑を含む)で、極一部のみ展開してくれたのですが、
あれこれ質疑が割り込んでいくと、あっという間に10分間の時間を消費し尽くしてしまいました。
(そりゃそうだ)

もう少し枠を広げて(時間も、共有範囲も)、次回に再度実施して欲しい!/やりしましょう!って話になりました。

負担かけて申し訳ないけれど、
(人に教えるのは、自分自身の理解を深めたり、知識の抜けを補完するチャンスでもありますから)
宜しくお願いします!、トミーさん!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

実務からスクラムの話を共有した。

顧客先でのECサイトの保守・運用・開発を行っている長部さん

Pict2788ここ数年、開発プロセスとして「スクラム」が導入されているとの事。
実務ベースの例として現実的に貴重な体験なので、共有の為に全社定例会の中のコンテンツとして展開してもらいました!

予定の時間枠は、本人申告で40分としていたのですが、
質疑でかなり膨れるんじゃないのかなーと想像していたんですけれども.....

フタを開けてみれば、何と倍の80分を要しました!

スクラム自体に関しては、これまでに定例会での勉強会やワークショップ等を繰返して来ているので、特に基本的な説明無しで進みました。
それでなおかつ、80分。

しっかりしたスライド(PowerPoint;無駄に凝ってた訳でも冗長でもなく)を準備してくれていたのですが、
説明途中での適宜での質疑・応答、派生しての話題の展開などで話が途切れません

Pict2789アジャイルな開発プロセスと言うと、能動的で密な&タイミングを逃さないコミュニケーションが必須前提になりますが、
チームを構成しているメンバーの大半が外国人で、殆どが日本語を話せない
標準の会話、チャット、メール、ドキュメンテーション、全て英語とのこと。

その辺での苦労話とか、厳しい場面での対処法などの話題も出ました(詳しくは書けないのですが...)。

定例会の最後の振返りでも、
「長部さんのスクラムの実務例の話題、非常に面白かった!」が Keep として挙げられました。

ちなみに、後日のWeb週報(社内の全員がお互いの週報を見られる)にも「とても興味深く聞けて楽しかった」
「振返りの視点(多少独自にカスタマイズされている)も、現在の仕掛プロジェクトに取り入れても良いのでは?」などのコメントを
書いてくれているメンバーもいました(←こういうのは嬉しいですね!、いや本当に!!)。

他に、自身で英語力を上げるべく色々な方法を実践して来た山内さんの週報にも、
英語を習得するに当たっての、導入部分での入り方のおススメ方法なども挙げられました。

形式知の共有は比較的簡単だと思うのですが、暗黙知の共有はとても難しいと思います。

でも、一方的な情報発信ではなく、メンバー間の相互作用の中で展開されていく情報ってのは、結構・暗黙知の共有にも有効なんじゃないかなと思ってます。

今回の長部さんの「実務でのスクラム」(保守運用に伴う開発・各種作業なので、&チーム構成メンバー・その他条件の実態に合わせて)
カスタマイズされたプロセスで運用されている、っていう点も重要ですね!

「当初はこのように運用されていたが、こんな問題点があり、現在ではこのように運用している」、などの「プロセス自体のメンテナンス」の話も貴重でした!!

どのような開発プロセスを適用しようとも、
・「全員&チームが改善指向である」、
・「全員が意見を出し合う(遠慮なく、タイミングを遅らせることなく)」、
・「チームとしてリリースをコミットしたのだから、チームの全員が責任意識を持つ」、

...などは大前提です!!
アスペア内の全員が、公式にどんな開発プロセスを適用していようとも、この辺の意識・レベルは共通標準でありたいと考えてます。

長部さんからの話で、改めて意外だったのは、「1日の稼働時間数」をかなり低めに設定していたこと。

これは、長く続いているサービス/機能である点も関係しているのでしょうが、
メンバー間の質疑やサポートに、結構な割り込みが入る。
人間は基本的に常時マルチタスクで動くようには出来ていないから、割り込まれると元のタスクの処理状態に(頭の中が)戻るのに時間を要するってことも有ると思います。

何より、「実務実態から導出した、(残業前提無しの)稼働時間だから、それで計画している」っていう点が良いです(当り前の事なんですけどね)

また、「タスクの見積精度を上げる為に(プランニングポーカーや振返りなどに)時間を掛ける」方が、仕様自体の理解が進んだり、
仕様自体の問題点の発見や、前提条件として別のタスクが必要と判明したり、
とにかく早期のリスクヘッジが出来る
改善すべき点を早く具体化して、メンバー全員が納得できるアプローチで対処を始められる

「タスクとして着手して、時間が経ってから問題点として判明する」よりも、消費する時間・労力・コストが少なくて済む
...などの点も、長部さんの口から実体験として述べられたことは興味深かったです。
以前の、蓑方さんからのスクラム実務の話でも、同様の内容が有りました

長部さん、予定枠の倍の長時間に渡るコンテンツ、お疲れ様でした!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

メンバーの動きを見ていて想うこと...

筆者自身は、開発の最前線には2000年初頭までしかいなかったので、最近の開発現場で必要となる要素技術は持っていませんし、
感覚的な「これが普通」という基準というか、常識というか、単なる概念だけ押さえていても共有できていないものがどんどん増えて来ているなあ...と、最近特に実感しています。

そもそも顧客先で業務を行っているメンバー達に関しては、残念ながら「作業を行っているその場」を見る・聞くことは出来ません。
(お客様を介して、各メンバーやチームに対しての「評価・問題点・より期待したいこと」などは定期的に聞き取っていますが...)

現在、自社内で開発業務を行っているメンバー達は、2つのチームに分かれています(顧客も違います)。

筆者自身が「現場感」をリアルタイム&ナマで感じ取れるのは、現状では唯一・彼ら・彼女らに拠ります。

現時点で社内にいる開発メンバーの大半を占めているのは「町田ラボ」と呼んでいるチームで、
顧客先に常駐して作業をしているアスペア・メンバー数名の中から、ラボとの窓口係(欠勤時には別の者が代替する)が外出し可能なタスク(粒度はマチマチ)を投げる。
(対象は、或る公開Webサイトのフロント/バックエンドの全般です)

町田ラボ側も、原則は窓口1人(こちらも状況次第で別のメンバーが代理を務める)で取りまとめを行います。

と、こう表現してしまうと、一見合理的に見えるかも知れませんが、「コミュニケーション・ロスが大きいんじゃないの?」と思われるかも知れません。

が、実際には、オンライン・チャット(slack)、版数管理、タスク管理(基本的にチケット駆動)、ドキュメント共有環境などを併用しているので、伝言ゲームで工数が増える・精度が落ちる割合は非常に少ないと思います。

と言うか、そうなるようにツール選定・環境構築、運用ルール決め&適宜見直し&ルールの徹底などをしている、ということですね。
放っておいても、勝手に上手く行くことは(絶対に)有り得ないですから

勿論、町田ラボ内で決定すれば良い事と、顧客先メンバー(窓口)と調整の上で決定しなければならない事が有ります。

で、このチームで1人前に仕事をするには、ある技術的な習得内容とレベルに結構なモノが要求されます(具体的には書けませんが、とても強力なOSSです)。

一通りのトレーニングメニューを消化し終えないと、「数画面に渡る文言修正」とか「CSS調整」とか、
軽んじることは出来ませんが、技術者的に「面白い」とは言い続けられないタスクしか担当できません。

とは言え、タスクは山積みなので、トレーニング中もある程度まで進んでいれば、可能な範囲で比較的軽いタスクを担当することになります。

これ(トレーニングと実タスクの担当スイッチ)は大変なように見えますし、実際大変なのでしょうが、
見方を変えれば、技術的なトレーニングをしながら、先々で担当して行く業務の一部を見ていく・末端からでも徐々に把握して行く機会でもあります。

これには営業的・経営的な背景もあるとはいえ、うまく機能しているなあと感じてます。
稼働時間数は決して長くありません。通常なら定時退社。2時間残業すれば多い方ですし、常態的に続くこともありません

「町田ラボ」のメンバー達の動きを見て・聞いていると(或いはslack上のやりとりを眺めていると)、いろいろと面白いなあ(手前味噌ですが、よくやってるなあ)と感じます。
(勿論、顧客先メンバーの頑張りや、窓口係の采配の良さが前提になっていますが)

※slackのやりとりが頻繁。だけど、顧客側窓口メンバーへの負担は抑えるように配慮している。
  ・自分の担当タスクに関係の無い、お互いの呟きもチェックしていて、必要になった時に活かしている
  ・「あれ?、何かおかしいな?」と思った時は、必要な相手に、適切な手段で確認している。
    ・これで、結構、品質担保や成果物に対するガイドライン化が進んだりもする
※タスク内容に指示が無くても、要求や仕様・画面の見栄え・既存ソースに問題を見付ければ、即共有する。
※↑:方向性を確認してから進める。回答待ちの間も時間を無駄にしない
※当り前だけど、毎日朝会をやっている(ほんの数分)個別の問題点は、必ず別枠で対処している。
※お互いのコミュニケーションが多い
  ・結論的なモノ、共有すべき(かも知れない)質問・確認などはslack上に流している。
  ・対面で詰めるべきものは、「今、ちょっと割り込み良いですか?」と聞いてから会話を始める。
  ・顧客先のメンバーと電話したい時は、slack上で「電話して良いですか?」と投げてからコールする。
    ・受ける側は個人携帯なので、自社(町田)側から発信した方が良い。という点もあります(通話料の点で)。
※躓いた点、煩雑な手順などで経験・知見が得られたら、共有すべきかをまず考え、記録に残す
  ・これには、顧客側の情報共有の仕組みを利用したり、ラボ側だけで共有すべきことは自社のツールに載せてます。
※ラボ側のタスクの配分は基本的に窓口 = リーダーが務めます。が、
  ・これ自体を、リーダー不在時(小さなお子さんがいるので時間や勤務体系が柔軟)には代理者が動く
  ・リーダー以外の全員が、「自分はリーダーの配下であり、指示を待つのみ」的な意識ではない!
    ・去年入社した若手でも、必要と有れば自分からタスクを取りに行く(調整・確認)など、指示待ちしてない。
リーダーの言動・人格に感心する...
  ・チームへの新規参画者への導入説明、事前の(日常からの)資料の整理、段階とタイミングを見ての説明が的確で確実。
  ・疑問点を見付けたら、タイミングを逸しないで即ツッコむ(フォローする、という意味ですよ)。
    ・何故、誰が、いつ、何を、どうする、どう周知する、までを(可能なら)その場で即決・共有する。
  ・不安点・リスクに気が付くのが早い。そして、現実的に可能な対処法を決めて実行する。
    ・実行は、それが必要なタイミングで、可能なメンバーに振る(勿論、それがリーダー自身である場合も有る)。
  ・視点が「担当タスク」に限定していない。別画面・機能・サービスにまで配慮している
    ・必要な可能性があれば、顧客側の窓口とも共有している。
  ・アスペアのビジネスとしてより良い方向に行くよう、「町田ラボ」の顧客評価を気にかけて、折ある毎に顧客先メンバーに聞取りしている
  ・チームでの「振り返り」も実行して、今後の課題の抽出や対処策の検討などを行っている。
    ・その場で、これまでに得られたナレッジやTipsなどの共有も図っている(1人1つづつ提示、という宿題にしている)。
  ・メンバーの指向キャリアの方向性や、年間目標(MBO)を意識して、役割設定やタスク割振りも考えてくれる
  ・何気にボケやツッコミで、堅苦しい雰囲気を作らない。円滑なコミュニケーションが自然に出来るようにしている。
  ・気配りが細かい。

なんか、切りが無いですね。

でも、特に「アジャイル」と宣言しなくても、とても良い形でプロジェクトが進められていると感じます。

「自己組織化」とか言わなくても、大体出来てるし。

良いメンバーが揃ってくれていて、日々、とても嬉しいと感じてます。
有難う。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2015年9月 | トップページ | 2015年11月 »