職場の開発を改善した取り組みについて

履歴書や職務経歴書を書くときにまとめたので、ついでなのでここに書いてみる。
職場を改善するためにいろいろやったこと。

【職場の開発を改善した取り組みについて】

顧客からの課題を受けて、課題解決のための取組みをしました。
課題を解決するために、勉強会や書籍などで新しい知識を取り入れ、役に立つ手法を模索しました。

■顧客からの課題
・本番でのバグが多い
・テスト工程の工数が肥大化し、リリーススケジュールが変更になる
・どんなに小さい修正でもリリースまでに3ヶ月かかる

■個人の取組み
□新しい知識の入手
課題を解決するために、勉強会や書籍などで新しい知識を取り入れ、役に立つ手法を模索しました。

□分析
入手した知識をもとに上記の顧客の課題を以下のように分析しました。
・バグが多い
・バグ修正に要する時間と費用のコストが大きい
・バグ修正のコストがスケジュールに対するリスク要因になっている

■チームへの取組み
上記の課題解決のため周囲に働きかけ、以下の取組みを行いました。
□戦略
「バグの修正にかかるコストは、バグが発生してから修正されるまでの時間に比例する」
という法則に着目し、バグ発生から早期に発見、修正する事で課題の解決をはかろうとしました。

□開発手法への取組み
勉強会や書籍で学んだ手法について周囲へ提案を繰り返し行い、開発手法を変えることで開発を改善しようとしました。

・Wモデルの導入
提案の取組みがたまたま開発標準改訂プロジェクトチームの目にとまり、開発手法にWモデルが取り入れられました。
Wモデルは設計段階で、同時にテスト設計を行うため、設計段階のバグが発見しやすくなります。
効果:
Wモデルの導入。

□チームへの取組み
勉強会や書籍で学んだ手法をもとにプロジェクトの中で周囲に新しいやり方を提案し開発を改善しようとしました。

・中間レビューの導入
従来では作業の最後にゲートチェックとしてレビューを行っていました。
しかし、それでは作業者の認識の齟齬が作業の最後まで持ち越され、誤った認識のまま作業を進めてしまうことがありました。
そこで作業者の認識の誤りを早期発見し修正するために、作業途中で中間レビューを実施しました。
「間違ったものを作ってしまう」ムダを削減できました。
効果:
設計、テスト設計工程の工数20%削減
設計時のバグの早期発見。
中間レビューでレビュワーと実際の進捗が把握できたため、スケジュールのリスク要因であるバグ修正のコストを可視化。

・テストコードの導入
ソースコードのバグを早期発見し修正するために、テストコードの導入を推進しました。
実装工程を担当する協力会社の担当者に賛同者を見つけられたため、テストコードを書ける人と一緒に
協力会社全体でJUnitによるテストコード講座を開催してもらうことができました。
今までは単画面テストなどにより手動でテストしていた人もいたのですが、テストコード導入の推進後は
全員がテストコードを書くようになりました。

効果:
実装、結合テスト工程の工数10〜20%削減
実装時のバグの早期発見。
テストコードによるテストの推進と再利用化

フォード生産方式について

フォード生産方式について語ろうと思う。

フォード生産方式の特徴

1.製品の標準化:
ラインアップをT型フォード1車種とし、その派生型のみを生産した。
2.部品の規格化:
規格化し、量産効率を高めた。
3.製造工程の細分化:
ベルトコンベア方式を採用し、流れ作業化した。

ここで注目したいのは3.であり、フォードの生産能率を飛躍的に向上させることに貢献した。
内容は作業マニュアルをつくり、熟練工を不要とした。
「労働者に対して2倍の給与を払った」ことで知られているが、これは最低給与を2倍にしたことを意味する。
一方で高給な熟練工を廃し、工員に対して高速でルーチン作業をこなすロボットとしての役割を求めた。

また、生産マニュアルの整備により、雇ってから即戦力化するまでの期間を短縮した。
そのためラインのスケール拡大に優れていた。

つまりマクドビッグマックを焼くように、どんなぼんくらでも同じように車を作れるようにした。
ここでいうぼんくらとは単純な操作を高速で行う能力が求められる。
複雑な作業を自分で考えて行う必要はない。単純な作業をマニュアルどおり繰り返し高速で行う能力だ。
そういう能力を持つ人材を雇うために2倍の給与を払う事を約束した。
2倍の給与を払っても3倍の生産効率を発揮すればよいという考えだった。


【フォード生産能力の真価の発揮】

フォード生産方式の量産能力は圧倒的であり、第二次大戦中、他の自動車メーカーが飛行機を1日1機つくるのが限界だったのに対し、フォードはベルトコンベア方式により1時間で1機の飛行機を作った。
これは生産能率の高さと、ラインのスケール拡大能力に優れていた点がきいている。

【フォードの製品ラインアップ】
最初はフォードT型1種としていたように、また色が黒しかなかったようにフォードは基本少品種に絞り大量生産する方式だった。
現在のアップルの製品を想像してもらえれば分かりやすいと思う。

【フォードの凋落】
フォードは基本少品種で進めていたため、消費者のニーズの変化と多様化に対応できなかった。
少品種大量生産を生産能率の高さで推し進めてきた当時、アメリカでは自動車は普及段階で誰もが持っている製品ではなかった。
しかし市場が成熟し、自動車が普及してきたとき、差別化し、新たな魅力を消費者に訴求するには多品種少量生産において高い生産能率を発揮することが求められたが、フォードは応えられなかった。


【転機】
80年代、オイルショックなどによりアメリカの自動車メーカーは凋落した。
そしてアメリカ本土の自動車シェアは日本メーカーにより蚕食された。
なぜアメリカメーカーは負けたのか?なぜ日本メーカーは躍進したのか?
この理由が研究された。

【後継者】
トヨタ生産方式が研究され、リーン生産方式としてまとめられた。
生産マニュアルどおりに高速でルーチン作業を行う単能工が否定され、自律的に生産方式を改善する多能工が評価された。
ボトムアップのほうが多品種少量生産に適しており、多品種少量生産が行えるならば、顧客ニーズの変化に合わせて新しい製品を短サイクルで投入できることが評価された。


【このお話の教訓】
自動車が十分に普及していなかったころにはフォード生産方式は有効だった。
市場の需要が十分に大きく、供給を上回っていたからだ。
いかに安価に大量に自動車を供給するかが大事だった。

自動車が十分に普及した後はフォード生産方式は有効ではなかった。
市場の需要は一服し、消費者の求めるニーズは高度化し、対する供給側はそれを奪い合わなければいけなかった。
いかに消費者の求めるものをすばやく市場投入できるかが大事だった。

フォード生産方式が否定され、トヨタ生産方式が賞賛される過程で否定されたものと賞賛されたものがある。

・否定されたもの
少品種大量生産
生産マニュアルとそれにしたがって動く単能工
純化された作業

・賞賛されたもの
多品種少量生産
自律した多能工
自働化された作業

【蛇足】
HとかNとかFとか、トヨタ生産方式といいながら開発標準整備するのはいますぐやめたほうがいいと思う。
結局少品種大量生産はできなかった。

あと携帯向けカードゲーム市場もすでに競合が乱立した成熟期に入っているんじゃないか?

かっこいい発表資料の作り方講座

かっこいい発表資料の作り方講座


ニコニコ超会議やGLTで発表した資料の最終版です
今日はこの資料を発表してきました。
http://bit.ly/TZNlvD




まず、ネタとコンセプトを決めます。

私はWebサービスを作った経験を前に出そうと思っていました。

次にコンセプト、というか持って帰って欲しいメッセージを決定。

「勉強会でインプットしてばかりじゃなくてもっとアウトプット(実践)しようぜ!」
を選択。ほかに
「スマフォ向けサービスって簡単に作れる。君も作ろうぜ!」
「新しい言語に挑戦するのは難しくない。もっとトライしようぜ!」
というのがありました。

これと前後して使えそうなネタをブレインストーミングして紙に書きだしておくと、ネタが出せます。


次に大雑把な構成を考える。
漫画で言うネームかあらすじにあたる部分。

今回だと

1.勉強会で学んだらアウトプットしたくなるよね!
2.開発手法を学んだから、開発手法をアウトプットだ!
3.ということでサービス開発だ!
4.開発手法をこんな風に使ったよ!
5.サービス開発して素振りしたあとに振り返った結果

というような流れになりました。
実際には上を書いてから、後で直すので構成は変わります。



次にスライド単位に書く内容(ネーム)を書き出します。

これはテキストエディタなどで書きます。

必ずしも内容がスライドと1対1で対応しているわけではありません。
そこまで拘る必要もありません。

とりあえず書いてしまってください。




次にパワーポイントを起動して、上のネームにそって書きます。

このとき注意するのは、この段階では図を入れないでください。

レイアウトにはこだわらず、スライドに盛り込む内容を書いてあるかだけに注意して書きます。

これが下書きです。


次に下書きにそって読みます。

読むと違和感を感じると思うので、それにあわせて内容を変えます。

内容が整ってきたら、強調したい部分や説明したい部分に図や絵を入れます。


入れながら読む、修正、読むのサイクルを繰り返します。


そうするうちに資料が完成します。




発表資料作りに必要な期間

ネタ出ししてネタを決めてコンセプト決めて、ネームをきるまででだいたい2日。6時間くらい。

さらに下書きを書いて発表資料が完成するまでに2日、6時間くらいで完成します。


だから1週間前くらいにオファーを受けても私の場合は発表資料が作れます。


こうしてみると意外と簡単に作れることがわかります。

アジャイルをするのに必要な技術スキル

アジャイルにはメンバーの高いスキルが必要なんでしょ?」

という企業は大抵レベルが低い。

という話についてこの前友達と話した。



「じゃぁアジャイルに必要なスキルって何なの?」

ツールや手法をまわすスキル?TDD?CI?


いずれも必須ではない。なくてもアジャイルはできる。
(あったほうが絶対いいよ、とは言われるが)


では何が必要か。

マインドはこの際問わないものとする。

自分でタスクを選ぶ能力もアジャイルをまわす中で育つものとする。

では技術スキルは何が必要か。


顧客の「こういうのほしいんだよね〜」というふわふわした要求を受け取って、プロトタイプやデモを見せながら、
「自分ひとり」で「分析、設計、実装、テスト」ができること。

当然DBは自分でCreate文書けるし、「なぜここは正規化崩しているの?」ときかれてもすらすら答えられないといけない。

テストだって正常系も異常系も自分で設計して書けること前提だ。


という見解を示したときに全員にできるか?と聞いたら全員が「できる」一部は「やったこともある」という回答だった。

そこでさらに質問。「では会社の同僚はできるか?」

ここは3つに分かれた。

「できないやつはうちにはいません」
「一部はできる」
「分業すればできるが、一人では無理だ」

一番上はアジャイル実践済みの会社。
下2つは残念系SIer。弊社も一番下かな。


御徒町さんが( http://bit.ly/yvAYPf )でふれているけどSIerには上から下まで出来る人材はもうほとんどいない。

だから平然と「アジャイルにはメンバーの高いスキルが必要なんでしょ?」と発言できる。

「設計からテストまで」を行える能力はすでに「高い能力」に見えるくらい平均値が低下している。


SIerはこういう。

「分業しているから専門家ばかりなんです」

オーケー。分かった。

だがそれには2つの問題がある。

・その方法だと開発の金額が下がらないが、その額を出せる顧客を継続的に確保し続けられるのか?
・専門家というほど、高いスキルを持っているか?特に金額に見合う、という意味で。


特にオチもない。

政治的な「真の原因」

バグの原因の見える化プロジェクトというのがあって、バグの原因の分類機能というのが必要になった。

バグの原因を分類するにも元ネタが必要だったんだけど、「なぜを5回繰り返す」なぜなぜ分析を3年運用しているチームから「うちのチームでなぜなぜ分析の真の原因をパターンごとに類型化しているテンプレートがあるので、それを提供しよう」という申し出があった。

それなりに期待していたんだがそれを見て唖然とした。

真の原因がほぼ「ほげレビューの未実施/不足」「ふがテストの不備」「ふーばーシステムの有識者の不足」しかなかった。




なぜそんなものが真の原因になっているかというと、「バグがおきました。『真の原因』がこれこれです。つまり『開発標準を遵守していなかったこと』が元凶だったのです。でも大丈夫!弊社では『開発標準遵守への取り組み』としてこれこれこのようなことを推進しており、プロジェクトの遵守比率もこれこのとおり上がっております!つまりこのようなバグは将来根絶できるでしょう!!!」とお偉いさんが顧客に説明するためにある。


ところが報告書を読んでいると、「もともと2週間あったA機能の結合テストは、進捗遅れにより4日まで削られている。そこで残業と増員(余剰人員と新人)により遅れを挽回します!」という結合テストの中で「結合テストの不足」が発生したことがわかっている。

ついでに結合テストのテスト設計するのに必要な設計書も中身はひどいものだった。

これに対する真の原因は「結合テストの不足」で、対応策は「結合テストレビューの徹底」でいい、というのは明らかにおかしいし、開発標準を徹底したところで前工程が遅れたり質が低かったりするのは回避困難であるように思える。


なお、リグレッションテストの自動化とか入れるべきだと思うがそれはしないそうだ。

理由はテストにかける工数が減ることは売上減につながるから、だそうで。

「社内勉強会は好きだが社外勉強会は嫌い」という人にあって

「社内勉強会はよく開催する。
 でも社外勉強会は何の意味があるのか分からないから行っていない。だってあれほとんど一般論で『明日からはじめるには具体的にどうすればいいのか』って話がないじゃない」

という人にあって、そのときは波風立てたくなかったので流したが、それについてつらつらと。



社内勉強会は好きだけど、社外勉強会が嫌いな人っていうのは、要するに「知識のローカライズ」する作業を嫌っているんだと思う。

野中郁次郎先生のSECIモデルにある「抽象的な形式知を個人の暗黙知に変換する」という作業があって、あれはモデル化された考えを講義などで聞いて、自分の中で落とし込んで、さらに自分の現場に展開するにはどうすればいいか、という話をさしていたように思う。



そもそも『明日からはじめるには具体的にどうすればいいのか』というのは話す側が相手のコンテクストを理解しなければいけないんだけど、それを理解するのは難しいし、金ももらわずにそこまで付き合ってくれる人はまれだから、本当に改善したいと願うなら自分でやるしかない。



私は社内勉強会を完全否定しているわけではないが、社内勉強会って要するに内輪の知識しか出てこないので、それ一辺倒だと局所最適解にとどまってしまうんじゃないかと思う。

チームを信頼するということ

「マネージャーがチームを信頼すると、どんなメリットがあるの?」

といわれたので色々考えてみた。

この場合マネージャーって言うのは部長クラス以上のマネージャークラスで、チームって言うのはスクラムチームみたいな10人くらいのチームだ。


・まず信頼するって何?

ここでは権限委譲する、ということにしておく。
報告さえすれば、チームに割り振られたタスクを消化している限りは何をしてもいいということ。

例えばだけど、3ヶ月でプロダクトをリリースしようぜ、というタスクがあって、それを順調にこなしている限りは定時で帰ろうが、あるいはJenkinsを導入しようが、ゆっくり神社を建立していようが、あるいは新たな追加機能を提案してみようが、かまわないということ。

タスクをこなしている限りは選択はチームの自由だ。

もちろんベロシティを消化して上司の覚えをめでたくしてもいい。


・信頼するとなにがいい?

ここでは話をプラクティスやツールの導入にしぼってみる。

割り振られた成果は出している。
だからチームはさらに挑戦してみることにしたとしよう。
Jenkinsによる継続的インテグレーションと自動テストだ。

理由はなんだっていい。手動テストがだるいからかもしれないし、チームのビルド職人が「転職してぇ」と不穏な発言をしだしたからかもしれない。

Jenkinsと自動テストへのチャレンジは成果を維持した状態でチームが持ち出しで試行する。

うまくいけばチームの成果は上がる。うまくいかなくてもコストはチームの持ち出しだから会社は困らない。


・信頼しないとできない?

信頼すること=権限委譲すること
という定義だから、信頼しない=権限委譲しない、ということになる。

するとチームはたとえばJenkinsを導入するために、稟議書を書いて提案内容をパワポにまとめて、何回もプレゼンして、偉い人に説明しないといけない。
とにかく面倒くさい。
そしてそれがリジェクトされるかもしれないし、偉い人に生意気なやつだとにらまれるリスクもある。

そう考えるとチャレンジしようとする人は増えないだろう。


・研究チームでやればいい話だろう?

研究チームでやる場合、制約条件がある。
 *「次に研究すべきもの」を研究チームが理解していないといけない。

 *会社は研究対象に予算をつけなければいけない。それは「前払い」だし、前払いするからには審議する。審議するからにはカジュアルにチャレンジできない、どうしても「実績のあるもの」に寄ってしまう。

 *失敗したものにも費用を払わなければならない。

 *研究しても現場にローカライズしなおさないといけない。せっかく社内に展開しようとしても、「社内で使ってもらえない」では意味がない


・会社がチームを信頼することのメリット

信頼することにより現場でのチャレンジが活発化する。
現場でのチャレンジが活発化すると「すでにチームで成果が出ているもの」「現場で使えるようローカライズされたもの」を「後払い」で手に入れることができる。


・では研究チームを解散するべきか?

チームを信頼するやり方では、チームが「いま必要なもの」を優先的に手に入れようとする。だから戦略的に会社が注力しようとしているものを主体的に研究することはできない。
戦略的に技術投資したい部分に関しては研究チームでやらせるべきだと思う。


・そんな余計なことしている暇があったら仕事しろ。俺の若いころは土曜も日曜も(以下略)

自分の努力が自分の目に見える形で返ってきたほうが、士気があがり、労働効率は高まる。
だから、各人に裁量を与えて自分で研究させたほうが、上で万事決めて割り振るより効率的だと思う。