2012-07-22
Issue Extensions Plugin 0.2.0 Released. #redmine
Issue Extensions Plugin 0.2.0 をリリースしました。
Redmine 2.0.0への対応をしています。
http://www.r-labs.org/versions/208
Download
https://bitbucket.org/changeworld/redmine_issue_extensions/downloads
Changes
Feature #934: Korean translation
Feature #1089: Compatible with Redmine 2.0.0
Comment
Redmine 2.0.0への対応及び韓国語の言語ファイルを提供していただいていたので、それを組み込んでいます。Ki Won Kimさんありがとうございました。
Permalink | コメント(0) | トラックバック(0) | 16:29 
2012-07-16
Free Mind Plugin 1.0.1 Released. #redmine
Free Mind Plugin 1.0.1 をリリースしました。
旧VersionでのRedmine 2.0.0での動作を確認しておりますが、プラグインの管理画面にURLが記載されていなかったので、追記しています。
Download
https://bitbucket.org/changeworld/redmine_free_mind/downloads
Changes
Proposal #3: Append of URL
Permalink | コメント(0) | トラックバック(0) | 11:52
2012-07-14
Joel Test Plugin 0.2.0 Released.
Joel Test Plugin 0.2.0 をリリースしました。
Redmine 2.0.0への対応をしています。
http://www.r-labs.org/versions/203
Download
https://bitbucket.org/changeworld/redmine_joel_test/downloads
Changes
Feature #1083: Compatible with Redmine 2.0.0
Proposal #1084: Refactoring
Permalink | コメント(0) | トラックバック(0) | 16:10
2012-07-13
ムリ、ムダ、ムラをなくす大事な3つの考え方
残業を悪とするチームを作るだけでは全く足りない - Change The Worlds
個別最適化では残業はなくならない - Change The Worlds
残業をしない会社を作るために - GoTheDistance
残業を悪とするチームを作ろう - ひがやすを blog
SIerにてエンジニアの残業を無くす方法 - ledsunの日記
残業をなくすためにすべきこと - ひがやすを blog
と色々なところで残業をしないというスタンスの事が言われてきた。gothedistanceさんは少し別の視点で、人が手作業でやっている作業をITにやらせるというアプローチだが、自分も含めて他の人はチームの成果や生産性をあげるというアプローチを取っている。自分なりの具体的なアプローチについて、以下に記載しよう。
ムリ・ムダ・ムラ
殆どの人はトヨタ生産方式で聞いたことがあると思うが、ムリとは負荷が能力を上回っている状況、ムダとは逆に負荷が能力を下回っている状況、ムラはムリとムダの両方が混在して時間によって表れる状況を指すものだ。
トヨタ生産方式では、ムダを「付加価値を高めない各種現象や結果」と定義しており、ムダなことを排除することで、生産性をあげることも、付加価値を高めることもできる様になる。
例えば、残業をなくす為に生産性をあげるということが良く言われる。プログラマーが生産性をあげる最も近道はプログラミングスキルを向上させることだ。それはコーディングする量が少なく、メンテナンスコストも低く、また自働化*1をすることに繋がる。
が、これらも
- 少ないコーディングで実装できるのに、コーディングを大量にすることはムダである
- メンテナンスをし易く作らず、メンテナンスをし難い様にするのはムダである
- 自働化をせずに、何度もテストやデプロイを手動でするのはムダである
という具合に実は本質的にはムダ取りをしているのだ。
というわけで、ムダの排除を通じて、ムリ、ムラを排除することが大事なことがご理解できたと思う。
どの様にムダを排除するのか？
ムダを排除する為の考え方が以下の3つになる。
- 対象を小さく分割する
- 優先順位を決める
- 流用できないか考える
実例と一緒に説明した方が分かり易いと思うので、個別最適化では残業はなくならない - Change The Worldsから
- ユーザからのシステムのリリース条件として、『同時に○○件の購入要求が来ても、全て××秒以内に応答が返ること』と契約書に書いてある
- しかし、リリースまで後数日なのに、条件を全く満たせていない。このままではユーザから損害賠償として、○億要求される
を例として、説明しよう。
対象を小さく分割する
まず『対象を小さく分割する』から始める。何事も大きく捉えると時間がかかるものである。そこで、まず対象を大きく捉えるのではなく分けて捉えた方が良いだろう。
上記の事例でこの考え方を説明すると、購入要求のフローは大まかに言うと、要求パラメーターのチェック→購入前処理→購入後処理→応答といったものだった。どこに時間がかかっているのかこのままでは分からないので、《要求パラメーターのチェック》、《購入前処理》、《購入後処理》の3つに分割した。そして、同時に○○件の購入要求を投げ、どこに時間がかかっているかを調査した。その結果、3つの部分でかかっている時間は同じ程度ということが分かった。
優先順位を決める
対象を小さくしていけば、いつかは問題個所を見つけることができるが、それでは時間がかかり過ぎてしまう。そこで、大事なことは何から順に対応していくかということだ。
上記の事例でこの考え方を説明すると、3つの部分に分割することができたが、何から順に調べていくかを決める必要がある。周囲の人の作業対象は《購入前処理》だった。《購入前処理》の部分は履歴や商品の親子関係を調べる部分が含まれているので、複雑な仕組みになっていた。そのため、自分以外の人は複雑な部分に時間がかかる処理ロジックがあるのではないか？と考えて調査をしていた。
そこで自分は彼らとは異なる部分を調査することにした。それは一人で調査できる量は少ないので、彼らとは異なるアプローチをした方が良いと判断したためだ。そこで彼らが一番優先度を落としていた《要求パラメーターのチェック》の部分を更に分割して原因を調査することにした。《要求パラメーターのチェック》は前半と後半の2つに分けることにした。その結果、後半部分に処理時間の殆どがかかっていることが分かった。前半と後半はチェックしているパラメータの別はあれどほぼ同じで、大きな差は後半部分にはログ出力関数を呼んでいるということだけだった。ログ出力関数を見てみると、このソースはJavaで書かれていたのだが、Log4Jではなく、自作でファイルにログを出力する処理が書いてあった。そこにはログレベル毎に分ける処理もされておらず、ログレベルを高くしても、全ての処理のログが出力される作りになっていたのだ。つまり、処理時間が長いのはI/O待ちの為だったのだ。こうして、どこの部分が問題になっているか見つけることができた。
流用できないか考える
問題の箇所を見つけても、全て作りかえていては車輪の再発明になるかもしれないし、車輪の再発明を意図していないのであれば、それは時間のムダである。そこで、大事なことは『流用できないか考える』になる。作ることはコストがかかることで、新しく作らなくても要求が満たせるならばそれを優先した方が良い。つまり、新規に開発しなくても良くないか考えるということだ。
上記の事例でこの考え方を説明すると、ここでの要求は「処理時間が短いこと」「必要なログを出力すること」になる。Javaのプロジェクトであり、Log4Jを使えばこの要求は簡単に満たすことができる。それにこの要求はこのプロジェクト固有のコアなものではなく、全てのプロジェクトで必要となるものだ。そこで、共有ライブラリに上記の要求を満たせるものがないか探した。当然の様にLog4Jを使って実装している関数があったので、それをログ関数の部分に流用することで、修正する箇所を最小限（ログ関数の中身のみで呼び出し元には影響なし）、改修の時間も最小限にした。
他への流用
今回ムダを排除する為の考え方として以下の3つをあげた。
- 対象を小さく分割する
- 優先順位を決める
- 流用できないか考える
これは別に改修の時だけ適用できるものではなく、もっと広い範囲に適用できることはすぐに分かるだろう。例えば、新規開発で一気にFacebookの様なサービスを実装しようとするのではなく、まず最初は「いいね！」ができることを目標とする（『対象を小さく分割する』）といったものになるだろう。『対象を小さく分割する』ことができても本来必要のないものを作っていてはそれはムダになってしまう。そこで、本当に必要な機能から順に実装していく必要がある（『優先順位を決める』）。そして、必要な機能だとしても流用できるのに、全て一から作っていてはコストがムダにかかってしまう。新規に開発しなくても要求が満たせるのであれば、そちらを優先した方がムダが少なくなる（『流用できないか考える』）。
さいごに
『ムリ、ムダ、ムラをなくす大事な3つの考え方』を身につけ、日々実践していくことは誰にでもできることだ。
『ムリ、ムダ、ムラをなくす大事な3つの考え方』は特別な能力がなくてはできないものではない。
でもほんの少しだけあなた自身が努力することが必要だ。
この考え方を身につけて、皆さんの現場のムダな残業が減り、皆さんの人生がより良いものになることを祈っている。
Permalink | コメント(0) | トラックバック(0) | 00:54
*1：誤字ではない
2012-07-10
個別最適化では残業はなくならない
以下の昨日の日記にレスをいただいた、ありがとう！
残業を悪とするチームを作るだけでは全く足りない - Change The Worlds
置かれている環境によって考え方や感じ方は異なると思うので、自分の置かれていた環境を書くと
である。
また、こちらにも書いていた回避策を邪道→覇道→王道の順に実施し、残業のない状態にすることもできている。
SIerにてエンジニアの残業を無くす方法 - ledsunの日記
までは分かる。が、ここから繋がる
労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。
の部分に疑問符が浮かんだ。殆どの会社は売上を拡大(＝右肩上がり)しようとする。その現実とは異なる前提での話になっているので、その後の話に腹落ちできなかった。題名にも書いているが、残業をなくすには、経営者視点、中間管理職視点、現場視点等の全ての立場、つまり全体最適化をしないと、最適化されていない立場の人に不満がたまり、うまくいかない。ただ、力関係上、現場の不満は経営者はある程度抑えることができるというか、従わざるを得ない立場に置かれ易い*1ので、その限りではないのが…。
ただ、現場視点だけでの最適化
労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。
では、残業はなくならないのではないかと思う。
残業をなくすためにすべきこと - ひがやすを blog
他から仕事がまわされてくるというのは、その仕事は、時間をかければ誰でもできる付加価値を生み出さない仕事だということです。正直言って、付加価値を生み出さない仕事をしている限りは、残業を減らすことはできません。
自分の仕事が『時間をかければ誰でもできる付加価値を生み出さない仕事』かどうかを自分で判断して決めるというのは手前味噌になると思う。その為、どんな仕事をしていたのか以下に記載するので、そこから読み手に判断して欲しい。『時間をかければ誰でもできる付加価値を生み出さない仕事』だと思ったのなら、そっとブラウザを閉じてもらいたい。『時間をかければ誰でもできる付加価値を生み出さない仕事』ではない、つまり、『時間をかけても誰にでもできる仕事ではない、付加価値を生み出す仕事』だと思ったのなら、『時間をかければ誰でもできる付加価値を生み出さない仕事』をしてなくても残業を減らすには『残業を悪とするチームを作るだけでは全く足りない』と判断してもらえば幸いである。
自分のしていた仕事
デスマーチ（＝火をふいた）プロジェクトに人海戦術チームの次の一手として送り込まれ、対応する仕事をしていた。固有の名称があるのかもしれないが、Aチームと呼ばれていた。具体的な作業としては、デスマーチプロジェクトのアーキテクチャやコアの障害を取り除き、取り除いた後はデスマーチプロジェクトの火が鎮火するまで、拙い部分を一つ一つカイゼンしてプロジェクトの立て直しをする仕事だった。
例えば、対応したデスマーチプロジェクトにはこんなのだった。
- ユーザからのシステムのリリース条件として、『同時に○○件の購入要求が来ても、全て××秒以内に応答が返ること』と契約書に書いてある
- しかし、リリースまで後数日なのに、条件を全く満たせていない。このままではユーザから損害賠償として、○億要求される
という条件で、リリース条件を満たす為にアーキテクチャやソースの問題点を見つけていた。
他にも
という状況下で、○時間以内にリリース作業を抑えられる様にカイゼン点を見つけて、自分の手でそれを証明していた。
前者の例、後者の例どちらもユーザ（と社長と役員）から*2お褒め&追加発注をいただくことができたので、ある意味付加価値を生み出している仕事だったと思う。
前者の例の場合、自分は2時間で問題点を見つけ、無事リリース条件を満たせたが、アーキテクチャ部分を一から全部見直しをかければいつかは問題点にたどり着けるので、時間をかければ誰でもできる仕事だったと思う。ただ、その場合は、次の日がユーザに約束していたリリースの日だったので、時間をかけて自分ではない誰かがやっていたら、会社は損害賠償をしていただろう。
後者の例の場合、そのチームにいた誰も思いつかなかった、というか皆勝手に暗黙のルールと思い込んでいて、その条件を壊して良いものと誰も思わなかったものなので、時間をかければ誰でもできる仕事ではなかったと思う。
この時は残業していたけど、残業代は時間分もらっていたし、ボーナスが同じグレードでは常に最上位に入っていた。
というわけで、私の仕事が『時間をかければ誰でもできる付加価値を生み出さない仕事』だと思ったのなら、そっとブラウザを閉じてもらいたい。『時間をかければ誰でもできる付加価値を生み出さない仕事』ではない、つまり、『時間をかけても誰にでもできる仕事ではない、付加価値を生み出す仕事』だと思ったのなら、『時間をかければ誰でもできる付加価値を生み出さない仕事』をしてなくても残業を減らすには『残業を悪とするチームを作るだけでは全く足りない』と判断してもらえば幸いである。
残業をさせるとそれだけ費用がかかるため、会社としては、できるだけ社員を効率的に働かせ、残業はさせないようにするのが経済的なはずなのに。
とひがやすをさんが書かれている通り、現場レベルではともかく、全体の残業を減らす為には、他の人より生産性の高い人に支援をしてもらった方が良いのだ。他の人より生産性の高い人の残業時間は増えるが、全体の残業時間は減るので、経営視点からすればそれは採用して当然の一手になる。
『時間をかければ誰でもできる仕事ではない』仕事がプロジェクトのデスマーチの原因になっている場合、『時間をかけても誰にでもできない付加価値を生み出す仕事』をしている人もそういったデスマーチプロジェクトを鎮火する為に投入されるので、『時間をかけても誰にでもできない付加価値を生み出す仕事』をしていても残業は必ずしもなくならない。
以下でgothedistanceさんや自分が書いている通り、
残業をしない会社を作るために - GoTheDistance
残業を減らしたいなら全社的な取り組みでなければ効果は出ないというのが、僕の基本的な考え。
残業を悪とするチームを作るだけでは全く足りない - Change The Worlds
これは王道とも言えるものだが、会社の文化を変革することだ。つまり、『残業を悪とする文化を会社の風土にする』ということだ。
だろう。
gothedistanceさんは
と書いているけど、ボトムアップでも可能。というかやった。ただ、最終的にはトップダウンをしてもらったので、厳密には最初からトップダウンにするか、ボトムアップでトップの考えを変えるの2つの方法があるのだろう。
Permalink | コメント(0) | トラックバック(1) | 22:47
