C93冬コミお品書きでーす！29日金キ30bでお待ちしています！！

12月29日金曜日東キ30bで新刊を２冊用意してお待ちしております。

新刊の他、少数ですが評判のエンジニアにグッとくる銀の弾Tシャツを頒布予定です。

カワイイ後輩の育て方５

品質管理をユリさんが熱ーく語ります。

かなり酔っ払いっているみたいですが大丈夫かな、ユリさん。普段、あまり喋らないから酔っ払うとなに上戸になっちゃうんでしょうね。

紙面構成を変更し、解説はニイナさんが中の人の代わりになってプラクティスを教えてくれるみたいです。一気に読みやすくなった「カワイイ後輩の育て方５」。お楽しみに！

ガルパン仕事術4
－いかにチームをスケールさせるか－ 

ガルパン仕事術もいよいよクライマックスの黒森峰女学院との決勝戦です。戦車道を復活させた大洗女子学園はたった一人しかいなかった戦車道経験者を増やし、熟練化出来たのでしょうか。

チームを育てること自体が難しいのに複数のチームを育て協調できたのはどうしてでしょうか。

チームをスケールさせる際のプラクティスがここに！

銀の弾Tシャツ（少数限定）

エンジニアがクリスマスにサンタさんにお願いしたいプレゼントの第１位が銀の弾じゃないでしょうか。

29日になるので年の瀬のご挨拶に、炎上中のプロジェクトマネージャへの差し入れや上司への付け届けにいかがでしょうか。

#C93 #カワイイ後輩の育て方　#ガルパン仕事術

プロジェクトマネジメント・インタビュー 株式会社LIFULL 小林様

「突撃！隣の会社のプロジェクトマネジメント!!」第2回目は、ホームズくんでおなじみのLIFULL HOME’Sでデザイナーをされている小林さんをお迎えして、どのようなプロジェクト運営をしているか、チーミングの特色や、メンバの育成などについてお話いただくくことになりました。

まずは、小林さんについて。

---

profile

小林武蔵さん

　株式会社LIFULL　http://lifull.com/

　LIFULL HOME’S事業本部

　新UX開発部　デバイスソリューションユニット　ディレクション・デザイングループ

 

　開発されているアプリ

　賃貸/売買物件・マンション・アパートなど不動産情報はLIFULL HOME’S/
　ライフルホームズアプリ

　https://play.google.com/store/apps/details?id=jp.co.homes.android3&hl=ja

 

　小林さんについては第1回のゲストの千歳さんもインタビューされていました！

　　http://media.coach4pm.com/entry/homes

　「HOME’S」の超高速改善プロセスの秘密とは？！大規模サービスにおける
　プロジェクト管理の最前線を丸ごと聞いてきた

---

（こ）小林さん

（い）稲山

（も）森實

グラフィック　高柳

撮影　野村

 

■デザイナーというお仕事について

（い）早速ですが、どのようなデザインのお仕事をされているか教えてください。

（こ）以前はWeb畑でデザイナーをしていて、PC・モバイル（ガラケー）やエディトリアルデザインと色々な媒体で学ばせていただき、現在はネイティブアプリに注力しています。

 

 

（い）Webデザインはブラウザ、エディトリアルデザインやスマホアプリと色々な媒体に携われると、それぞれの媒体による違いに気づかれることがあると思います。それぞれの特徴にはどのようなものがありますか。

（こ）デザインの根本は同じだと思っています。ただ、媒体ごとの特色はもちろんありますので、Webデザインができる人でもアプリらしさを考える必要はあります。

（い）Webやアプリにより媒体自体に違いがあったり、制約から感じられるものでしょうか。

（こ）それぞれの制約が「らしさ」に繋がるかと思います。例えば、Webの場合はPC・スマホ・タブレットで閲覧できますが、それぞれのデバイスでユーザが期待することが少し変わると思ってます。スマホではサクサクと情報が閲覧できること、PCでは詳細な情報がたくさん載っていることなどです。

　それを把握・考慮しないでアプリデザインをしてしまうと、Webからアプリに移しただけの評価になってしまいます。ユーザは手間を掛けてアプリをインストールしているので、Webよりちょっと何かよい体験を期待すると思います。

　なので、アプリらしさを理解して作らないと、アプリにおける上手なデザインはできません。

（い）若いユーザ層のインターネット利用は、ネイティブなスマホアプリから入っているのでそういった期待は大きかったりするのでしょうか。

（こ）Webは「検索した結果を閲覧する」という使い方をします。アプリは「ユーザが自らインストールする」というステップがあるので、その手間に見合った付加価値を求めます。

　若いユーザ層がアプリから入るのが普通なのであれば、今後は逆にWebでわざわざ検索しているのだから、という変化が起きるのかもしれませんね。

（も）インストールすることでユーザ自身が理由づけをして期待値も上げてしまっていると。

（こ）期待値はアプリの評価にダイレクトに返ってきますが、日本人の評価は厳しいとGoogleもいっています。なので、そういったアプリに対する期待はあるんだろうなと思います。

 

■アプリ開発について

（い）アプリ開発でのチーム人数は何人くらいですか。

（こ）最小単位は2人で、デザイナーとエンジニアになります。少しでもユーザ体験に影響がある場面では、デザイナーも一緒に施策を進めます。

　それとプロジェクト難易度により、プロジェクトマネージャ（以降PM）がジョインしたり、ディレクター・エンジニアを増員し、平均3−4人の体制で動くことが多いです。

（い）PMの方が入るのは3−4人になってから。

（こ）人数より施策の内容・難易度ですね。例えば最小単位が2人とお話したのですが、ユーザ体験に関わらないところでエンジニア1人で完結するときもあります。エンジニアもデザイナーも1人ずつでいいが、仕様や要件の影響範囲が広いときなどは、エンジニアとデザイナー以外の視点も大切なので、PMが入ってきて全体をコントロールします。

 

 

（い）アプリ開発のシステム開発手法、一般的にはウォーターフォールやアジャイル開発やその中間などあります。今のやり方はどれになりますか。

（こ）ウォーターフォールが適している施策はウォーターフォールで、アジャイル開発が適している施策はアジャイルでというのが回答になります。

（い）開発したいものにより使い分けている。

（こ）2年ほど前にアジャイル開発を取り入れてますが、馴染むまで苦戦しました。修正や追加案件が出てきたら「次のスプリント」となるのは本来あるべき動き方なんですが、ウォーターフォールだとそれらを含めてやれていたので、それができなくなることでのメンバーのストレスや動きにくさに繋がる部分でもありました。

　まずはそれぞれの開発の型にはめて動き「このチームだとどう開発していくのが一番効率いいだろう」をいろいろと試していきました。

　結果としては、仕様やデザインはスプリントから外してウォーターフォールで行う。その後の開発をアジャイルで進めるようにしました。このやり方だと、みんながやりたいように動けてフラストレーションもそれほどなく、開発スピードも出ることがわかり、当時はハイブリッド型開発という呼び方をしていました。

とはいえ、このやり方がアプリ開発チームにフィットするまで、1年半くらい掛かっています。

 

 

（い）アジャイルとウォーターフォールの使い分けは始める前にわかりますか。

（こ）過去に類似した施策があればその知見と、施策の影響範囲をみんなすり合わせることで、ある程度使い分けはできるようになると思います。

　影響範囲が狭く、エンジニアの作業で完結するようなものであればアジャイル、各種調整が必要で、影響範囲も広い場合はまずはウォーターフォールで動き出しましょう、という具合です。

 

■継続的な改善について

（い）チームのメンバ同士で、開発や改修を通して繰り返し話題に登るテーマはありますか。

（こ）ナレッジが弱いという問題があります。全員が毎回同じメンバならドキュメント化は不要かもしれませんが、新卒も加わりますし、組織変更も考えられます。

　属人化したり、ドキュメント化されないことナレッジが蓄積されないことに対して、解消していこうという流れはありますし、成果も徐々にでてきていますが、まだ最適化・きれいに仕組化されていないという状況です。

 

 

（こ）リリースしたら、ふりかえり会をKPT法で行っています。ただ、「ふりかえり会をやった」ところで終わってしまうという問題があります。Problemは直さないと次に繋がらないし、それをやらないとチームの成長に繋がらないと思っていますが、どうしてなかなか。

（い）KPTのProblemで出したProblemをTryにできていない。

（こ）Tryを出したら満足してしまっているのだと思います。本当にTryをしないといけない致命的なものは対応するのですが、それ以外は優先度が低く、取り組めなかったり、次のふりかえり会で同じTry項目がでるなんていうことも稀にあります。

（い）大切なProblemは改善できているけれど、それ以外まで手が回っていない。

（こ）はい。致命的なものだけが大事ではないとメンバも理解していますが、優先度が上げられない。

　例えば、普通の操作でクラッシュしてしまったら「全員で即座に共有して対応する」というようにスピード感をもって対応できているのですが、普段、施策に取り組んでいるときは、作業時間を削ってまでTryに取り組むことが出来ていないのはチームの課題です。

（も）KPTのTryにAction planのAを付けてPlanまで落として回した方がいいというやり方があります。

（こ）そのActionのように具体的に何をすればいいかまで落とし込むことや、そうした取り組みのリーダシップを取る人を情熱リーダとして立て、Tryで出来ていないアクションを少しずつ改善していこうと取り組み始めています。

 

 

■チームの役割について

（い）チームを組むと価値観の違う人が集まってきます。エンジニアとデザイナーとは専門性が違いますし、エンジニアでもアプリとインフラでは専門性に違いがあります。そういう人達が集まったときにプロジェクトをやっていく上で何を大切にしますか。

（こ）一番大切にしたいことはユーザ体験です。収益や工数とかは一旦置いといて、どんな体験・価値提供をできるかどうかを考えます。その上で、もちろん後者についてもちゃんと考えます。

（い）何か、きっかけがあってユーザファーストになったのですか。

（こ）会社として、ステークホルダーを大事にしましょうという考え方があります。特にデザイナーという職業はBtoBやBtoCに関わらず「情報が正しく、わかりやすく、伝わっているか」を常に考えている人たちなので、相手を大事にしたモノづくりというスタンスは自然なものだと思います。

　社是に掲げている「利他主義」は採用や評価でも最も大事な価値観としているので、それに共感する人しかいません。だからユーザー（相手）を大事にするという考え方がズレにくいのだと思います。それが結果として、売れるもの＝ユーザが欲しいもの・必要なものとなって収益に繋がります。

　ユーザファーストを大事にしていますが、掛けるリソースに対して少ないユーザの価値しか産めないこともあるので、そういった場合はユニット長が「本当にそれでいいの？」と助言してくれます。

 

 

（い）長は役割を果たされている。

（こ）おそらく常に注意を払ってくれていると思います。「いいじゃん」と褒めてもらえるときもあれば「どうなってる？大丈夫？」と停滞してしまっているときにお尻を叩いてくれる役もしてくれます。

　メンバーが施策に熱中して、アクセルを踏み込みすぎて、ハンドリングがおろそかになるときがあります。そういったときに俯瞰して見てくれているPMがいると、心強いです。

 

■メンバの成長について

（い）チームの価値観は揃っているようですが、そうした中でも意識的に取り組まれていることはありますか。

（こ）施策毎に育成コストが掛かっても個人が成長できるように意識しています。

内製にこだわっているところにも関係するのですが、誰かが不在になっても、残りのメンバーである程度開発を回せるようになるのが理想ですね。

　2、3年目のメンバに難易度の高い仕事を振りつつ、先輩が見て品質を確保するようにし、経験と知識を養っていくイメージです。その分コストは発生しますが、サービスを育てるのと一緒に人も育てていかなければならないし、育てていきたいと考えてます。

 

 

（い）エンジニアやデザイナーに関わらず、若いメンバに仕事を任せている。

（こ）僕は成長は筋トレだと思っています。今できる100％で仕事をこなしても成長しないと思っているので、105％の仕事をお願いするようにしています。この5％をクリアするために、やりながら成長しないといけない。そこはインプットしてもらうなり、アドバイスしてあげるなりしてやり抜いてもらう。それを繰り返して、当初の120％の力がついている、というスタンスでやっていいます。

　ただ、時には気持ち良くやりきれないと楽しくないと思うので、100％の施策をお願いして、本人に「出来た」と実感してもらうことも大事だと思います。

（も）成長が感じられますね。

（こ）こちらとしても嬉しい瞬間ですね。逆に120%の施策をお願いすることもしてます。「まかせたよ！」と。ぶん投げることで、こんなに大きな仕事を任された、とワクワクしてもらえれば成功ですね。

（も）僕もそれをするとワクワクしてくれます。お話を伺っていると一人ひとりの意識が高いと感じました。

（こ）「自立して、自律して、自走する」ということをユニット長は強くメンバーに意識をさせています。仕事の作り方じゃないですけれど、そういった働き方に導いてもらっていると思います。

（い）仕事の作り方ですか。

（こ）例えば自分が作っているアプリでも改善できるところはあるはずです。だったら、自分で見つけて、ここが使いにくいからこうしたほうがよいから提案する、という考え方を持とうと。

 

■チーム運営について

（い）チーム運営で大事にしていることには何がありますか。

（こ）これは完全に個人的な考え方という前置きをして(笑)

　敵を意識してもらうようにしています。好敵手としての競合もそうですし、空想上の「こんなチーム・働き方は嫌だ」を伝えて、方向性やあるべき姿を伝え、共有するイメージです。

 

 

（い）小林さんの考えはどこで身につけられたのですか。

（こ）小６からダンスを習い始め、たくさんのチームで踊る中で、同じ目標を共有できていないチームは成長しないと強く感じることがありました。大儀を共有できると一番いいのですが、そこまでのプロセスとして、方向性や意志の部分の負けん気だったりを共感するとうまくいくことがあったので、そのあたりですね。

（い）会社の文化であるユーザファーストがあったり、みんなが揃ってやっているなど良い会社だなと感じました。機会があればぜひ一緒にしたいですね。

（も）今の大事にされていることは観察眼がない人には出来ないことだと思いました。チームの中でコミュニケーションは測定してといっても測定出来ませんし、飴と鞭の使い処もその人をどう見ているかです。

　意識はされないのでしょうけれど、僕たちはこうしていこうとアクションがなかなか生まれないことに対する1つの解なのかもしれません。

　僕らは目標をどこに設定して、どこを目指そうとすることはとても大事だと思います。

片やアンチパターンというチームの悪を共有するのがありましたが、普通はこの2つを両立させないと僕は思います。

　なぜなら、僕達はこれを目指しているんだといったらそのためにどうあるべきかを解こうとするから。どうあるべきかを解いてしまったとき、みんなはそれであることを求めてしまい自分で考えることを失ってしまうという意味でチーム自体がどうあるべきかを考えるようにしているからコミュニケーションが成り立っているのだと感じました。

（こ）その人の正義を知るより悪を知る方がコミュニケーションをする上で大事だと思っています。

　その人の悪に触れずに上手に接することでコミュニケーションは円滑になると思うんです。必要であれば折に触れてつつきますが。

 

 

（い）相手の性格を知るってことですね。

（こ）そうですね！性悪説派なので、正しいってなんだろうを考えたいというのが根底にあって、そういった思考で物事を見ているんだと思います。

（い）相手を理解しようとしたことの行動が先に出ているのだと思いました。スマホアプリというプロダクトに携われているとSIerのエンジニアとはかなり違いがあることを気づきを得ることができました。

　本日はお忙しいところありがとうございました。

 

XP祭り2017お立ち寄りありがとうございました ＃LT祭り参加してきましたー

今年もXP祭に参加してきました。

今年は、講演枠ではなく夕方のLT祭りの枠でした。

講演のセッション枠は今年は特に激戦だったようで、アジャイル漫才でもその点についてはセンション抽選の経緯を申込者と関係者以外は知らないので丁寧にご説明されておられたとおりでしたし、発表されたセッションは濃ゆいテーマばかりでしたので納得の番組表だったと思います。

XP祭り2017の当日の流れはツイートで確認できますのでこちらをどうぞ。

togetter.com

セッション応募から溢れたスピーカーはLTになだれ込み、さらに野良LTまで盛況でした。こちらもバラエティに飛んだ超濃縮のスライドが目白押し。

1番目は原田さんから始まり最後のトリは中さん。そんな中で2番目に。スライドはXP祭りの最中に公開していますのでご覧ください。

XP祭り2017LT 「技術系同人誌で学ぶ 実践プロダクトマネジメント」 from Fumitaka Inayama

www.slideshare.net

このブログにリンクを貼るのに見に行ったら参加者を（多分）超えたviewになっているのでありがたいなーと思います。

頒布コーナーがA会場の中でしたので必然と基調講演から聴講させていただけることになります。

2012年のXP祭りから来ていて（facebookの過去の出来事で写真が出て来た）その翌年くらいからXP祭りもアジャイルvsウォーターフォールから組織論やチーミングにテーマが少しずつ変遷して行った時期に様々な講演を聞いたり、講演をしたりと関わることができて大変貴重な経験をさせていただいていると思っています。

昨年はプロジェクトマネージャの育成についてお話をするなどエンジニアの育成は一筋縄ではいかないイシューだと感じています。簡単に解決するような課題ではないし、でも何かしら解決策は見出したい。だからこそ、一人ひとりのエンジニアが体験して形式知に変えて共有することが知に価値を与えるのではないかと思うのです。

そういう価値のある知を共有する場としてXP祭りはカジュアルですし、ノリもいいので一見不安定に見えるかもしれませんがそれが持ち寄った知の集合を融合させることもできるし、鋭い質問がスピーカーに新しい気づきを与えてくれる場になっていると思います。

XP祭り最後の出し物は協賛出版社からの書籍プレゼントです。オライリーさんのトートバッグをいただきました。

戦利品の数々。ペヤングは寄付なのでスポンサー提供ではないですけれどwww。

最後の方になって、持ち込んだマイナビ本を１冊急遽プレゼントに回し、一番早く手を上げた方に。書評が楽しみです。

次の講演は、ナイトセミナーの2部で召喚されましたのでそちらで登場します。

企画名　　[西新宿開催] 大きなSIerの中で「アジャイル開発で飯を食う」までの歩み
開催日時　2017/10/18(水) 19:30-21:30
開催場所　〒160-0023 東京都新宿区西新宿7-21-1
　　　　　(新宿ロイヤルビル3階 グロースエクスパートナーズ株式会社 G's LounGe)
申込URL　https://postudy.doorkeeper.jp/events/64967

postudy.connpass.com

さらに、次の頒布イベントは、「技術書典3」となります。ぜひ、頒布会場でお会いしましょう。

日時　2017/10/22 (日) 11:00〜17:00
場所　アキバ・スクエア
主催　TechBooster/達人出版会
一般参加　無料

techbookfest.org

C92 ガルパン仕事術3 書影公開でーす！

夏コミ新刊　「ガルパン仕事術3」の書影公開でーす！

秋山優花里ちゃんが表紙でーす！11日まで待っててねー

C92 カワイイ後輩の育て方４ 書影公開です！

通称、表１と呼ぶ表紙です。

涼しげなアユちゃんの浴衣姿どうでしょう。

裏表紙は表４といいます。もちろん、シンコちゃんの衣装は？

外出 インドネシアとベトナムの風景

このお出かけは、終電ちゃんのコラボを観るためにと言っても過言ではないのです。

2時間前に着くように行くんですよね、空港には。

九十九里なのかな。

空港からホテルへ。渋滞していると物売りが路上に。何売っていたのだろう。

インドネシアの初日の夜景。行く数日前にテロがあったり、ラマダンに入ったばかりだったり。外出は控えます。車はほぼトヨタばっかり。

ホテルの入り口に手荷物検査。人もゲートをくぐります。

6時の風景。

通勤のピークは過ぎてもバイクがものすごく多いのです。隙あらば割り込んできます。

夕方の工業団地。隙間があるとどんどん割り込んできます。

 南武線の嫁ぎ先はインドネシアでした。さすがに乗りに行くわけにはいきません。

さて、ホーチミンへ

同行者のPCにこのタイミングでWindows updateが始まる同行者が。

着いたら雨だった。後でわかったけど雨季らしい。タラップ降りてバスに乗り換えるの久しぶり。

ほぼ上がったのかな。

ベトナムは車のメーカーが多いですね。KIA、Ford、三菱、トヨタ、日産、ヒュンダイ…国内では売っていないいすゞのRVの看板があった。

ホーチミン初日の夜。

歴史的建造物ばかり。

歴史のありそうなホテル

街並み。

工事中だったのでそのうちオープンするのかな。

同行グループから離脱してひとりごはんに。

手前の皿のライムに隠れている唐辛子がたった２片で超絶辛い。

BIA頼んだら333だった。

帰り道のファミマで見つけたたい焼きアイス。一番下の何味だろう。

翌日、早朝のお散歩。

ケーブルはものすごい量が上を這っているわ、切れた？ケーブルは放置されているわ。

歩道も平気でバイクが走っているのでその対策かな。

博物館かな。

戦車。

何通りだっけ。

川の方。

工業団地に向かうの図。

工業団地に向かうの図。

ホテルの隣の区画前にあった巨木。

ベトナムの「の」

プロジェクトマネジメント・インタビュー iYell株式会社 千歳様

interview企画に至るまで　ー企画の前説的なものー

システム開発手法のウォーターフォールやアジャイルのスクラムでこれが世界共通の標準というテンプレートがあるわけではありません。システム開発手法はもちろん、プロジェクトをマネジメントするPMBOKもマネジメントからのモニタリングとしての考え方であり、知識エリアの実務での実施要領はプロジェクトや組織で構築しなければなりません。

 

エンジニアが経験できるシステム開発手法やプロジェクトマネジメントは、メンバとして参画したプロジェクトのプロジェクトマネージャやスクラムマスターの経験に基づくものです。これは、

 

「エンジニアは参画したプロジェクトで採用されているシステム開発手法やプロジェクトマネジメントの管理方法しか経験することができない」

 

ということの裏返しです。そういった考え方に立つと、他社のシステム開発手法やプロジェクトマネジメントはどのように運用されているのだろうと興味を覚えたのでした。

 

だったら、実際にあって聞いてみたらいいのではとツイッターで呟いていたところ、この企画に最初に興味を持っていただいたのがiYell株式会社の執行役員兼すみかる編集長の千歳紘史さんでした。

@inayamafumitaka coach4pmというプロジェクトマネジメントに関するブログを書いております千歳と申します。弊社のことでしたらお話できます。

— 千歳紘史／chitoseweb (@chitoseweb) 2017年1月17日

このインタビューは、様々な会社のでプロジェクトマネジメントを会話を介して体験する企画です。それではiYell株式会社の千歳様のインタビューを始めましょう。

---

profile　ー千歳様とiYell社についてー

千歳 紘史さん　iYell株式会社（いえーる）

　執行役員 兼 "いえーる すみかる”編集長　https://iyell.co.jp/member/kchitose/

　経歴　受託開発や自社サービスでのプロジェクト経験を積んだ後、独立してプロジェクトマネジメントを支援する株式会社理想ラボを設立。2016年11月にiYell株式会社と事業統合し、執行役員兼”いえーる すみかる”編集長に就任。

　住宅ローンや不動産会社選びの情報サイト　http://sumikaru.iyell.jp/

　個人ブログ　 http://media.coach4pm.com

---

interview

インタビューの約束の日は、天気予報どおりに昼下がりを過ぎたあと1時間もないタイミングに雷鳴と驟雨が道玄坂の風景を変えた、そんな5月の午後にiYell社のオフォスで行われました。

自己紹介のあと、限られたタイムボックスの中でインタビューを行います。千歳さんに、森實さん・筆者でインタビュアーを、3人の会話を高柳さんがファシリテーショングラフィックでまとめていきます。

会話形式で表記します。発言者の表記は次のとおりです。

　ち：千歳さん　も：森實　い：筆者

 

■千歳さんのキャリア、iYellでの役割、進行中のプロジェクトについて

い「千歳さんご自身のプロジェクトマネージャの経歴を教えてください」

ち「キャリアパスとしてよくあるエンジニアからマネジメントになったのではなく、マーケティング畑からシステム開発のプロジェクトマネージャになりました」

い「iYellでの役職を教えてください」

ち「Web系のプロダクトを統括しています。システム開発のエンジニアが9名（SES２名含む）、編集が6名、セールスが2名の計17名のチームです」

い「編集のメンバの具体的にどのような業務をされているのですか」

ち「システム開発以外のすべての業務を行うチームを＜編集＞と呼んでいます。ユーザーインターフェイスの検討やコンテンツ制作、マーケティングKPIのコントロールなどを担当しています。ただ、開発、編集、セールスの線引きは厳密なものではなく、全員がすべての領域をカバーできることを目指しています。」

い「開発部門で現在進行しているプロジェクトはどのようなものですか」

ち「現在*1の主なシステム開発プロジェクトは、今秋リリース予定の、不動産取引に特化したスマートフォン向けAIチャットアプリ開発にほぼ全エンジニアを投入しています」

*1　2017年5月1日取材時点。

---

■開発部門のマネジメントについて

い「開発部門の組織構造はどのような構成になっていますか」

ち「千歳－技術責任者－エンジニアメンバの3階層になっています」

い「CTOの配下のエンジニアはフラットですか。それともリーダを配置していますか」

ち「フラットです。今の人数であれば生コードを把握できる規模なので」

---

■システム開発手法について

い「主なプロジェクトのスマホアプリ開発だと、システム開発手法はアジャイル開発のスクラムを採用されていますか」

ち「緩いウォーターフォールを採用しています。基本的な機能開発を終えてファーストリリースした後は、アジャイル開発のように短期間で開発を繰り返すと思います」

い「短期間で機能開発を繰り返すシステム開発手法はアジャイル開発よりは、短いウォーターフォールの繰り返す追加開発のイメージに近いですね」

ち「そのイメージが近いです」

い「WBS、タスク管理には何かツールを使用していますか」

ち「タスク管理にはRedmineを使って、チケットで管理しています」

---

■ガントチャートは使用しない

い「Redmineなどのチケット管理システムだとチケットが一覧のビューで表示されます。スケジュールはプラグインなどを入れてガントチャートで共有されていますか」

ち「ガントチャートは使っていません。ガントチャートは、工数や期間や依存関係が曖昧に表現されすぎるので、現実と乖離してしまうことが多いと思っているからです」

い「タスクの見積もり工数が数時間でもガントチャートで表現すると1日になってしまう、ということですね。ガントチャートの線で作業プロセスの何を含めるのかと決め事も必要になります」

ち「そうです。それにガントチャートでタスク毎の線を描くと、未着手なのにできた気分になってしまうのも精神的によくないと思っています。」

い「人は子どものときから日曜日から土曜日のカレンダーや夏休みのスケジュールなどで日付を単位としたスケジュール管理に慣れています。そういった慣れについてはどのように時間軸を共有していますか」

ち「マイルストンはガント風の線表にして共有しています。タスクレベルではチケットのみです」

---

■ウォーターフォールの開発手法を採用する理由について

い「スマホアプリ開発ではウォーターフォール開発手法を採用されていますが、アジャイル開発のスクラムやカンバンを採用されなかった理由がありますか。あちらには透明ボードにポストイットで作業管理をされているようですが」

 

ち「あれは管理部門の物理カンバンですね。物理カンバンは確かにわかりやすいのですが、開発プロジェクトでは物理で可視化するにはタスク数が多すぎる気がします。また、前職ではアジャイルで開発をした経験もあるのですが、期待する結果を得られなかったということもあり、現在はウォーターフォール開発手法を採用しています。アジャイル開発は今ステークホルダーとの利害調整もやりにくいと感じます。」

---

■エンドユーザとの関係について

い「受諾開発と内製システム開発ではエンドユーザとの関係で変わったことがありませんか」

ち「受託では契約に従って線を引くことができました。いわゆる炎上プロジェクトですら、あくまで契約上の範疇で仕切りやすいという側面があります」

い「現在は自社プロダクトになったので契約で切ることができなくなった。でも、リリースを伸ばすか、リリースする機能を減らす他に選択肢はないと思います」

ち「自社プロダクトは、ビジネスオーナーが顧客となるので線引きがしにくく、すぐにスコープクリープを起こしてしまいがちです。その意味では今の方がプレッシャーがあるのかもしれません」

---

■チーム運営について

い「チーム運営で大切にしていることがあれば教えてください」

ち「プロジェクトチームである前に友人でありたいと思っています。他愛ない話ができる関係であれば問題の火種は雑談の中で早期に解決できますが、ビジネスライクな関係では問題が表面化しないと解決できません。最近の風潮だとブラック企業と言われかねないですが、他社と比べて飲み会やイベントも多いです、友達ですからね。休日も一緒に遊べるくらいのチームの関係を作ることで、馴れ合いではない強い絆が生まれます。チーム同士で対立軸を作らないようにすることも気を遣っています」

も「気軽に雑談できることは大切ですね。相談になってしまうとすでに問題になっていることが多いです。対策案も一緒に持っていかないといけない場合もあります」

ち「相談の前にいかに雑談レベルで予兆を掴めるかが運営の鍵だと思います。その点でも風通しは良いと思っています」

い「コミュニケーションはどのように促進していますか」

ち「チームのコミュニケーションツールはchatworkを使っています。隣同士でも、会話せずにチャットでやりとりしていることも多いです」

い「同じ開発室にいて近い距離にいるのにチャットワークを使う理由は」

ち「作業とコミュニケーションを平行して進められることが最大のメリットだと思います。会話の場合はどうしても数分手が止まってしまいますが、簡単な確認なら、chatworkであれば集中を切らさずに一言返答することができます。実装中にエンジニアに声をかけるのは気を遣いますからね笑」

い「相談したいときに、今、相手に話し掛けて良いか悩まなくていいということですね。」

ち「はい、メンバーを限ったチャットルームを作れば機密的な話もしやすいですし。」

---

■チームマネジメントについて

ち「チームのゴールはかなりストレッチした目標を設定しています。その方が事業もメンバ自身も成長するので」

い「社内の他部門とはゴールをどのように調整していますか」

ち「目標には外から見える部分と見えない部分があるので、見える部分のみで調整しています。その見える部分が、プロジェクトマネージャとして最低限クリアするラインということです。見えない部分がストレッチの部分で、専門職としてのスキルが問われるところですが、その部分は玄人だから見える差なので、仮に未達だったとしても対外的な利害調整では問題ないようになっています」

い「具体的にはどのような差なのでしょうか」

ち「わかりやすい例でいうと、如何にリーダブルでメンテナンスしやすいコードを書くかなどです」

---

■エンジニアと次世代プロジェクトマネージャの育成について

い「プロジェクトマネージャになりたいと意思表示しているメンバはいますか」

ち「います」

い「プロジェクトマネージャやラインマネージャはあまり人気のない職種と言われているので嬉しいです。現在フラットなチーム構成の場合、どのように育成していきますか」

ち「小さなプロジェクトから任せて経験を積んでもらいたいです。特に若い人には、仕事のプロジェクトではなくても、例えばイベントなどでも良いのでマネジメントの立場で最初から最後まで経験することがスタートだと思っています」

い「開発部門の人数から、プロジェクトマネージャの経験を積む場合プレイングマネージャになると思いますがプロジェクトマネージャとして持っていてほしい資質にはどのようなものがあるでしょうか」

ち「プレイングマネージャになりますね。プロジェクトマネージャとして持っていてほしい資質には、最低限タスクの洗い出しと依存関係の把握は完璧にできてほしいです」

い「作業の見積もりも出来て欲しいですね」

ち「作業見積もりは一人で出来て欲しいです。時間との兼ね合いもあるので、全てをというわけにも行かないと思いますが。分担するにしてもそれを判断しなければならないので」

も「これが見えているとマネジメント出来ている、と思えるものはありますか」

ち「人に対してどうコミュニケーションを取るか。メンバが気持ちよく仕事できるようにするか、で、しょうか。あとは、最終的には自分が全部責任を持つという覚悟がプロジェクトマネージャには必要ですね」

---

■プロジェクトマネジメントを別の言葉で表すとしたら

も「最後に、敢えてプロジェクトマネジメントを別の言葉で表現するとしたらどのような言葉が当てはまりますか」

ち「表向きには、時間とスコープとコストです。本心は、プロジェクトに関わる人達のモチベーションがプロジェクトマネジメントだと思います。誰と何を話してゴールまで向かうか。それがプロジェクトマネジメントだと思っています」

---

インタビューが終わって

右から、千歳さん、森實さん、筆者、高柳さん

 

ち「改めてプロジェクトマネジメントについて考える良い機会になりました。とても楽しかったです。どんなに小さな組織やプロジェクトでも、それをマネジメントするには知識と経験が必要だと思います。普段はどうしても経験に頼りがちになりますが、今日話しながら改めてプロジェクトマネジメントついて考えてみて、知識と最近の経験とが融合して私自身が一段階レベルアップできた気がします笑」

ち「ちなみに、iYellではエンジニアや編集・ディレクターなどを絶賛大募集中です。小規模な開発チームで働くことや、不動産領域のプロダクトに興味のある方がいればお気軽にご連絡ください」

 

高柳さん「楽しく描かせてもらいました！千歳さんのお話を聴きながら、これはしっかりとプロジェクトマネジメントを学んだことがある方だなと思いながら描きました。知識と実践のバランスによってたどり着いた考えという感じがして、説得力ある話だったなと思いました」

 

森實さん「面白い企画に巻き込んでもらえてとても嬉しかったです。ワンチームの開発チームとそれを含む会社という単位の組織について、現場感がたっぷりとあるインタビューでした（すぐ後ろに開発チームや管理部門の方々がいらっしゃいました）。また、千歳さんのおっしゃるプロジェクトマネジメントは『誰と何を話してゴールまで向かうか』という、人をキーにしたマネジメントスタイルに共感を覚えるとともに、素敵な会社だなと感じました」

 

い「千歳さんとはツイッターで予めお話しする方向性についてはお伝えてしていましたが、事前に想定していたより多くのテーマについてお伺いすることができたことはプロジェクトマネジメントという共通の知識があったからかもしれません。会話の中で千歳さんが選ぶ言葉、振る舞い、そして表情などからプロジェクトマネジメントや組織のマネジメントの考え方を裏付ける信念を感じることができました。特に印象が残っていることは、メンバの情報を拾い上げる場作りです。エンジニアにより、情報の捉え方、伝え方は様々ですから、場を作ることで収集する機会を増し、拾い上げ続けることを重要視されていることに共感しました」

 

---

ファシリテーショングラフィック

高柳　謙@DiscoveryCoach

企業向け研修コンサルタント兼ファシリテーター。主に企業外の活動でファシリテーターとしての活動を行っていたが、2012年からファシリテーションを用いたチーム（プロジェクト単位での）研修を企業内で実施。研修を現場の課題の解決と実験の場として扱い、研修で失敗して現場に活かすプログラムに組み上げていった。 2015年に5月に独立し、現在は企業研修の内製化のコンサルタントととして研修策定・作成・研修ファシリテーターまでを行っている。またファシリテーターの育成や、チームビルディングとしての対話の場づくりを提供している。

講演：アジャイルジャパン2017、ComebackJapan2017

 

インタビュアー

森實 繁樹@samuraiRed

認定スクラムプロフェッショナル(CSP)、認定スクラムマスター(CSM)、認定スクラムプロダクトオーナー(CSPO) 

講演：XP祭り2016、プロダクトオーナー祭り2016、アジャイルジャパン2017、DevOpsDays Tokyo 2017、ComebackJapan2017

活動：日本XPユーザグループ(XPJUG)スタッフ、侍塊sの侍れっどとしてXP祭りLT司会や各種楽曲制作（「Dear XP」など）

 

企画・インタビュアー

稲山文孝@inayamafumitaka

Project Management Professional(PMI)2003～ 

講演：XP祭り2015、XP祭り2016 、アジャイルジャパン2017、ComebackJapan2017

著書：「アプリ開発チームのためのプロジェクトマネジメント(マイナビ)」「カワイイ後輩の育て方」「ガルパン仕事術」（プロジェクトマネジメント同人誌）など