スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/10:41 [PR] |
04/05/15:03 人間にしかできないこと古今東西、何かと何かを結びつけることができる人は重宝された。 古典的なものだけでも、それは、ヒトだったり、モノだったり、カネだったり、いろいろある。 その「結びつける」ことを「マッチング」と呼び、それを生業とするビジネスを「マッチングビジネス」と呼ぶならば、おそらくほとんどのビジネスはマッチングビジネスになるだろう。 我々のシステム開発も、システムを作りたいクライアントと、システムを開発できるスキルを持ったエンジニアを、マッチングさせるビジネスと捉えられる。そのために「法人格」や「雇用」と言ったメカニズムを単に利用しているにすぎない。 そんな中、Webの技術が発展したことにより、「マッチングサイト」というメカニズムを利用して、間に介在する専門家に頼らずにマッチングを行うというWebサイトがたくさん登場することになった。 完全に自動化されているものもあれば、メカニズムの信頼性を保つ為の監視だけは人力によるもの、さらにはマッチングを促進するサポートまで人力でするものなど、その自動化の程度には差異が見られた。 そうして出来上がったあるマッチングサイトが、最近、自動化されていた機能を廃止して、再び専門家による人力のマッチングに注力することを知った。 個人的には、これは一つの良い選択だと思う。 産業革命でもIT革命でも、技術革新によって利便性や効率性が急激に上昇した後では、必ず「人間にしかできないこと」を見直す「揺り戻し」がある。 人は対比することによって、逆にそのもの本来の価値を知ることができることも多い。 機械化やIT化されて初めてわかる人間の良さというのは必ずあるだろう。 それをビジネスの中核にするのは一つの正解だと思う。 弊社のコアコンピタンスも、実は、ここで働く人間である。 クライアントの無意識レベルのニーズまで汲み取るスキルを持ったSEと、色々な要素技術を組み合わせて成果物であるプログラムを作成するPGだ。 IT革命の最先端にいるシステム開発会社が、実は一番大事なものは人間である、と言うのは一見不思議かもしれないが、究極まで機械化やIT化によって効率化している我々だからこそ身にしみてわかる人間の大事さというのがある。 オープンソースや、いろいろなクラウドサービスなど、いろいろと便利なものが増えていて、ITエンジニアの未来について悲観的な観測を持つ人も多いが、我々は何も恐れていない。むしろ、それらは全て、我々のような「人間」を大事にするエンジニア集団の価値を引き立たせ再認識させることになるだろう。 未来は明るい。 ただし、大事な前提がある。 「人間にしかできないことをやり続けているか」 ということである。 昔は水はタダだったが今は有料で売られている。 今は「スマイル 0円」という感じで、タダでもらえる人間のスマイルの価格が、有料になり、機械で作らられたハンバーガーの価格を超える時代がいつか来るかもしれない。 そんな時代に生き残るエンジニアになるために大事なキーワードは「人間にしかできないこと」だと思う。
PR
|
03/28/12:23 ユニバーサルデザインと業務システムユニバーサルデザインという言葉を聞いたことがある人は多いだろう。 私の中でのユニバーサルデザインのイメージは、どちらかというと、 建物や施設などが身体障がい者の方にとって使いやすかったり、 公的なWebサイトなどで、視覚や聴覚に障がいを持つ方にとってわかりやすかったり、 というイメージが強い。 ただ、一般的な定義で言えば範囲はもっと広い。 Wikipediaでは 「ユニバーサルデザイン（Universal Design、UD）とは、文化・言語・国籍の違い、老若男女といった差異、障害・能力の如何を問わずに利用することができる施設・製品・情報の設計（デザイン）をいう。」 などと定義されている。 また、これに関連して有名な7原則というのがある。 こちらもWikipediaからの抜粋になるが ユニバーサルデザインの7原則 The Center for Universal Design, NC State University による。 1. どんな人でも公平に使えること。（公平な利用） Equitable use 2. 使う上での柔軟性があること。（利用における柔軟性） Flexibility in use 3. 使い方が簡単で自明であること。（単純で直感的な利用） Simple and intuitive 4. 必要な情報がすぐに分かること。（認知できる情報） Perceptible information 5. うっかりミスを許容できること。（失敗に対する寛大さ） Tolerance for error 6. 身体への過度な負担を必要としないこと。（少ない身体的な努力） Low physical effort 7. アクセスや利用のための十分な大きさと空間が確保されていること（接近や利用のためのサイズと空間） Size and space for approach and use というものだ。 まさに、誰にとっても利用することができる、という感じだ。 我々も、ECサイトや不動産や求人情報などの紹介サイトなどは、多種多様なユーザーを想定する必要があるので、そんなシーンにおいてはこの7原則は有効だろう。 ただ、業務システムはどうだろうか? ここではより狭義の業務システム、すなわち、業界や業務形態、業務フローなどが特殊であるが故に、一般のパッケージやASPでは非効率が発生するため、ゼロからフルスクラッチで作成するようなシステムを想定する。 このようなケースにおいては、ベストなシステムはかなり尖ったものになり得る。さらに言うと、そのシステムのユーザーでも、そのシステムに接している時間の長短、権限の有無、重要性の高低などには違いがあり、どのユーザーにとってベストなシステムかと細分化してみる必要がある。 実は世の中で実際に稼働している業務システムは、このようにより狭い範囲の人間のために最適化されていることが多い。外から見ると、一見して、イケていないなとか酷いシステムだなと思うものでも、それが出来上がった背景には歴史や思い入れがある。それはおそらくそのプロジェクトを担当したSEやクライアントの担当者しか完全には理解できないものであろう。 ということで、世の中にこんなにもたくさんの便利なクラウドサービスやフリーソフトが出回っても、オリジナルの業務システムをスクラッチで構築したいという要望が消えることがないのは、上で書いたように、誰にとっても良いものではなく、ある特定の人間にとって最高(もしかする大勢の人にとっては最悪)なシステムを作りたいという要望がなくなることはないからである。 築地市場の競りのやり方をもっと誰にでもわかりやすい仕組みにする必要もないし、何かのコレクションをたくさんディスプレイしているマニアな人の部屋をホテルのような部屋に変える必要もない。 フルスクラッチの業務システムは、大量生産とは異なる工程や手法で作成するので確かに手間がかかり価格も高くなる。 でも、私たちの作る業務システムの贅沢さは、特別に作っている工程にあるのではない。特別に作られたものを使い続け、毎日その利便性などを享受できる、その日常こそが「贅沢」なのである。 つまり、フルスクラッチで作ったから価値があるのではない。 背景に、まるで、二日酔いの朝にその人の健康を気遣って出されるお茶漬けのような優しさが溢れているからこそ、私たちの作るフルスクラッチの業務システムは価値があるのだと思っている。 皆のアイドルのような誰からも好かれるシステムではなく、あなたのことを理解して常に寄り添ってくれる伴侶となるような業務システムに出会いたくなったら、いつでもお声がけいただければ幸いである。
|
02/08/13:46 ノウハウよりもノウフー Part2昔、ノウハウよりもノウフー、という記事を書いた。
今日は、それの第二回。 あるデキる部下との、ある技術要素に関するコミュニケーション ———————————————————————— 私「そこの部分は、前にLaracastsで取り上げていたと思うからそこ見てみて」 部下「あ、確かに見た記憶あります・・なんでしたっけ」 (二人して検索、数十秒後・・) 私「このシリーズだね。これの第22回から第24回がそれに関するところで、今回のはたぶん第24回だね。」 部下「あ、この第24回の、xx秒目のところがまさにそれですね」 私「そうだね、その近辺のところに詳しいやり方解説されているから見てやってみてねー」 部下「了解です」 ———————————————————————— ああ・・超楽だ・・・このコミュニケーション。 まぁ、Laracastsは教材としてはちょっと特殊ですが、基本的には、「それはxxxに書いてあるので見てみて」で終えられるコミュニケーションは、時間的にも質的にもお互いにとってベスト。何もプロの代わりに自分で必死に下手な解説をする必要もないし、説明する時間も節約される。もちろん、見た上でわからなければフォローすれば良い。 そして、皆が新しいことでハマるのは、自分で有効な情報の置き場を見つけられないことが多いからだったりする。 (まぁ、今回の場合は、優秀な部下なのでこんなやりとりなくてもすぐ辿り着いただろうけど・・) 他にも「それはxxxがoooの案件でやったことがあるはずなので聞いてみて」とかってのも同じ。 技術の分野は幅広いので全てのノウハウを自分の中に蓄積してアウトプットするのはあまり効率的とは言えない。 コマンドでも、よく使うコマンドのオプションとかは頭に記憶しておいたほうが良いけど、たまにしか使わないものについては覚えるのではなくヘルプを引けば良い。 自分の頭の容量には限界があるので、優先順位をつけて記憶するようにしている。 技術情報とかであれば、例えばこんな感じ。 ------------------------------------------------------- ◉優先順位 第1位 その技術の世界観 確か、あの技術でこんなことができたような気がする・・という感覚。確かこんな機能があったよな・・とか。これはPGだけでなく、SEとしてお客さんと話をする時にも有効だ。お客さんの要望を聞きながら、「ああ、これはあの技術、それはあれだな」とか頭の中でイメージしながら聞けて、話を聞き終わったら大体の提案ができたりもする。引き出しの広さ、アドリブの提案力というのは、直感とかヒラメキによるものだろうけど、それらはすべてこの漠然とした世界観があってこそのものだと思う。 第2位 ノウフー あることに関する情報を得るには、誰に聞くのが良いか、どこを見るのが良いか等についての知識。人に限らず、サイトや本なども含む。必要に応じて、自らその情報源から情報を引き出しても良いし、今回の例のように丸投げも可能だ。 第3位 使用頻度の高い技術ノウハウ 日常業務で使用頻度の高いものについては、記憶してしまったほうが良い。もしくは、真逆で、シェルを書いたり、エイリアスをきったりしてシステム化してしまう。これは徹底的にスピードと効率を重視する。慣れるまでは、大真面目に練習するのもアリだ。無意識レベルになっていると思うがブラインドタッチも最初は誰もいきなりはできなかったはず。大脳新皮質を使わず、小脳レベルでこなせるレベルまで持っていく。各ツールのショートカットなんかもそうだ。いちいち考えながらではなく、体が勝手に動くまで、大げさだけど素振りや空手のカタのつもりで取り組めば良い。 第4位 通常作業のノウハウ 機械化出来ず、毎日の作業の中心となる事柄に関するノウハウはこのレベルだ。頭の中の記憶や自分のノウハウ帳などからノウハウを引き出しなから、考えながら作業していく。 ------------------------------------------------------- これより優先順位が下のものについては、私はあまり記憶していない。どこかに自分向けに記録するか、そもそも記憶することを諦めて、ざっくりとした世界観だけ覚えておいて、あとはノウフーとしてのインデックスだけを記憶しておく。 ただ大事なのは、それらの情報自体は優先順位は低いが、世界観やノウフー情報は記憶の優先順位は高いということ、この辺が特殊なこだわりかもしれないなと思う。 ちなみに、よく「資格試験は意味があるかないか」みたいな議論を見かけるけど、上の話に照らし合わせてみると、 ・資格試験の教材などは、その技術に関する世界観を掴むには、体系的な知識も得られるし効果的だと思う。 ・資格試験に合格することは、もし、通常使用頻度の低いノウハウまで記憶する必要がありその分量が多いのであれば、優先順位は低く片手間にやるくらいで良いと思う。ただし、優先順位が低いだけで、やったらやった分の価値はあり無駄ではないと思う。 というのが私の考え。世の中に本当に無駄なものなんてあまりなくて、ただ、時間と予算の制約があるので、優先順位をつけて取り組む必要があるだけだと思う。 優先順位の低いことにとらわれて優先順位の高いことをおろそかにしたらダメだけど、優先順位の高いことをしっかりこなしつつ、その上で優先順位の低いこともこなしている人は、その分野においてより高みにいる人だと思うしとても尊敬をしている。両者は大きく異なる。前者が世の中に悪評を撒き散らし、後者まで軽んじられてしまうのは不幸だ。 なんだか収拾がつかない感じの文章になってきたので、今日はここまでにしようかと思う。 大事なことは、記憶できる量には限界があるので、何を記憶するのがより効率が良いか意識しながら動こうというお話。
|
02/01/17:34 新しい技術に出会ったら・・弊社では、サーバーサイドの技術としてLaravelを採用している。
Laravelは非常に優れたフレームワークで、熟練のLaravel使いになれば、今までの数倍のスピードでコーディングが可能になる。 最近、フロントサイドの技術の中で、Vue.jsの導入を進めている。 実験的にすでに採用している社内案件もある。 私自身も時々、Vue.jsについて調べたりサンプルコードを書いてみたりしている。 ここまでいろいろと試してみて感じたことは、Vue.jsを導入する場合、どこまでをJavaScriptでやり、どこまでをPHPでやるかの判断がとても大事ということだ。 新しい技術の採用全般に言えることだと思うが、最初は、今までのコーディング作業がこれを導入することで楽になる、というレベルの話があり、このレベルについてはどんどん導入していってよいと思う。 ただ、そこを推し進めていくと、途中で、コーディングの量はむしろこれまでより増えるけどより魅力的なUIが提供できる、とかってレベルの話になってくる。そしたら要注意だ。 コーディングの量が減るにも関わらずより魅力的なUIが提供できる、なら問題はあまりないが、コーディングの量が増えるのなら、それは本末転倒になりかねないこともある。 話をするときに、当たり前品質のレベルの話か、魅力的品質のレベルの話かは区別する必要があるだろう。 で、Vue.jsの場合は、どうかというと・・・・・今検証中だ。 ただ、所感として、vue-routerを使って、全アプリのルーティングやビューの切り替えをやるとかまで行くと”やり過ぎ”な気がする。componetの仕組みを使ってvuiefyでモジュール化していくのも、程よいところで止めておかないと、オブジェクト同士のメッセージ通信が煩雑になり過ぎて非効率になってしまうと思う、これも”やり過ぎ”注意だ。 基本的に、LaravelでもVue.jsでも、一応それぞれの世界だけで完結できるようにフレームワークは提供されている。そのような場合だと”原理主義”同士の戦いになることもある。Vue.js的にはこうあるべきだ、というのと、Laravel的にはこうあるべきだ、というのがぶつかったりする。実際には、それぞれ、部分的な導入もOK、と柔軟な姿勢を示しているにも関わらず、使う側が原理主義に陥るのだ。 あまり料理が得意ではない私が言うのもなんだが、プログラムは料理みたいなものだと思う。Vue.jsもLaravelも素材だ。それぞれの素材の味を100%引き継いだら美味しい料理はきっとできない。それぞれの素材の良さを生かしつつ、ある意味良さを程よく殺しつつ、単体の素材では出せないより高みを目指すのが、きっと料理という芸術なのだと思う。 ということで、新しい技術の採用においては、”中途半端の美学”とでも言うべき感覚を大事にしたい。目的は、単体の技術を極めることではなく、それらを使ってより高次の目的を実現することにある。 で、Vue.jsの場合は、どうかというと・・・・・今検証中だ(笑) 結論出てなくてゴメンなさいm(_ _)m
|
01/21/14:57 便利にするための仕組みで不便にならないように。ふと、便利にするための仕組みを無理やり使って不便になることってあるよな、と思ったりすることがある。 例えば、LaravelのController。 Laravelの公式ドキュメントにも Instead of defining all of your request handling logic in a single routes.php file, you may wish to organize this behavior using Controller classes. Controllers can group related HTTP request handling logic into a class. Controllers are stored in the app/Http/Controllers directory. と書いてあるように、別にLaravelはControllerの使用は強制してなくて、スタンスとしては、関連するリクエストハンドリングロジックをまとめることができるよ、という感じ。 で、例えば、概念的には3つだけど、システム全体で受け取るリクエストの種類が例えば1つのリソースコントローラーにデフォルトで定義されるactionの数(7つくらいだったけ?)より小さいレベルとかその程度なら、むしろコントローラー分けず、Laravelのbasicなroutingを利用するのは十分ありな選択肢だと思う。 もちろん、サーバーサイドのリクエスト処理が複雑なアプリになってくると別だけどね。 でも、最近はVue.jsとかフロントでいろいろやるアプリとかも多いと思うけど、そうするとサーバーに対するリクエストのパターンなんてアプリの見かけ上の動きよりかなり少ないこともあると思う。 例えば、基本的にAPIでサーバーサイドと連携するアプリなんか、下手すると、リクエスト受付のURLのルールは1つで、単に呼び先のクラスに渡すだけとかあるかもしれない。もちろん呼び先のクラスとかはコマンドパターンとかいろいろ適用して適切に設計したら良い。 ORM周りもそうだし、バリデーション周りのそうだし、Larvalは本当に便利な選択肢がたくさん用意されている、ただ、それらの利用は強制されているわけではなく、必要に応じて利用していくべきものだと思う。と言っても、かなり痒いところに手が届いているので、使って行った方が良いケースがほとんどだけど。 逆に、MVCでMがEloquentとかって決めつけも良くない。それに、なぜか、Controllerで書くかEloquent継承したModel(テーブルと1対1)の2階層しか考えない人もいるけど、普通はそんな単純な構造はなくて、ServiceとかRepositoryとかそういう概念を入れてコーディングをすべきだと思う。その辺も原理主義に陥ってはいけないね。 というわけで、今日は、便利な道具をたくさん集めて逆に不便な状況に陥らないように、たまにセルフチェックしましょう、というお話でしたー 読み返してみると、偉そうだな(笑)
|