富士通黒川社長、「富士通は業務を顧客に任せ、ITに偏りすぎた反省があった」 より
なんか横文字のオンパレード。
富士通では、フィールド・イノベーションを実現するために、「どう作るか」から「何を作るか」へと意識改革をしたビジネス・アーキテクト、人とプロセスを改革する役割を担うフィールド・イノベータを育成し、顧客のビジネスをもっと理解した形で、イノベーションを起こしていく仕組みを構築。「お客さまと、富士通のフィールド・イノベータ、ビシネス・アーキテクト、コンサルタント、営業、SEが一体となったフィールド・イノベーション・チームを編成し、ビジネスの視点から、一緒になって課題解決を行う関係を作ることが大切だ。お客さまのビジネスを理解する、時にはビジネスを代わってやらなくてはならないというところまで踏み込む必要がある」と語った。
もはやよく分かりません。イノベーションがマイブームなのでしょうか。数年前から横文字については言われ続けているのに、未だに解消していないあたりが問題な気が。
Lifehackに関する情報を提供するメディア、ブログは数多くあります。が、それらを信じて日々を少しずつ改善したら、優秀なエンジニアになれるのでしょうか。恐らく結果は逆になるのではないかと。
via MUJI color Pen Rainbow with Moleskine on Flickr - Photo Sharing!
原因としてはLifehackを熱望するあまり、Lifehackすることが目的になってしまうからです。確かに役立つ情報もあるでしょうが、それをそのまま実行するだけでなく、租借し、自分なりのやり方に変えて、自分のものにしていかなくてはいけません。何よりLifehack情報を集めるのに時間を費やしているはずです。情報収集に時間をかけるよりも現状を維持している方が実は効率的、なんてなったら笑えません。
似たような事例として「トヨタのカンバン方式」とか「モトローラのシックス・シグマ」とかあったと思うのですが、それを真似する企業が追随しました。が、結果として駄目だった会社もたくさんあります。他人の真似をしているだけでは駄目なのです。
また相当遅いのですが、日経ビジネス2008年02月25日号は「湘南企業」というタイトルで、様々な湘南の企業を特集しています。その中の一社「アルバック」は会議をダラダラやるという決まりがあるそうです。効率性ばかり追求している現代の企業群とは一線を画す方法です。
で、そこで以下のように語られています。
でもね、よく考えよう。100万回ループさせたら9秒の差が出ました、って、、、 100万回とか1000万回ループするfor文なんてものを書くのは実際の開発現場においてよくあることなんだろうか？（いやもちろん、実験だからそういう数値を使ってることは承知のうえで）
恐らくWeb屋（いわゆる人のためにサービスを開発を行う方々）はこう思うだろうな、と。言わば納品先はシステムの素人な場合が多い訳で、優先順位的にも納期や安定動作の方が重要で、システムの速度はその次でしょう。
でも自社のWebサービスとして開発する場合は全く異なってくるでしょう。数ミリ秒単位で速度を磨き上げていくことは、ユーザビリティの向上につながります。特に最近のWebサービスでは数秒のもたつきでユーザが逃げてしまう、なんてことは良くあること。こうした小さな改善を積み重ねていけば、結果として大きなシステム改善につながり、ハードウェアに頼らないチューンナップが可能になります。
元ネタの「@」でエラー抑制すると PHP が遅くなるという噂について [ a++ My RSS 管理人ブログ ]にしてみれば@がないことで1000万回実行した結果による8秒改善が重要なのではなく、そもそも自社システムをより良いものにしていくという姿勢の現れだということです。
個人的にはできれば良いじゃない的な論理ではなく、やるからには徹底的に突き詰めて改善していくという考えがWebの技術者には必要だと思います。そうした小さいこだわりは意外なほど、使っているユーザに伝わるものです。
コンピュータの前に座っていると、ついついキーボードを触りたくなります。が、実務であれば別ですが創造性を必要とする場合や、もやもやしたものを形にしていく時にはむしろコンピュータでない方がはかどることが多いです。
その時に大事なのがメモできる用紙です。個人的にはA4サイズでは物足りないため、B3くらいのスケッチブックを使っています。全くの無地なので、自由に線を引いて文字を書いて、とできます。
もう一つ大事なものは以下にて。
開発会社の方であれば、仕様書は作成すると思います。受託開発のころ、元請けの会社の方が仕様書をきり、それに沿って開発をしたりしていたのですが、開発を進めていくうちに徐々に問題が出てきます。
via A pile of paper on Flickr - Photo Sharing!
よくありがちなのが、納品物に対する仕様書を盾にして意見が押し付けられることです。読み違いや勘違い、前提知識など様々な要因があるのですが、仕様書は絶対と言わんばかりの態度をとられます。
そして、さらによくありがちなのが仕様書の間違いです。しかしこれは前者の逆でありながら、スルーされることが多いようです。絶対なのか、または逆なのか…勝手に解釈を加えて欲しいのか否か、よく分かりません。
後、もう一つありがちなのが、最初の方の仕様こそきちんとしているのですが、後の方（システム的には重要視される部分）になるとドキュメントが希薄になっていくという現象です。開発のスケジューリングの問題なのかも知れませんが、差別化要因を生む箇所にこそ、力を注がないといけないのですが、そうでないことが多いようです。
ということで、解決策は以下に。
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを blogを読んで、ちょうど先日同じ話をしていたので。
via Cocoa Code - 1 on Flickr - Photo Sharing!
テストファーストで書かないと、と思いつつも工数や納期に押されて書けずにいる人は多いと思います。プログラマにとってみれば、自分の書いたところにバグはないと信じる気持ちもあるので、あまり気が進まないということもあります。
そこで、書くべき場所と書かない場所を決めてしまうのが大事かな、と。
これは先日人から指摘されて、はと気付いたのですが。
オープンソースを紹介している中で、英語/日本語以外のソフトウェアもたくさんあります。英語は第二言語ほどではありませんが、理解できる人も多いですが、ドイツ語/フランス語/イタリア語/ロシア語など、その他の言語になるとさっぱり分かりません。アラビア語など、読むべき方向が違うので戸惑うばかりです。
そうしたソフトウェアやサイトを見ると「なぜせめて英語だけでも情報を提供してくれないのか」と思ってきました。せめて英語だけでも情報があれば、内容の理解が進むからです。
また、同様のケースはプログラムのエラーでも起こりえます。エラーメッセージは英語で出ているので、それで検索してみるのですが、ブログのコンテンツはイタリア語になっていたります。せっかくのエラー改善につながるかも知れない重要なコンテンツが英語というのは非常に残念なことです。
しかし同様のことは日本語でも言えそうです。
答えから言ってしまえば必要でしょう。全てのデータは最終的に会計へと収まっていきます。何らかのデータがあった時、それが会計上必要ないのであれば削除できる可能性もある位です。
via Busy with these ! on Flickr - Photo Sharing!
バックオフィスの方で、なぜこの入力を行わなければならないのだろうと思うようなことが時々あります。それらは企業内の歴史の中で培われたもので、存在意義を誰も知らないことがあります。そうしたときに重要なのが、会計上利用しているか否かです。もし利用していない場合、そのデータは消しても問題ない可能性が高まります。
逆に、例えば顧客管理にあるデータが売掛元帳の顧客名として使われていた場合、安易にデータの削除処理を行うとリレーションの具合によってはデータは抽出できなくなり、会計の不一致を起こしかねません。削除処理の前に、売掛残が存在するかチェックしたり、漏洩するとまずいデータ（会社名、メールアドレス、住所など）だけ塗りつぶして他は削除フラグを立てるだけにしておくといった処理にすることを考えつきます。
会計のデータは決算書へと反映され、企業が存続する上で重要な要素になります。このシステムへと入るデータは全て最重要です。その観点でデータ構造の定義をしていくと、実は担当者の個人的な思いであったり、既に不要なものであったりということが分かるようになってきます。
さらに大事な理由は以下より。
今のネット社会では情報が膨大に溢れ返っています。日々新しい情報が次々と舞い込んで、目移りしてしまっているのではないでしょうか。その所為で、数ヶ月前には「あれをやろう」と思っていたのに今は「これもやらなきゃ」と以前の決意はどこへやらという状態になっている人も多いのではないでしょうか。
via madrid 05. on Flickr - Photo Sharing!
そこで、敢えて情報を遮断してみる勇気を持ってみるのはどうでしょうか。遮断された中で本当に必要なもの、すべきことを見つけて、それだけを探求すると決めてしまうのです。
会社組織ではよく、先輩が自分の仕事を下（というと語弊があるが）の人に教えてあげないということが起こる。原因は簡単で、下の人に自分の仕事を与えてしまうと、自分の仕事がなくなってしまうのではないかという不安にかられてしまうからだ。
via gravity on Flickr - Photo Sharing!
会社人である以上、自分の専門性が会社内での地位につながっているというのは分からないでもない。だが、下の人に任せるべき仕事に固執しているのは周囲から見てどう思うだろうか。そこで、そんな不安を解消する方法を紹介しよう。
簡単に言えば、得意分野を二つ持つのだ。それは平行して持つのではなく、さらに一段上の技術を習得するのだ。
|
MOONGIFT
|
Open Service
|
|
Rails 2.0
|
Residentof.net
|
|
Cool Coding
|
Producing Web
|
