ブログ変えてました

知っている人は知っていて、知らない人には突然ですが、「はてなダイアリー」から「個人ブログ」へ移転してました(←過去形)。

こちらでの投稿はそのまま残しておきますので、続きの投稿が見たい方は

新ブログ:Change the World!(http://changesworlds.com/)

でご覧ください。これからもお付き合いいただければ、幸いです。

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さんありがとうございました。

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

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

ムリ、ムダ、ムラをなくす大事な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つの考え方』は特別な能力がなくてはできないものではない。
でもほんの少しだけあなた自身が努力することが必要だ。

この考え方を身につけて、皆さんの現場のムダな残業が減り、皆さんの人生がより良いものになることを祈っている。

*1:誤字ではない

個別最適化では残業はなくならない

以下の昨日の日記にレスをいただいた、ありがとう!
残業を悪とするチームを作るだけでは全く足りない - Change The Worlds
置かれている環境によって考え方や感じ方は異なると思うので、自分の置かれていた環境を書くと

  • 残業すればしただけ残業代がでる(=サービス残業はない)
  • 従業員が多い(wikipediaの定義では大企業になる)

である。
また、こちらにも書いていた回避策を邪道→覇道→王道の順に実施し、残業のない状態にすることもできている。

SIerにてエンジニアの残業を無くす方法 - ledsunの日記

ここで考えるのはSIerにてエンジニアの残業を無くす方法です。残業を無くすには労働生産性を上げればよい。

までは分かる。が、ここから繋がる

労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。

の部分に疑問符が浮かんだ。殆どの会社は売上を拡大(=右肩上がり)しようとする。その現実とは異なる前提での話になっているので、その後の話に腹落ちできなかった。題名にも書いているが、残業をなくすには、経営者視点、中間管理職視点、現場視点等の全ての立場、つまり全体最適化をしないと、最適化されていない立場の人に不満がたまり、うまくいかない。ただ、力関係上、現場の不満は経営者はある程度抑えることができるというか、従わざるを得ない立場に置かれ易い*1ので、その限りではないのが…。
ただ、現場視点だけでの最適化

労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。

では、残業はなくならないのではないかと思う。

残業をなくすためにすべきこと - ひがやすを blog

他から仕事がまわされてくるというのは、その仕事は、時間をかければ誰でもできる付加価値を生み出さない仕事だということです。正直言って、付加価値を生み出さない仕事をしている限りは、残業を減らすことはできません。

自分の仕事が『時間をかければ誰でもできる付加価値を生み出さない仕事』かどうかを自分で判断して決めるというのは手前味噌になると思う。その為、どんな仕事をしていたのか以下に記載するので、そこから読み手に判断して欲しい。『時間をかければ誰でもできる付加価値を生み出さない仕事』だと思ったのなら、そっとブラウザを閉じてもらいたい。『時間をかければ誰でもできる付加価値を生み出さない仕事』ではない、つまり、『時間をかけても誰にでもできる仕事ではない、付加価値を生み出す仕事』だと思ったのなら、『時間をかければ誰でもできる付加価値を生み出さない仕事』をしてなくても残業を減らすには『残業を悪とするチームを作るだけでは全く足りない』と判断してもらえば幸いである。

自分のしていた仕事

デスマーチ(=火をふいた)プロジェクトに人海戦術チームの次の一手として送り込まれ、対応する仕事をしていた。固有の名称があるのかもしれないが、Aチームと呼ばれていた。具体的な作業としては、デスマーチプロジェクトのアーキテクチャやコアの障害を取り除き、取り除いた後はデスマーチプロジェクトの火が鎮火するまで、拙い部分を一つ一つカイゼンしてプロジェクトの立て直しをする仕事だった。
例えば、対応したデスマーチプロジェクトにはこんなのだった。

  • ユーザからのシステムのリリース条件として、『同時に○○件の購入要求が来ても、全て××秒以内に応答が返ること』と契約書に書いてある
  • しかし、リリースまで後数日なのに、条件を全く満たせていない。このままではユーザから損害賠償として、○億要求される

という条件で、リリース条件を満たす為にアーキテクチャやソースの問題点を見つけていた。
他にも

  • ユーザからの要望としてリリース時間を『○時間以内に抑えること』と言われている
  • しかし、リリースするサーバの台数が増えてきたので、○時間以内に抑えることはムリ(とそのチームの人たちは思っていた)

という状況下で、○時間以内にリリース作業を抑えられる様にカイゼン点を見つけて、自分の手でそれを証明していた。
前者の例、後者の例どちらもユーザ(と社長と役員)から*2お褒め&追加発注をいただくことができたので、ある意味付加価値を生み出している仕事だったと思う。
前者の例の場合、自分は2時間で問題点を見つけ、無事リリース条件を満たせたが、アーキテクチャ部分を一から全部見直しをかければいつかは問題点にたどり着けるので、時間をかければ誰でもできる仕事だったと思う。ただ、その場合は、次の日がユーザに約束していたリリースの日だったので、時間をかけて自分ではない誰かがやっていたら、会社は損害賠償をしていただろう。
後者の例の場合、そのチームにいた誰も思いつかなかった、というか皆勝手に暗黙のルールと思い込んでいて、その条件を壊して良いものと誰も思わなかったものなので、時間をかければ誰でもできる仕事ではなかったと思う。

この時は残業していたけど、残業代は時間分もらっていたし、ボーナスが同じグレードでは常に最上位に入っていた。

というわけで、私の仕事が『時間をかければ誰でもできる付加価値を生み出さない仕事』だと思ったのなら、そっとブラウザを閉じてもらいたい。『時間をかければ誰でもできる付加価値を生み出さない仕事』ではない、つまり、『時間をかけても誰にでもできる仕事ではない、付加価値を生み出す仕事』だと思ったのなら、『時間をかければ誰でもできる付加価値を生み出さない仕事』をしてなくても残業を減らすには『残業を悪とするチームを作るだけでは全く足りない』と判断してもらえば幸いである。

残業をさせるとそれだけ費用がかかるため、会社としては、できるだけ社員を効率的に働かせ、残業はさせないようにするのが経済的なはずなのに。

とひがやすをさんが書かれている通り、現場レベルではともかく、全体の残業を減らす為には、他の人より生産性の高い人に支援をしてもらった方が良いのだ。他の人より生産性の高い人の残業時間は増えるが、全体の残業時間は減るので、経営視点からすればそれは採用して当然の一手になる。

『時間をかければ誰でもできる仕事ではない』仕事がプロジェクトのデスマーチの原因になっている場合、『時間をかけても誰にでもできない付加価値を生み出す仕事』をしている人もそういったデスマーチプロジェクトを鎮火する為に投入されるので、『時間をかけても誰にでもできない付加価値を生み出す仕事』をしていても残業は必ずしもなくならない。

以下でgothedistanceさんや自分が書いている通り、
残業をしない会社を作るために - GoTheDistance

残業を減らしたいなら全社的な取り組みでなければ効果は出ないというのが、僕の基本的な考え。

残業を悪とするチームを作るだけでは全く足りない - Change The Worlds

これは王道とも言えるものだが、会社の文化を変革することだ。つまり、『残業を悪とする文化を会社の風土にする』ということだ。

だろう。

gothedistanceさんは

ボトムアップでは無理。トップダウンでしか成し遂げられない。

と書いているけど、ボトムアップでも可能。というかやった。ただ、最終的にはトップダウンをしてもらったので、厳密には最初からトップダウンにするか、ボトムアップでトップの考えを変えるの2つの方法があるのだろう。

*1:自分みたいに反発する人は少数だろう

*2:社長と役員とユーザ以外からはどうだったかって? 言わせんなよ、そんなこと。口にも憚れることなんだから

残業を悪とするチームを作るだけでは全く足りない

残業を悪とするチームを作ろう - ひがやすを blog
仰っていることに対しては概ね同意。
でも大事なことが欠けている。それは『残業を悪とするチームを作るだけでは全く足りない』ということだ。

残業を悪とするチームを作った後に起こる事象

前提条件として、ひがやすをさんも書かれている通り、社員の稼働率が売り上げに直結する所謂SIerの場合の話。

仕事の質に誇りを持ち、残業を悪とするチームを作ることは、あなたにもできます。

仰る通り、『仕事の質に誇りを持ち、残業を悪とするチームを作ることは、あなたにもできます』は正しい。色々苦労をするだろうけど、残業を悪とするチームを作り、チームの生産性も他のチームより高くすることはできる。しかし、残業をしなくてすむ様な生産性の高いチームを作ったら上司からの圧力はかからないか?と言うとその答えはNoだ。
殆どの人は体感していると思うが、仕事はできる人に優先的に回されるからだ。あなたのチームが他のチームの2倍、いやそれ以上の生産性を発揮したとしよう。
周囲(上司含む)があなたのチームの力を理解していない時なら残業をせずに帰れるだろう。しかし、一度チームの実力が周囲に知れ渡り、理解されれば、起こることは作業の割当だ。
何故ならば、金勘定が出来る人(管理職は最低でもこの程度はできるだろう)は全体の残業時間を減らすには生産性の高い人(チーム)に仕事を割り振る方が効果があることを知っているからだ。
これはチームリーダーだけに起こるものではなく、多くの部下(=多くのチーム)を抱える部署長の様な立場になっても同じで、チームリーダーでは、他のチームの作業を割当られるが、部署長では、他の部署の作業を割当てられるということに変わるだけだ。

残業を悪とするチームを作った後に起こる事象の回避策

回避策と書いているが、Sliver Bullet(銀の弾丸)があるわけではない。ひがやすをさんも以下の様に書いている通り、簡単なことではない。

この問題を解決するには、自分たちのチームを作るのがおすすめ。会社や上司を変えることは難しいけど、仕事上のチームを作ってその中は残業を悪とする文化にすれば良い。

ただ、策が全くないわけでもない。

まず、1つ目。これは王道とも言えるものだが、会社の文化を変革することだ。つまり、『残業を悪とする文化を会社の風土にする』ということだ。これをするには情熱(莫大なエネルギーと言い換えても良い)もさることながら、それ以外にも政治力といった、大抵のエンジニアが必要なスキルとは思わないスキルが必要になる。経験した自分が言うのもなんだが、正直かなりしんどいのであまりお勧めしない。
次に2つ目。これは王道に対する邪道と言えるものだが、成果を喧伝しないということだ。つまり、『チームの生産性が他のチームよりあがり、残業しなくても良くなっても残業する』ということだ。残業が悪なのに残業をするとは此れ如何に?と思うかもしれないが、残業をしなくなるとすぐに成果(他のチームより生産性が高い)が周囲に知れ渡ってしまう。そうなると、上記にあげた様に大量の仕事を振られることになり、生産性をあげる前よりも帰宅するのが遅くなるという事態になることがある。というかなった。その事態を避ける為に、自分たちの作業が終わったら、他のチームの作業を自分から積極的に手伝う。手伝うというとフォローの様に聞こえるが、これは自分たちをその作業にアサインし、責任も自分たちが持つということだ。これをすると、残業せずにさっさと帰っているチームという様に見えず、かつ他のチームを手伝っているので、周囲からの眼も優しいものになる。本質(残業を悪とする文化を会社の風土にする)に対しては何もしていないが、すぐに実行でき、チームも不幸にしなくてすむという意味ではかなり良い策だった。
最後に3つ目として覇道とも言えるものがあるのだが、ここにも書けない様な内容の策だ。

といった様にただ単純に『残業を悪とするチームを作る』だけではその先に待ち受けるものは以前よりも酷い地獄なので、その後の回避策も考えて行動すると良いだろう。回避策も込みで提案すれば、会社の異なる(所謂パートナー)人が含まれるチームでも十分に行えるので、そこの辺りも見越して導入してみると良いだろう。

あわせてよみたい。

残業をしない会社を作るために - GoTheDistance