肩こりに効くアイテム その1
エンジニアの職業病といえば肩こり。
over35エンジニアには辛い症状でしょう。
自分もご多分に漏れず酷い肩こり持ちです。
肩こりを根本的に治す手立ても考えて行きたいところですが、今回は手っ取り早く役に立つアイテムを紹介。
ツイート
ツイート
2011年の振り返り？
・・・を今年もしようと思ったのですが、いろんなことがありすぎて全く整理がしきれませんでした。
２０１１年のことはたっぷり時間をかけて考えていこうと思います。
ただ、２０１１年という年の一瞬一瞬は他の年より明らかにいろんなことを考えさせられ、自分を成長させたというのは間違いないと思います。
とりあえず、今年一番よかった本だけ
この本は自分の人生を変えました。といえる一冊。
たまたま本屋で見つけた本でジャケ＆目次見て買いました。
なぜ人は退屈するのかというだけでなく「楽しむ」とは？「人生」とは？「仕事」とは・・・倫理学だけでなく、哲学、経済学その他諸々から学問的に追っています。
ツイート
リファクタリング 不吉な臭いに関するツィートまとめ④
リファクタリング 不吉な臭いに関するツィートまとめ①
リファクタリング 不吉な臭いに関するツィートまとめ②
リファクタリング 不吉な臭いに関するツィートまとめ③
続きです。。。
#refactoring 不吉な臭い⑭「一時的属性」・・・インスタンス変数の値が特定の状況でしか設定されない。「isNull」などの属性がいい例。対処策は「クラスの抽出」「ヌルオブジェクトの導入」。Specializeなクラスにする。
@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑰「不適切な関係」・・・例）「Aクラス」を利用するのに「Bクラス」のフィールドを知らないと使えない。あるクラスを利用するのにあるAPIを必ず使わないといけない・・・など 対処策）「メソッドの移動」「フィールドの移動」@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑱「クラスのインタフェース不一致」・・・似た処理をしているのにメソッド名などが違う。 引数のみが異なるメソッドは「メソッド名の変更」。また「メソッドの移動」でインタフェイスを合わせる。「インタフェイスの抽出」やコンポジションの利用も有効。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑲「未熟なクラスライブラリ」・・・クラスを全くいじれないならデコレートパターンやアダプタパターンなどが使えるが、修正できるクラスならクラスを修正する。@pilgrim_reds木目沢康廣
ツイート
リファクタリング 不吉な臭いに関するツィートまとめ③
リファクタリング 不吉な臭いに関するツィートまとめ①
リファクタリング 不吉な臭いに関するツィートまとめ②
つづきです。。。
#refactoring 不吉な臭い⑨「基本データ型への執着」・・・変数＝基本データ型と思い込んでいる。振る舞いが必要になった場合、「オブジェクトによるデータ値の置き換え」を適用。また、データがタイプコードを表している場合enumで置き換える。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑩「スイッチ文」・・・基本はenumを使用できる。EffectiveJava(第二版)第六章が参考になる。 http://p.tl/lhQd@pilgrim_reds木目沢康廣
「⑪パラレル継承」は継承を使わないため省略しています。
#refactoring 不吉な臭い⑫「怠け者クラス」・・・リファクタリングの結果、不要になったクラスがある。その場合は「クラスのインライン化」を行って他のクラスに組み込み元のクラスを削除する。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑬「疑わしき一般化」・・・（症状）たいした働きをしないクラス。使われないパラメータ。わかりにくい抽象的な名前のメソッド。テストケースでしか使われないメソッド。使われないgetter/setter。NotSpecializeなクラス。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑬「疑わしき一般化」・・・（対処法）使われないパラメータは「引数の削除」。わかりにくい抽象的な名前のメソッドは「メソッドの変更」。@pilgrim_reds木目沢康廣
ツイート
「バグ」と「リファクタリング」と「技術的負債」について
自分の書いたコードにバグがあった。
コードは何ヶ月か前にかかれたものだが、今見返してみるととてつもなく・・・汚い。
バグが出て当たり前のようなコードだ。
バグはSQLの記述ミスだった。
完全にケアレスミスだが、注意深く書いていれば防げたと後悔している。
ただ時間が経ってから考え直してみると、ただ注意深くと言っていても根本的な解決にはならないのではと思った。
根本的な解決法は何かと考えた結果、やはりUnitテストだろうと思った。
ソースを書いていた当時はどうしてもテストを書く時間を確保できず、ほとんどUnitテストを書かなかった。
こういう行為を技術的負債というそうだ。
以前保守屋だったときはあれほど、人の書いたコードにテストがないことを憤っていたのに、同じことをしてしまったのだ。
技術的負債は納期との兼ね合いなどでどうしても発生するものだ（そして溜まっていく。だから「負債」）。しかし、それは早く返済しないといけない。
それがよくわかった。
それからテストを書く時間がなかったと言ったが正確にはテストが書けなかったというほうが正しいかもしれない。
ソースを書いていた当時はわからなかったが、リファクタリングを学んだ今だから言えることがある。
Unitテストはまずメソッドに一つ以上の役割りを持たせてしまうと書きづらい。
よく考えると当然だが、あるメソッドを検査するのに二つも三つも結果のパターンがあればテストもそれだけ複雑になるし、メソッド名も曖昧だからテストを書くのにソースを読む必要があるのだ。
だから、テストを書く前提として、テストが書ける程度のソースの書き方を知る必要があったのだ。
もちろん完璧にリファクタリングをしていては時間がなくなってしまう。が、技術的負債が負担にならない程度にリファクタリングしなければならない。
ちなみにリファクタリングは設計の際にも必要になる。深いモデルはリファクタリング後に明らかになることが多いとDDD本に記載がある。
ということで、時間の合間を縫ってこのコードのリファクタリングを始めている。さすがにこれは臭いすぎるという箇所と、しょっちゅう修正している箇所からだ。
もともとforやwhileなどはなかったものの同じメソッド内に大量ifがあったり(長すぎるメソッド)、重複したコードが大量にあった。引数も多すぎるものがあったりした。
リファクタリング実行後一番効果的だったのがenumの適用だ。(リファクタリング本にはないパターンだが、effective javaに詳細あり)。これで劇的に変わった。
enumにする前はあちこちのクラスに似たコードやenumの項目分のifがあったりしたがenumを適用したクラスに責務がきちんと集まってきた。
また、リファクタリング開始当初はメソッドの抽出が多かったが小さいメソッドが多くなると別の臭いが発生する。
属性操作の横恋慕が目立ってきたり、一つのクラスにまとめられそうなデータの群れが出てきたり。。。
ただ、あまり時間もかけられないので兼ね合いはとらないといけない。
とは言え、やっとテストが書きやすいぐらいにはなってきた。
この本で初めて「技術的負債」という言葉を知った。他にもいろいろ考えなくてはいけない内容が納められている。
「プロのプログラマとは？」は必ず読むべし。
ツイート
リファクタリング 不吉な臭いに関するツィートまとめ②
http://pilgrim-lifestyle.com/?p=511
続きです。
#refactoring 不吉な臭い⑤「変更の発散」・・・１つのクラスがさまざまな理由で変更される。リファクタリングのきっかけともなる臭い。SRP単一責任原則。「クラスを変更する理由は一つ以上存在してはならない。クラスの責務（役割）は一つでなければならない。」@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑥「変更の分散」・・・ある１つの変更の理由で複数のクラスを変更しなければならない。リファクタリングのきっかけになる臭い。こちらはよく臭う。@pilgrim_reds木目沢康廣
プログラムの変更時が主にリファクタリングの動機につながる。よって変更の発散・分散がリファクタリングの基本。
#refactoring 不吉な臭い⑦「属性、操作の横恋慕」・・・他のオブジェクトのgetを何度も呼び出している。変更の分散につながる不吉な臭い。対処策は「メソッドの移動」。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い⑧「データの群れ」・・・属性・引数・内部変数などでデータの集まりが存在する。変更の発散につながる不吉な臭い。属性の場合は「クラスの抽出」を適用。@pilgrim_reds木目沢康廣
ツイート
リファクタリング 不吉な臭いに関するツィートまとめ①
一日一つぶやきでリファクタリング本の不吉な臭いの章(第三章)についてつぶやいていました。そのまとめです。
#refactoring 不吉な臭い②「長すぎるメソッド」・・・長すぎるメソッドは「変更の発散」につながる不吉な臭い。「メソッドの抽出」が基本。コメントの代わりにメソッド名をわかりやすく。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い②「長すぎるメソッド」・・・一時変数や引数が残ってしまう場合、「メソッドオブジェクトによるメソッドの置き換え」→発想が面白い、条件分岐やループには「条件記述の分解」@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い③「巨大なクラス」・・・大きすぎるクラスは「変更の発散」につながる不吉な臭い。対処策の基本は「クラスの抽出」と「インタフェースの抽出」。@pilgrim_reds木目沢康廣
#refactoring 不吉な臭い④「多すぎる引数」・・・引数の数が多すぎるのは「変更の発散」につながる不吉な臭い。対処策１つ目は「メソッドによる引数の置き換え」。その引数が、あるメソッドの戻り値でそのメソッドが中から呼べるなら引数を削除しメソッド内部で呼び出す。@pilgrim_reds木目沢康廣
ツイート
もしSIerのエンジニアがドラッガーの「マネジメント」を読んだら
流行は去ったけどドラッガーの「マネジメント」からSIer事業を考える
もう流行ってないけどドラッガーの「マネジメント」からSIer事業を考える
続きです。
SIer事業というのは「顧客のイノベーションを実現するというのを手助けする」ことであるということであれば、私たちにできることが明確になりそうです。
それはイノベーションを実現するためにITを活用するとともに顧客のリスクをできるだけ軽減すること。
そのために必要なことは・・・
- 実現するための技術を提供すること。
- 柔軟に機能の変更・追加・削除ができること。
- 柔軟にプロジェクトの拡大・縮小・撤退ができること。
１は当然の話しでやはりイノベーションを実現するための技術はきちんと追い求めていくべきですよね。
2についてはより大きくビジネスが関わってくる部分だと思いました。
新しいことをやろうと思えばビジネス上機能の変更・追加・削除は当然のようにでてくることだと思います。
最近ではアジャイルがこれに対応するものとして主流になりつつありますが、プロセスだけでは根本的に解決するとは思えません。
なぜなら、一つの変更で変更箇所をあちこち探したり、修正漏れがあったりすれば結局かかる時間の膨大さは変わらないからです。
TDDでテストをきちんと書いていてもそれは変わらないと思います。
もっと早くもっと少ない手順で機能を変更・追加・削除できることが大事ではないでしょうか？
それを可能にするのが「顧客のビジネスを理解してそれをソースコードのレベルまで落とすこと。」
もっと早くもっと少ない手順にするには究極には「変更箇所」を一箇所・ひとつのクラスにすること。
機能の変更・追加・削除の理由は「ビジネス上の理由」が必ず存在します。
とすればビジネスに沿ったクラスを作成していかなければならない。クラスだけでなく、メソッドやフィールドレベルまで適用することが大事。
そのための設計手法の代表がDDDであるのだと思います。
しかし、イノベーションの実現には「スピード」が求められる。今日の社会の状況は明日もそうなっているとは限りません。
ということでRDRAやICONIXで要求からコードまで一貫して設計する。
で、スピードが求められるところで一発でそういう設計をするのは難しい。。。ということで「リファクタリング」を行いながら設計を改善し続ける。ということでしょうか？
3についてはそれこそアジャイルなプロセスがそれを実現できる手段ではないかと思います。
実は私は半年前に転職し、「有限会社 システム設計」にお世話になってます。
システム設計では正にこれをやっています。
私もシステム設計の社員です！と胸を張って言いたいところですが、まだ技術が付いていけず悪戦苦闘の毎日を送っております。
現在は社内の勉強会で「リファクタリング」の不吉な臭い（P75～P88）からパターンを覚えるというところをやっています。もちろんRDRA/IConix/DDDなども主要なテーマとして理解を日々深めています。
最初に示した1～３について、もちろんそれを実現する手段というのは各企業によって異なることでしょう。それどころか事業の定義すら各企業で異なるはずで、この3回で示してきた「顧客のイノベーションの実現のための手助け」というのは私自身が書籍を読んだ上での感想でしかありません。
しかし、リファクタリングが翻訳された当初（・・・はまだ私はエンジニアではなかったのですが）、さらには半年前DDD本が翻訳された当初のIT勉強会界隈のあのブームは今はどこにいったのかが気になるところです。
各企業で細かい事業は異なるがやはり必要とされて歓迎されたのだろうものが今あまり見られない・・・各企業で浸透したのか、または忘れ去られたのか、あまり必要でなかったのか。。。リファクタリングを勉強したりマネジメントを読んだりしながら思ってしまいました。
また、エンジニアがビジネスを理解すべしという曖昧な疑問には(今私自身実現できているかどうかが別として・・・)明確な答えを出すことができました。
顧客にとってはイノベーションを実現するためにリスクを取っている。それを支援する我々はどうしても同じ立場でリスクをとることはできない。
しかし、それでも顧客のビジネスを最大限理解し、適切な技術を選択し、ビジネスをソースコードレベルまで落とし＋アジャイルなプロセスを適用することで最終的に顧客のリスクを最大限軽減することができ成果をあげることができるのだと思います。
ツイート
もう流行ってないけどドラッガーの「マネジメント」からSIer事業を考える
流行は去ったけどドラッガーの「マネジメント」からSIer事業を考える
つづきです。
今回は「SIerという事業は顧客のイノベーションの実現を手助けすること」と仮定した場合にSIerが抱える諸所の問題が違った視点で見えてくるというお話しです。
① 顧客のビジネスを理解するのは難しい
エンジニアなら一度は顧客のビジネスを理解して仕事をするべきだ。と考えたことがあると思います。ただ、実際には難しい。
特に２次受け３次受けの仕事をしていると顧客のビジネスはどんどん変わる。しかし、難しい理由はまだまだあります。
顧客がわたしたちに発注するのは「イノベーションの実現のため」。新しいエンドユーザの欲求を掘り出す作業はマーケティングに沿ってビジネスをするより大変な「リスク」を伴うはずです。
私たちがどれだけよいシステムを組んでも、またはそれができなくても私たちの「リスク」はそれほど高くないはずです。
なぜなら、私たちにとっては顧客の欲求は顕在化している。つまり、「マーケティング」に沿ったビジネスをしているからです。
雑な言い方をすればわたしたちはシステムを作ればそれでもビジネスとして成り立ってしまうわけです。
このような意識になってしまうととても顧客のビジネスを理解することは適わないことだと思います。
また、顧客がわたしたちに発注した時点で既にイノベーションを実現するための「目標」や「事業計画」もちろん「予算」なども立てているケースがほとんどで、だから発注をかけているわけです。
そんななかで顧客のビジネスに入り込んでいくというのはさらに大変な作業なわけです。
しかし、顧客が「イノベーションの実現のため」に私たちに発注していることが理解できれば顧客のビジネスを理解しなくてもよいというのが間違えだということがわかります。それは後程説明しましょう。
② 頑張ったのに次の発注につながらない。または頑張ってないのに発注を継続してもらった。
今まで私はこの点に関しては「顧客の懐」次第。と思っていたのですが、それは間違いでした。
理由はやはり顧客は「イノベーションの実現」に注力しているからなんだと思います。
とてもリスクが高いなかで挑戦なわけですから、一方では「縮小」や「撤退」も考えながらやらなくてはならない。これもビジネスの一側面だと思います。
しかし、私たちにとっては顧客ほどリスクを取ってはいないわけですから、システムの「完成」のみを考えて仕事をしているわけで当然そうしなければ対価ももらえないわけです。
この顧客との「ズレ」が誤解を生んでないでしょうか？
顧客にすれば「縮小」「撤退」は当然の選択。しかし、わたしたちは切られたと思ってしまう。
もう一つ考慮すべきは「完成後」。顧客のビジネスがこれで上手く軌道に乗ったとすればそれは私たちにとっても嬉しいことですが、ここで変化が起こるのを私は見逃してきました。
それは、イノベーションの達成後はエンドユーザの新しい欲求は「既に存在する欲求」に変わっている。ということです。
そうなると、顧客の考えることは「イノベーション」ではなく「マーケティング」ということになると思います。
ここではITの役割または顧客が私たちに期待することがぐんと減ってきたり変化したりするはずです。そこに気がつかないでいるといつの間にか私たちは不要になったのか？などと誤解を生むことになりそうです。
③ 二次受け三次受けは・・・という考え。
少なくても今私の周りにはこのような人がいないのが嬉しいことですが、前の会社では何人かはいました。「作れればいい」という人。
ただ、よく考えたら正解でもあるのです。私が前いた会社は二次受け・三次受け・・・の会社でした。
そのときの私の顧客は当然受注した会社またはその間に立ついわゆる「ブローカー」（と言ってもいいのかな？）です。
その世界は１００％「マーケティング」の世界。顧客の欲求は「作れる人」。となればやはり「作れればいい」という考えも一理あると思います。
ただし、それだけの企業はそのうち立ち行かなくなるかも知れません。
ドラッガーも
マーケティングだけでは企業としての成功はない。静的な経済には、企業は存在しえない。そこに存在しうるものは、手数料をもらうだけのブローカーか、何の価値も生まない投機化である。
と述べてマーケティングだけでなくイノベーションとの両立が何より大事と説いています。
・・・とまた長くなったので結論は次回。最後は「じゃあどうする？」というのを考えてみたいと思います。今のところ言えることは・・・
この問いに対して、私自身としての答えは「まさに他の意味も含まれている。顧客のビジネスを理解する努力なくしてSIerの事業はできない。」ということです。
ツイート
流行は去ったけどドラッガーの「マネジメント」からSIer事業を考える
今三回目のマイドラッカーブームが到来しています。
過去2回は挫折したので今回は頑張って読んでいます。
どうやら甲子園を目指す女子高生より理解力がないようです。
今回は「マネジメント[エッセンシャル版] – 基本と原則」からSIer事業を考えて見たいと思います。
ドラッカーは、まず企業の成果は利益ではなく、顧客の創造であると言っています。
これは決して利益が大事なわけではなく、むしろ必要条件であると言っています。ただ利益の追求それ自体が企業の目的ではないのだということです。
で、顧客の創造という成果はどのようにすれば手に入るのか？
ドラッカーは企業に成果をもたらすものとして、『マーケティング』と『イノベーション』をあげています。
ちょっと乱暴ですが簡単に言ってしまうと、マーケティングとは顧客の欲求を満たすものやサービスを提供すること。
イノベーションとは新しい顧客の欲求や新しい富を生み出すようなものを発見し、かつそれを満たすものやサービスを提供することであると言えると思います。
これを踏まえて、事業の目的や目標、事業計画を作って行く必要があります。
で、事業の目的を考える場合も顧客から入ります。
つまり、『我々の顧客は誰か』ということです。
ここからSIer事業にとっての顧客とは何かを考えて見たいと思います。
まずは発注者（様 以下略・・・）ですね。
そして「発注者＝システムの利用者ではない」ことがほとんどだと思うのでエンドユーザ（様 以下略・・・）も顧客と捉えるべきだと思います。
BtoBでもBtoCでも社内アプリであってもここは変わらないと思うし、誰しも思いつくと思います。
経験が長いエンジニアならむしろエンドユーザにとって価値のあるものを作りたい！という志の高い人も多いでしょう。
しかし！ここで私が思ったのはこんなことでした。
- 自分ではエンドユーザの価値のために作ったつもりだが使われなかった。
- プロジェクトが炎上してプログラムもスパゲティコードで顧客に申し訳ないと思っていたのに、次も発注を受けた。
- 逆にきちんと仕様どおりに期待されたものを作っていたのにプロジェクトが中止になった。また、きちんと納品したが次の発注には結びつかなかった。
などなど、成果と利益が結びつかない理不尽がこの業界は多い！と思ったものです。みなさんも思い当たりませんか？
ただ、この本を読むとどうやら悪いはドラッカーではなく自分であるのに気がつきました。
まず、この考えからして顧客から入らず事業自体や利益を考えてしまっている点です。
大事なのはシステムを発注する顧客は、または、エンドユーザの欲求はなにか？何を求めて発注するのか？ということです。
そう考えると、発注した顧客はいろいろありそうだけどエンドユーザの欲求というのは全くわかりませんね。
システムによって変わる、つまり、発注者が「発注者の顧客の欲求を満たしたいとう思い」から依頼するのではないでしょうか？
さらに突っ込めば、すでにある欲求を満たすのに新規でシステムを発注することって少ないと思いませんか？
システムを使ってもらうことで顧客にこんな新しい価値を提供したい。というケースがほとんどだと思います。
これって、イノベーション？と思いました。
発注者はイノベーションを起こしたいんです。
そのために、ITを活用したいと思ってるんです。
そう考えると、私たちの事業とは「顧客のイノベーションの実現を手助けすることだ」と言えないでしょうか？
このように考えると、これまでSIer事業特有の問題とされてきたいくつかの問題や先ほど箇条書きで書いたことがまた違った視点から見えるようになるんです。
それはまた次回検討してみたいと思います。
※ この記事は、書籍を読んで今私が感じたことを書いています。
実際には、それぞれの会社がそれぞれに考えてそれぞれに結論をだすべき事柄なんだと思います。
しかも書籍内でドラッガーはこの点について、「常に問うべき」と言っています。それはわれわれの社会は常に変わり企業は常に新しい現実と問題に直面し続けるからです。
ツイート
最近のコメント