ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守(アプリ方面)のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

プレイバックDevLOVE現場甲子園2014に参加してきました

DevLOVEのイベントに初参加してきました。

 
今回は以前に行われた「プレイバック現場甲子園」ということで、2013年、2014年に行われたプレゼンテーションの再演ということでしたが、半分以上は焼き直してました。
計10人の20分のプレゼンを聞いたので、全部まとめていると大変なので面白かった・考えさせられたものだけまとめておきます。

俺のエンジニアリング:及部敬雄さん

「ぼくのかんがえたさいきょうのふつうのチーム」のアップデート。
「エンジニアリングにチームビルディングは必要なのか」という問いでした。テクノロジーに走るとむしろ無視されがちな話題だったり、逆にそういう話題を考えるときには当然必要という前提だったりするので面白い問いだと思います。
ダメダメなチームでも、各チームメンバに話を聞いてみると意外と現場にいるメンバはどう改善すべきかに気付いている、けどそれを変えようという行動は起こしていない、というのはあるあるだなと。「人は変化を好むが、他人に変化させられることを好まない」(『リーン開発の現場』より、だそう)ので、そういったときの改善策の持ってき方として、「みんなにヒアリングした内容をまとめただけです」といって持っていくというのは凄くいい方法。結局メンバに「やらされてる感」が出てしまうともうダメで、(嘘でもいいから)彼ら・彼女ら自身から改善案が出る(出たように見せる)ことが必要なのだと。 
リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

 

 

ユーザーが「それいいね!」と言うまで:志田裕樹さん


ユーザーが「それいいね!」と言うまで // Speaker Deck

犬版のTwitterサービスをやっているとのことで、ユーザーにGoogle Hangout経由でインタビューしたり、やはりエンタープライズシステムの運用・開発とは違うな、とただただカルチャーギャップを感じました。

エンタープライズシステムの場合、特に運用の場合だと、クライアントサイドの予算制約があるので、「如何に要求を抑えるか」という部分に目線がいきがち。開発の場合でもユーザと直接要求開発することはあまりなくて、クライアント企業のトップマネジメントと大枠は決めてしまうので、要求の曖昧さも薄い。
 

自分のチームをどう作る? by すぎいまさかつさん

SIerでちょっと前に課長職になった方が自分のチームをどうするか、というお題。それに対してFearless Changeという本からヒントを得たことを中心に実践したことの紹介。僕もちょうど先月から課長なので同じ立場だったので非常に「分かる」問題意識だった。
他のチームと差別化した旗印(この方の場合はアジャイル)を掲げることで、人を育てられる(長期的に人材を確保し、頻繁な出入りが発生しない)ようにする。その他、「とりあえずやってみる」とかはよく言われることだけど、懐疑派代表(実践したいことに対して否定的な人物)を味方に付けるというのはあまり語られないことだと思うのでなるほどと思うところもあった。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

デザイナーもアジャイルをやってみたい by 秋葉ちひろさん

エンタープライズシステムの世界だとデザイナの人の話を聞く機会なんてほとんどないので新鮮。それ故自分の業務には直接結びつかないなと思いながら聞いていたのだけど、どちらかというと提案書とかのパワーポイントを作っているときの作業の仕方に似てるなと。
「4時間で2画面」よりも「1周間で10画面」のほうがデザインには合っているというのは納得。アジャイルの方法を取り入れたときにイテレーションの間隔をどれくらいにするかというのはそれぞれのチームやメンバ、あるいは作業の内容に依って違うべきで、唯一解的なイテレーション間隔というのはないと思う。
「価値検証(サービス自体がユーザにとってどのような価値をもたらすのか)」と「デザインの検証」(デザイン自体の良し悪し)が同時に起こることを防ぐというのはパワーポイントの紙書きのときにも当てはまる。最低限のデザインの価値とテイストが分かるものをいかに素早く作るかというのはまさに鉄則。また、最初から凝りすぎてそれがボツになったときのMP消費(笑)が半端ないというのも一緒。
 

私がドメイン駆動設計をやる理由 by 増田さん

ドメイン駆動設計、いわゆるDDDは名前は知っていたもののどういうものか全く知識がなかったので知れてよかった。曰く、「変更コストが(地道ではあるが)劇的に下がる」とのこと。ポイントはモデル駆動、三層+ドメインモデル、チームをドメイン駆動に、の3つ。
 「モデル駆動」としては現実世界の感心事をモデルとして単純化し、それをソースコードで表現するという2ステップをとる。パッと聞く限りは普通に要件定義書・設計書を作成してコーディングしていくのと何も違わないのでは?と思った。聞く限りは、例えば要件定義時にパッケージ図として書くなど、開発側の人が「この業務要件をどうソースコードに落としこむか」をその場で考えてモデル(設計書)に落としこむ、というところが違いか。
「三層+ドメインモデル」というのは、プレゼン層、アプリ層、DB層とドメインモデルという分け方にすること。単純に三層だけだと、それぞれのレイヤに業務ロジックや重複ロジックが現れがちだったため、リファクタリングを繰り返した結果、ドメインモデルの部分に業務ロジックが集約されたとのこと。確かに、業務ロジックがどこかに集約されていれば、変更時の影響分析は格段にやりやすくなるはずだ。 
 

中間管理職がいなくなったらプロジェクトがうまく進みだしたよ♪:西秀和さん

管理者が突然いなくなったら現場はどうなるのか?というまとめ。個人的には心が痛いプレゼンテーションでした。
IPA IT人材白書によるとアプリ技術者2人に対してプロマネが1人いる計算になる。しかも企業はさらにプロマネを増やしたいと言っている!IT人材白書2014については僕も以下の記事でまとめていた。上記は掴みのネタとしては面白いと思うけど、実際にはプロマネはインフラ技術者の管理にも必要だし、日本国外(オフショア)の開発の管理にも必要なので、「2人の作業者を管理する管理者が1人」というのは正確ではない。

IT人材白書2014をプロマネ視点で読み解く - ぷろまねさん

とは言えその後の実体験からの「管理者不在での成功」は学ぶべきものがある。大炎上の末大失敗したサービスイン後、そのリカバリフェーズでは予算の都合で単価が高いマネジャーが切られたまたまエンジニアだけが残った、そしたら1ヶ月でリカバリ出来てしまった、とのこと。

その理由としては、管理者が作業者に対して「何をすべきか(WHAT)」の段階まで粒度を細かくして渡してしまうと、作業者はそのWHATに対して「どうやってすべきか(HOW)」、「なぜすべきか(WHY)」までさかのぼって考えるに至らず、自発的に動けなくなる。それがたまたま管理者がいなくなった状況では作業者たちで自発的にWHY / HOWから考えるので、適切な打ち手が打てるということ。

管理者側からしてもこれは(作業者もちゃんと頭の良い人々な現場という前提で)同意しないといけない内容だと思う。作業者にHOWの部分から振ってちゃんと考えさせる、考えるクセを付けさせることは必要なこと。一方ででは管理者は何をしていればいいのか?というのも大きな問いだと思う。これはまた別の機会に考えたい。

アドベントカレンダーやります

帰りがけに上手いことアドベントカレンダーのお誘いに引っかかってしまいました。

DevLOVE Advent Calendar 2014 「越境」 - DevLOVE | Doorkeeper

アドベントカレンダーという単語自体これまで知らなかったのですが、本来のアドベントカレンダーはクリスマスを楽しみに待つための1日ごとのお菓子入りのカレンダのことだそう。

エンジニアのアドベントカレンダーは何かのテーマに沿ってみんなで1日づつ記事を書いていくのだそう。

上記の通り、「越境」というテーマで12月5日に書くことになったようなので、それまでに考えておこうと思います。