エンジニアの実装力をコンサルティングに活かすということ

会社を設立して、あっという間に半年が過ぎました。自分が食べる分にはお陰様で困ることはなく、色んな試行錯誤が出来ています。

その中で最大の試行錯誤は、当方が今後やっていきたいと考えていた「非IT系中小企業を対象に、IT技術を業務や事業運営に活かす顧問としてのエンジニア」というビジネスの形です。

中小企業はやっぱり困っている

「自社で Excel / Access が出来る方がいて、そこで作られたものを使って業務を回している。でも、他に良いやり方を知らないので、そうせざるを得ない。手を入れたくても、どうしたら良いのかわからない。専門家にこのやり方が本当に良いのか、変えるとしたらどこなのか。そういうテーマで調査して報告してもらいたい。」

上記のようなお悩みをお持ちの会社さんから、ご相談頂きました。現地に飛んでヒアリングして、現状をクリアにして改善点をまとめた調査報告書を作った所、喜んで頂けました。

ITを業務に使ってはいるけれど、他にやり方を知らないのでより良い方法があれば知りたい。やるかやらないかは別にして、自社にとってITを活用できる道筋をご案内することで、ITに何を求めていくのが望ましいのかを整理して、回答を提示する。こういうニーズがあるのかと勉強になった。

ITを入れる前提で動いてしまうと敷居がすごい高い。そもそも何がどうなっていくらになるのかも見当がつかないのに、そんな話は通せない。調査してこういう道があると対話して、現状を共有する。取っ掛かりとしてすごく良い形だと感じました。来年以降、こういう形で一般的な中小企業に対し顧問エンジニアのお仕事をやっていこうと思います。

改めて感じたのは、実装力の有無は提案の幅に(主に選択肢として)大きく差が出るということ。業務の独自性は企業規模に全く比例しないので、パッケージソフトを入れて改善できるポイントがあまりない。そうなると、当たり前だけど業務に流れる情報の流れを設計して現状を整理し、それを行う為に最適な手段をプログラミングをする前提で考える必要がある。実装手段はExcelでもいいんだけどさ。

大企業のように、単純な作業がそれ自体たくさんあるわけじゃないんだよね。中小企業は大企業のミニチュアじゃないですし。そーゆー所を勘違いしてるから、中小企業のIT活用は成功していないんじゃない？

Segueが2回呼ばれてしまったらSegueをVCから貼り直す

StoryboardでUITableViewからSegueを伸ばしていると、VCのライフサイクルとdidSelectAtRowのタイミングで2回呼ばれてしまうようです。

こいつを治すには、Segueの貼り方を変えるだけ。VCから対象のViewControllerに向かってSegueを貼ります。あとはdidSelectAtRowのデリゲートメソッドでperformSegureしちゃって。

自分で敷いたレールを歩みたいよねっていう話

この記述、すごくわかる。僕もそう。だから独立した。同じような考えの人っているもんだ。

「自分たちのサービスで勝負したい」という想いがどうしても強く、既に誰かが成功させたビジネスに乗っかって、更に成功を拡大するためにプログラマーとして働くという選択肢を取ることができなかったという理由です。

東京の会社を退職して山形に移住することにしました - セカイノカタチ

わかる・・・わかるよ・・・ 多分同じ感覚だ。商売がしたいんだよね、仕事がしたいのではなく。仮にGoogleから年俸で1000万のオファーがあっても、給料の1000万にはさしたる興味がない。でも、自分で作ったサービスなりシステムなりで100万円売り上げることに、やりがいを覚えてしまう。10分の1しかなくてもね。そういうものなのだ。

僕の場合は自分のサービスで勝負したいの他に、独立を志した理由があった。顧客を作る努力をしようと思ったから。今36歳になっちゃったんだけど、アラフォーになったら転職は当然難しくなる(一般的にね)。独立したって同じように厳しい。質は違えど、どっちの道を選んでも厳しいわけ。どちらかがえらい簡単なことはない。職につく努力をするか、自分の顧客を作る努力をするか。どっちがしたいと考えて、後者を選びました。顧客を作る努力のほうが楽しいもん。

ご武運をお祈りします。お互い頑張りましょう！

おっさんの説教という最凶のバズ

レールに乗った人生は嫌だの石田さんの炎上っぷりをみて、改めて感じたこと。おっさんが説教したくなる内容ってはてブを中心に火がついてバズる。すごく。

イケハヤさんも燃え上がったのは若くてソコソコ頭が回るのに全く明後日の方向を向いたコンテンツを量産していたから、というのが自分の中で腑に落ちる。「いやその理屈はおかしいけど、若気の至り臭すごい。まだ間に合う、まだ引き返せる。言わずにはいられない。」というギリギリのバランスがあった気がする。今は単なるおっさんになってしまったから、誰も説教しようともしなくなった。石田さんは今が旬だけど、1年後には燃料が切れる。ろうそくのようなもので、どんどんすり減っていく。継ぎ足すことはできない。

高知のおっさん、ほんまにどうするんだろ。サロンとnoteは急上昇のあと急降下、ブログは適当に書き散らかすのみ。謎の農地を購入して公園の砂場遊びに明け暮れている。彼の言うことに耳を貸す人が減ったから商品価値も減っている。思いつきで生きているから仕事を請けることの意味もわかっていない。打つ手が無いので遠目には四面楚歌に見える。老害として再ブレイクするしか無いんじゃないかな。キャラしかコンテンツに出来ないのなら時間の問題だ。

ラーメンが苦手

どうしても食べ飽きてしまう。サッポロ一番塩ラーメンだけは好き。

温かいうどんや、リンガーハットのちゃんぽんとかは好きなのに。ラーメンだけが苦手。

恐らく脂が原因だと思う。ズドーンと脂が前に来るのが苦手。二郎系はもう色々無理。スープも味付けが濃いラーメンが多い。薄味で整えるのは難しいし食った気がしない人が多いだろうから、薄味のスープのラーメンって作ってもリピーター来ないんだろうな。

あと、麺。ラーメンって麺の種類がすごく豊富だけど、麺がうまくないと食べ飽きるんじゃないかなぁ。醤油ラーメンも醤油の味を感じてしまうと飽きてしまう。

ラーメン苦手だけど、実はラーメンってすげー作るのが難しい一品なんじゃないでしょうか。

筋書きを書くこと

どうもこれが一番好きみたいだ。ストーリーを書くといってもいいか。

プログラミングが好きなのも、プログラミングで１つの筋書きを書くから。

文章の読み書きが好きなのも、筋書きを考えるのが好きだから。

やきうが好きなのは、そこに筋書きがないから。これだ。

おれが野球を愛する理由はここにあったな。

仕様書策定の良いツールはないものか

やっぱりOfficeソフトを使っている会社さんが多く、画面設計書なんかはPowerPointで書かれていたりします。

当然のことなんですけど、「この画面項目はDBのどのテーブルのどのカラムに該当するか」がわからないとプログラムを書くことが出来ません。そういう情報をパワポに盛り込んでしまうと、DB側で変更があった時に差分が取れなくなります。取れなくなるというか、手で修正する必要があります。逆も然りで、ER図に変更があった場合は設計書に反映しないといけない。

例えばだけど、ERに変更があったらそこからテーブル作っちゃって、画面設計書の項目をマッピングする時に作ったテーブルのカラムをプルダウン(オートコンプリート)で選んでいくみたいなレベルまで徹底している現場って…あるんでしょうか？

こういう不整合が重なると、仕様書が死ぬと思うんだけど...

Markdownで書けばいいじゃんっていう説もあるようですが、Markdownって複数の文書間の整合性を取れるもんじゃないですよねぇ...