読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ユーザ系SIerから全く別業種の会社で「ひとり情シス」として内製してる変わったエンジニアのブログです

最速で身につく要件定義入門という講座をスクーでやります

ご依頼があったので、やります。

schoo.jp

システムやアプリを構築する技術がどれだけ向上しても、技術だけでは「こういうシステムが欲しい」という合意形成を得ることは無理。

要件定義には、プログラミングと全く違う「技術」が求められるわけですよね。要件定義と言うと受託の香りがしますけど、サービス運営しているところだって同じことですからね。要件定義しないと、リリースできないわけですから。

個人的には、ITシステムが欲しいけど何をどうやってシステム屋に頼んだら良いか分からないユーザー様に、受講して頂ければと思います。生放送で受講される場合に限り、無料ですので。

それでは、どうぞよろしくお願い致します。

「エンジニアのためのデザイン入門」という授業をスクーさんでやります

schoo.jp

イシジマさんが「エンジニアやプログラマ向けに特化したWebデザインの書籍をやろうとしてるけど、エンジニアとコミュニケーション取りながらやらないとねぇ...」みたいな所に、僕がサンプルのサイトを提供したのがきっかけです。じゃあ一緒に授業もやりましょう、と。作った人間が目の前にいるほうが、より授業にも深みが出て面白いよねってことです。

僕はバックエンドよりもフロントエンドが好き。UIとか考えるの好きだけど、デザインのロジックがわからないので、いっつも適当にやって適当に出来上がってアンニュイな気持ちになっていました。

「デザインはどんなルールがあるのか、他の要因とどんな関係があるのかをロジカルに伝える」ことをポイントにしています。デザインってコードと違って写経するのも難しかったりしますよね。その意味で、この授業が「デザインを支える技術」についての理解の手助けとなるよう工夫していきますし、僕もその観点から講師のイシジマさんの知見を引き出そうと頑張ります。

7月14日、19時から生放送です。全4回の、1回目。どうぞよろしくお願い致します。

schoo.jp

【書評】C#実践開発手法 〜デザインパターンとSOLID原則によるアジャイルなコーディング〜

監訳者でおられる通りすがりのエバンジェリスト 長沢智治 (@tnagasawa) | Twitterから献本頂きました。

本書では「Adaptive Code」をテーマにしています。Adaptiveとは、コードを大幅に変更すること無く、新しい要求やシナリオに対処する適応力のこと、と定義されています。コードを大幅に変更すること無く変化に適用するためにはどうしたらいいんだっけ...っていう話を、デザインパターンやSOLID原則という概念を用いて解説する一冊になっています。

Adaptiveであるためには、とにもかくにも依存関係を整理しなければなりませんよね、という話から始まります。それをコードで表現したパターンを「Stairwayパターン」と表現しており、具象クラスの隠蔽を階段を登り降りするかのように表現しています。

依存関係をゼロにすることは出来ないけど、依存関係を疎結合にすることは出来ます。また、そうしないとダメな理由をこれでもかと言うぐらいサンプルコードを交えて説明しています。デザインパターンやTDDなども触れていますが、それらはあくまでも依存関係を整理することで、コードを変更すること無く変化に対応し、そのようなコードのテスタビリティが高い理由を説明する補足説明で使われています。

SOLIDの原則

この内容については本書をあたって頂くとして、面白かったのがSOLIDの「L」のパートで紹介されている、リスコフの置換原則というお話です。その中で「事前条件と事後条件」について語られており、それをコードベースで書くことが出来ます。事前条件は「入力となる対象全部の値が、そのメソッド正常に動作する条件を満たしているか」です。事後条件は「戻り値が有効な状態であるかどうか」です。

これを.NETの仕組みを使ってやるとこうなります。Beforeがif分岐コード、Afterが事前条件と事後条件をContractsを使ったものです。条件を満たせないとContractExceptionがスローされます。JavaでいうAssertみたいなもんですかね。

Before
public decimal CalulateCost(float kilograms,Size<float> inch) {
  if( kilograms < 0f ) {
   throw new Exception();
  }
  if(inch.X < 0f || inch.Y < 0f ) {  throw new Exception(); }
} 
After
using System.Diagnostics.Contracts;

public decimal CalulateCost(float kilograms,Size<float> inch) {

  Contract.Requires(kilograms > 0f);
  Contract.Requires(inch.X > 0f && inch.Y);

} 

C#erなら取り敢えず読んどけ

とにかく本書はしつこいです。しつこいぐらいコードを載せて「Adaptive」について400p近く語られています。本書でも「抽象化を行わなければ、無数の要求が大きな泥だんごと化し、責務はほとんど描写されず、結果としてユニットテストがなく保守も拡張も難しいのに、業務上不可欠なアプリケーションが出来上がります」と警鐘を鳴らしています。自分の明日の仕事をラクにするためにも、C#erは本書をあたる価値があるでしょう。

全然関係ないけど、個人的にはWPFのMVVMの決定的な入門書が欲しい。ピュアにC#で実現するパターンと、フレームワークを使うパターンで。しつこいぐらいそこを解説する本、なんか無いかな〜。

【書評】マリンITの出帆: 舟に乗り海に出た研究者のお話

地元の図書館にたまたま新着で入っていたので、読んでみた。とても面白い試みだったので、紹介します。

マリンITの出帆: 舟に乗り海に出た研究者のお話

マリンITの出帆: 舟に乗り海に出た研究者のお話

イカ釣りの機械のモーター制御からキャリアを開始

著者はカンブリア宮殿にも出演した東和電気製作所さんで、イカ釣りのモーター制御のプログラムを書くことからキャリアを開始。テグスがピンと張っている時は構造上イカが逃げることは出来ないが、船の揺れや海の状況によってテグスが緩みだすと、イカは逃げてしまう。

というわけで、漁船の揺れを検知してテグスが緩まないように、モーターの回転を制御するプログラムを書かれたそうです。C言語だよな、きっと。組み込み系の話は面白い。

ちなみに、簡単に言うとこういうロジックで算出されるそうです。計算の変換には積分を使うらしい。

  1. 加速度を検出し、速度に変換
  2. 速度を変位に変換し、モーターの回転速度に変換
  3. 補正する回転速度を出力

大人になると(特にITの仕事をすると)、数学が色んな現象をモデリングしていることに気づいて面白い。GPS三平方の定理を使って現在の位置を割り出すとか。学生の頃知りたかったですね。'`,、('∀`) '`,、

www.tbs.co.jp

ユビキタス・ブイ

「ホタテ養殖のために、海水温観測のブイを作って欲しい。10万で。」

環境省が導入するクラスのブイが、数千万円。漁業用で安価なものでも、数百万円。でも、ひとりの漁師が出せる予算は、10万円。水温観測をしたい理由は海水温を検知してホタテが大量死するのを未然に防ぐため。

・・・当初は10万円で出来るわけねーだろというお気持ちで試作品を作ったそうですが、漁業組合の青年会の方々の協力の下、地道なサンプルデータの収集を続けることで段々と実用化に向けた手応えを感じられ、「ノーマリーオフ」機能を組み込み実用化されたとのこと。素晴らしいですね。

その他にも色んなお話があり、iPadを使った漁業日誌アプリとか、漁船に無線LANを導入した話とか、現場に則した実践的なお話が多くて楽しく読めました。

制約なき開発は作業に過ぎない

本書の114p〜115pに書かれていて、これはと思いました。

新しいものを開発するときには、必ずチャレンジを含めるようにしている。つまり、少々厳しい制約を設けるのである。(中略) 何よりも、制約を設けないと工夫するために頭を働かせるチャンスを失ってしまうのである。実にもったいない。

最初からできる事が分かっている開発は単なる作業であり、そこに創造性はなく、次に活かせる技術も身につかない。その結果いいものはできず、達成感もないから愛着もわかない。

エンジニアの成長についてのほとんどすべてが書かれている文章ではないでしょうか。

マリンITの今後に期待します

今後のマリンITの目指す先はどこになるかわからないのですが、恐らくは方法論を確立して標準化を目指していくことになると思います。海水温のリアルタイム解析とか、海底の地図におけるGoogle Mapとか、やりたいことは色いろある中で、Python的な「間違えようのないやり方がひとつだけあるのが望ましい」という方法論を、産学連携して築いていけるといいなぁと思いました。

こういう話を聞いてると、ソフトのみでもたらすことが出来る革新的な物事って、そんなにないですよね。まずはハードを開発できないと新しい体験は生まれないだろうし、どんなにソフトをとっかえひっかえやっても、ハードそのものが変わらないとダメだなぁと。その意味で低レイヤーの技術とWeb技術の両方を会得するレイヤーフルスタックなエンジニアが、5年後には花型になってるかもしれませんね。

あわせてよみたい

news.mynavi.jp

システム内製か外注か、どちらを選択すべきか問題

atsuizoさん、ちーす。また飲みましょうー。

atsuizo.hatenadiary.jp

僕も強烈な内製回帰厨なので、本件については黙ってはおれませんでした。

内製がメリットを生む条件

何事も条件が揃わないとメリットは生まれません。僕は以下のとおりに考えています。

  • 事業の差別化要因が強化されることが期待できる。
  • 継続的に手を入れるだけの理由がある。
  • 外部サービスで代替出来ない理由が明確である。
  • デモテープを作ることが出来る人材がいる。

これら全てにYESと言えない場合、外注を検討したほうが良いでしょう。継続的に手を入れる理由がないなら、買ってくればいいんです。改善する理由が見つからないなら、リソースを割く意味が無い。リターンがないからです。重要なのはROI...というか、これだけ。内製することでROIを高めるためには、事業の魅力がアップしなければならない。よりお客さんが選んでくれる理由を濃くするか、増やさなければなりません。

ITで事業の魅力を高める手段は、色々あります。ネットショップの自作なのか、社内業務の高度化なのか、顧客向けサービス開発になるのかは、なんとも言えません。共通していることを大きく言えば、競争力の強化ですか。で、それはどうすれば実現されるかって話なんですけど、この2つしか無いんじゃないかと思ってます。

  • ビジネスモデルは今まで通りだけど、圧倒的にオペレーションが高度化される。
  • ビジネスモデルの再構築を行い、競争優位に立てる。

ITの話じゃなくなりましたね・・・。弊社の場合は前者の比率が大きかった。

ただ、経営判断をしたくても「出来上がったものを見せてよ」っていう話に絶対になります。口に入れてみないと判断できないので。その意味で「デモテープ」を作ることが出来る人材が必須で、極端に言えば「デモテープ作って下さい!」っていうオファーをクラウドソーシングでやってもいい。コード書かなくてもPaas(Kintone等)で作っても全然OKじゃないですかね。

デモテープ作ったら「やったぜ、これを公開して早速儲けよう」とするのが経営。しかし、どこかで「デモテープとレコーディングはレベルが違うんです」っていう話をしなくてはならず、それが出来る人材がユーザー企業に圧倒的に少ないというミスマッチを強く感じています。継続性に欠ける理由もここにありそうです。

内製化の人材確保問題

僕が何かしらの理由で一時的なり長期的なり永続的なり弊社を離れることになってしまったら、どうなるか。永続的に離れたらシステムダウンの時が弊社の終わりの時でしょうね。現場が崩壊します。零細企業なんてそんなもんで、そのリスクは受容するしか無い状態です。金もないし。

長期的(数年)離れても、別に問題無いです。仮に退職しても、僕個人にメンテ料を払ってもらえればちょいちょい手を入れるだけで済むぐらい、システムとして完成されたので。全てが僕の頭に入っているからできる事なんですけど。

僕の存在自体がメリットであり、リスクとなっています。死なないように鋭意努力します。

顧問プログラマ

人材確保のひとつの理想として、倉貫さんの「顧問プログラマ」っていう考え方を紹介します。IT技術は高度な専門職。会計士のように月額定額でサービスをして、IT経営を実現するためにコードを書いたり、要員の教育をしたり、外注とのやりとりをしたりする。そーゆー小回りの効くプログラマが圧倒的に足りないのは事実ですし、雇用するにはハードルが高過ぎるのも事実です。定額制でサービス化したいよね、と。人月最高だね。

kuranuki.sonicgarden.jp

世の中がソフトウエア化(ありとあらゆる情報がソフトウエアによって管理されること)する流れが進むわけですから、顧問プログラマにスポットが当たってもいいはずなんですけどねぇ... 特にユーザー企業さんに。本業がITではない所に。どうしたらいいんだろう。

作るだけじゃ意味が無いから、継続的にユーザー企業にIT支援を行えるような人材流通・流動の仕組みができるといいなぁという結論に、内製と外注を考えると落ち着いてしまう今日この頃です。