出来ない人のレベルに合わせてはいけない

あるあるネタだと思いますが、組織がより優れたパフォーマンスを出す為にやっちゃいけないことが「出来る人とできない人がいた場合、出来ない人のためにレベルを下げること」です。

優れた解決策を持ってる人に合わせよう

コードのバージョン管理で、出来へん人が「あの僕はGit使えないんでZIPで差分管理して欲しい」とか言い出した時に「そうだね！出来ない人に合わせないとね！」とはならず「Git覚えて」となるでしょ。優れた解決策を持ってる人が、結局は出来ない人を助けている。わかりやすいでしょ。

— やきう大好きござ先輩 (@gothedistance) 2015, 12月 24

簡単にいえば「↑」のようなことです。非エンジニアの方にはわかりにくい例ですが、Excelをファイル名＋日付＋バージョン名で複製して管理するのはとても大変ですよね。そんなことをしなくても良いツールがあるんです。それを使える人がいるのであれば、皆がそれを最低限使えるように努力すれば良い。できる人のレベルまでたどり着けではなく、できる人の邪魔をしないレベルまで下駄を履かせることにすごく意味があります。

昔、なんかの記事でExcelで手計算しているシートをマクロか計算式を組んで簡単にしたら怒られたみたいな話を読みました。ソースはごめんなさい、忘れました。が、Excelというツールを高いレベルで使いこなせる人が皆さんが苦労しないように「ひとつ上」のステージに上がれるよう腐心したのが怒られる理由が、ちょっとわかりませんでした。

出来ないひとに迎合した場合は、ずっと「ファイル名＋日付＋バージョン名」で差分管理をすることになる。Excelの手計算を続けなくてはならない。やらなくても良い作業をやらねばならず、何も生み出していない作業に時間が食われる。「みんなで頑張ってます」といえば聞こえはいいのでしょうが、出来る人はできない人の為に足を引っ張られて、ひとつ上のステージに行けるチャンスを逸している。恐ろしい話。

出来ない人に合わせていたら、誰も幸せになりません。できる人の邪魔をしないこと、阻害をしないことが、翻ってみんなの為になる。ExcelマクロでもGitでも同じことで、そのような優れた解決策があれば、出来ない人でも有る一定の質の成果が出る状況を作ってくれるので、会社を経営する立場からすればこれほどありがたいことは無い。

頑張ってもしょうがないこともある

僕、頑張るって言葉あまり好きじゃないです。努力するしか無いわけですけど、優れた解決策に迎合する努力をしないで、ただ目の前のことを頑張っているというのは、全員が不幸になる恐れがあります。ボトルネックを解消せず、ボトルネックをそのままにしておいて皆で頑張りましょう的な考え方は、大変危険です。誰も幸せになりませんから。頑張らなくても良いことに全力で努力しても...ねぇ。僕はエンジニアなので、余計にその思いが強くあります。

人の頑張りというボトルネックを解消しよう

ボトルネックが生まれるのは、その作業が自動化(仕組みとして整備されていないという意味で)出来ていないことが多いです。差分管理もそうですし、手集計もそうですよね。優れた解決策を持っている人がいるのに、それを「出来ない人がいるから」という理由で捨てるのだけは、本当にやめて頂きたい。生産性が上がらない→休みたくても休めないような状況に追い込まれる→疲弊する→優秀な人がやめる→生産性が(ry のループに入ったら終わり。

「出来ない人に迎合したら終わり」→「出来る人はあんだけ努力してるのに何なの」という個人の自助努力を批判する方向に行くケースもあって、これが最悪。生産性を上げるのに努力は不要です。そのやり方に従っていれば、誰でも一定の成果が上がることを生産性が向上したと言えるのであって、人が頑張ってパフォーマンスを上げているのは、俯瞰して見るとボトルネックでしかありません。その頑張りに依存しているのだから、大変なリスクです。

人の頑張りというボトルネックをコードで解決するエンジニアを頼って、みんなで休みを取りましょう！マジでそう思います！！

【書評】お金をドブに捨てないシステム開発の教科書

技術評論社、傅さんよりご恵投頂きました。

お金をドブに捨てないシステム開発の教科書 ~なぜ、要件定義がうまくいっても使えないシステムができてしまうのか?

本書は公認会計士でありながらシステムコンサルタントをされている中川さんが、システム構想づくりの重要性をじっくりと説く一冊になっています。そう簡単に出来ることではないので「経営・会計・業務・システム」の4つの視点に分けて考えるべきと説いております。詳しい目次はこちらの著者の方の会計事務所のWebサイトにあります。

nakagawa-cpa.jp

本書で挙げられているメッセージは僕の中で違和感が多かったので、書評の内容も「なんでそういう説明になるのかな」という話が中心となります。

構想づくりの大切さを説く「なぜ」が弱すぎる

僕が感じた、本書の最大の不満がこれです。20pの1ページしか、何故システム構想が大切なのかが書かれておりません。システム構想づくりの大切さを説く本のはずなのに、「経営者の決意の重さをこめろ」とか「何故システム構想が難しいのか→ビジネスが多様化しているから」という論理展開は雑です。教科書と謳う以上は、もっと詰めて説明して欲しい。

例えば、経営者の決意をどれだけ込めようが、しょうもない設計書からはしょうもないシステムが出来るので絶対に辞めろ。これが教科書に書くべきことですよ。マジで。

4つの視点を集約しましょうという構成ですが、一読してもう一度頭から読み返すと一体何が大切だったんだっけかなぁとわからなくなりました。視点を切り替えて語ることは必要なことですが、構想を語る為の最終的なドキュメントは下記の構成物で構成され、こういう手順でしっかり詰めましょう、という構成が良かったんじゃないかなぁと思います。会計システムと販売管理システムでは検討事項が異なりますが、本書ではそれを包括的に教科書としてまとめようと腐心されたのでしょうけど、システム開発は暗黙知が多いので大変難しいことだと改めて感じた次第です。

僕が考えるITでお金をドブに捨てない方法

この３つだけ、最低限考えましょう。

• 経営者の思いは適当に受け流せ。
• 自分の仕事の判断基準を全て書き下ろし、ボトルネックを潰せ。
• いきなり作るな。ASPで代替出来ないかを常に検討しろ。

経営者の思い。重要ですよね。プロジェクトの本気度を図る指標としては有用ですが、システム構想には不要なこともあります思いが間違ってることも多いです。僕は自社で内製しましたが、経営者の思いを全く汲んでおりません。聞くだけ無駄でした。やりたい事とやらなくちゃいけない事は、全く別なんです。詳しくは下記をご覧ください。

gothedistance.hatenadiary.jp

業務の洗い出しが重要だ〜とよく言いますが、その8割ぐらいは「で、あなたはその仕事を終える為にどんなことを判断してるの」で説明ができます。判断基準がわかれば、完了基準も例外となることもわかります。そうすれば、業務担当者のボトルネックを見つけてその原因となる構造がどうなっているのか、議論ができます。まずはここを潰さなければ。使う人に使う意味がなければならず、その意味が経営に資するかどうかは、また一つ上の議論です。

ボトルネックの兆候としては、ミスが多い・確認が多い... など。ボトルネックになるのは個人の問題ではなく、組織運営の問題です。その問題が生まれてしまう構造をAs-Isを分析しましょう。その精度が低いと、どうしようもないToBeが出てきてしまいます。新規事業等でAsIsが存在しない場合はToBeから描くしか無いので、余計に難しくなります。

で、最後に。構想を練って業務プロセスを描いて、こういうオペレーションが出来れば改革ができるという段階になって、次に検討すべきはASP等のサービスの活用です。出来合いのもので済ませることが出来るのか出来ないのかを、じっくり吟味する必要があります。昨日の記事で「プラント型ITの構築は企業競争力の優劣の鍵」と書きましたが、中小企業においてはいくらその部分を強化しても無駄なので月3000円払って借りてくるのが最適解であるケースもあります。最終的に業務と業務を繋ぐ血管を作るためにプラント型ITが必要になるとは思いますが、まだその段階まで至っていないケースもありますから。特に新規性が高い業務の場合は。

みなさんのシステム開発が実り多きものであることを祈ります。

お金をドブに捨てないシステム開発の教科書 ~なぜ、要件定義がうまくいっても使えないシステムができてしまうのか?

【書評】会社のITはエンジニアに任せるな！

著者の白川克さんよりご恵投頂きました。

会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること

こちらの白川さんは、エンジニア上がりのキャリアを武器にIT寄りのコンサルタントとしてご活躍されていらっしゃいます。僕も長年「ITを使いこなせない(武器に出来ない)会社が多いのは、何がアカンのか」という話をブログに書いていますが、白川さんもずっとこの問題に向き合っており、ITを武器にする為のメッセージが「会社のITはエンジニアに任せるな」という本のタイトルに凝縮されております。

ツール型ITとプラント型IT

本書では「そもそもITって何なの」という話を、ツールとプラントという概念で分けて考えています。ツール型は、メールやカレンダーのように用途が限定的で完結型のITです。プラント型は「業務と密接に関係しており、ITがその会社での人の動き方を決めるようなIT」のことで、前者と後者は全くの別物。プラントを動かすためには確固たる哲学が必要だから、丸投げするには大事すぎると続いています。

プラントって、↓ なやつ。

ITを武器にする＝プラント型ITを築き上げる

何故プラント型ITなるものが必要なのって話です。ここが重要である理由が伝わらないと、本書を読み進める意義も薄れるので強めに補足します。

最大の理由は、ITで結合された業務を回すためのインフラがあるのと無いのでは事業運営のレベルが全く違い、企業の競争力に大きな差がでるからです。

ITシステムは無くても、Excel/Access無しで業務を回してる会社は皆無でしょう。業務が暗黙知とExcelで回っている状態は、舗装されていない荒れた道を、最小限の機器を積んだ車でドライバーが勘と経験で運転して目的地まで向かってるようなもの。が、経営の立場から見れば、業務を回す工程が人に依存するのはデメリットしか無い。生産性が人に依存しているので改善もクソも無く、現状維持が精一杯になります。この状態で業務改革を実行するのは単に２倍働け(給料は据え置きで)という話ですので、まぁふざけろ、と。

プラントの設計図を書くためには、「業務担当者が判断していること」から「業務上の重要な判断基準」を抜き出して、それを経営の視点から煮詰めます。煮詰めた判断を時系列でつなげていくと、ベストなプラントの完成イメージ図が出来ます。こいつが「ビジョン」です。ビジョンだけでは糞の役にも立たないので、そのビジョンを作業手順まで落とし込んでITに載せてやる必要があり、その作業はプラントの構築のように複雑です。簡単に手間いらずな事業運営など、あり得ません。

そうやって育てられたITがあれば、誰がやっても正しく事業運営が出来ますし、経営判断を業務の中に埋め込むことが出来ます。ヒトに依存しないので、ITシステムを改良することで、更に生産性が上がります。逐次的でありながら、やるほどに加速度が上がります。弊社がそうですので。ヒトが頑張れば早く進むことは出来ます。歩け→走れは簡単なこと。でも、遠くへ進むことは出来ません。取っつきにくいプラント型ITですが、一度プラントが構築できてまわり始めると、会社はガラッと変わります。

これが「ITを武器にする」意味で、その果実を得るためにどうしたら良いのかは、本書に様々な角度から語られています。

プラント型のITを作るためには、経営・業務・ITの3つの視点が必要です。最も足りないのがITエンジニアですよね... 描かれたイメージを素因数分解してレシピに落とす作業がどうしても必要で、その道のプロにしか出来ない。レシピも画一的なものはなく、自社にとって意味があるレシピを作るのは手間がかかるけど、やる意味はすごくあります。

メールベースの相談ならいくらでも乗るんで、僕で良ければお気軽にお問い合わせ下さい。

色んな会社さんにITを武器にしてもらいたいので、事業運営のあり方を変えたい方に本書を読んで頂ければと思います。

会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること

「一括請負はお互い不幸」から「作らないSI」へ

僕がSIerを退職して５年。大きな潮目を迎えているのかもしれない、SIビジネスのお話。

itpro.nikkeibp.co.jp

簡単にまとめると「一括請負はゼロサムになってお互い不幸なんで、XaaSを使って作らないSIをやり始めている」という話を「オルタナティブSI」という言葉で表現しているようです。この5種類に分類してくれていますが、ただ並べただけで軸はバラバラです。

• 月額契約型サービス「納品のないSI」
• 固定料金でシステムを構築する「定額パッケージSI」
• 自動生成ツールを使う「自動生成SI」
• クラウドでITインフラを構築する「クラウドインフラSI」
• ユーザー企業自らシステムを外販する「コミュニティSI」

作らないSIはずっと前から目指していた

代替となる選択肢は色々あるけれども、根幹にあるには「作らないSI」を目指していることだと思っています。

僕がSIerにいた10年前も「作らないSI」をやりたいと社内で議論されていました。ソフトウエア開発は技術力の高低によって、成果物に大きなブレがあります。だけど、仕事として請ける以上は質の均一化は当然のこと。会社の信用問題です。均一化を目指して10年前に生み出されたのは「俺のフレームワーク」という皮肉。OSSベースの標準フレームワークを頑張って作っても「オレの案件、VB。お前のフレームワークJava。糸冬。」という話がとても多かった記憶があります。内製で頑張って標準化を進めてもあまり見返りがないし、稼働率を重視する人月の世界では可動が最優先ですから、なかなか厳しい。

でも、クラウド技術が当たり前になりまして、サインアップすれば誰でもITリソースがジャンジャン使える時代になり、ようやく作らないSIが出来る環境が整ったのではないでしょうか。ボタン一個でサーバー起動で自動スケール、メールサーバやスマホプッシュ通信、VPNもどんとこいというサービスを使うことが出来て、質も良いしお安い。よほどの理由がない限り、使わない理由がなくなってきました。関係ないけど、AWSこえ〜。AWS lambdaでついにサーバーレスのSIまでやり始めた。何でもアリやな。

作らないから、契約も変えられる

作らないでやれるんだったら、契約の方法もそれに適したものに変えていく。作らないわけですから、期間と人数を掛け算してもしょうがない。人月計算型で3,000万のシステムが下手すれば100万に収まるとすると、積算する意味が無いってこと。成果報酬は揉める要素が大きいので、固定額(買い切り)とサブスクリプション(月額定額)が多いみたいですね。固定額の内容が人月ベースの成果補償から別の形に変わっていく。健全な変化ではないでしょうか。

ある程度の技術力はクラウドが担保してくれるので、技術力で差をつけられる要素は少なくなりました。なので、自分たちの技術をどうパッケージングして売り出していくかというマーケティングが、これからのSI企業に最も必要な力だと考えています。倉貫さんの「納品のないSI」みたいな感じ。マーケティングって要はポジショニング。自分にカネを払う理由を教えてあげるわけですよ、今そこにないポジションを取ることで。

どの会社にもCTOが必要であって欲しい

作らないSIが出来ることで、委任に近い格好でSIビジネスが出来るようになった。請負でなければ、極論すれば個人でもSIが請けられます。コード書かなければ、誰がやってもシステムのコード品質は保てます。システムそのものに価値があるかは、全く別ですけど。

作らないでシステムを作ることがどんどん進んでいけば、よりユーザーが自分たちの袖にあったシステムを手に入れられるようになっていくでしょう。必要なシステムを最低限のコストで手に入れられるし、作らないのでコードがブラックボックスにならないのなら、中小企業のIT活用の最大の問題点である「ITがわかる人材がいない」というハードルをクリア出来る気がします。技術者を雇用するというハードルを下げることが出来ますし、ユーザ企業のビジネスの仕組みを支える技術顧問というロールを担うエンジニアが、増えていくとすごく面白いと期待を頂いています。3文字で言えば、CTOですね。

この10年で一番変わったことの一つに、「CTO」という言葉が当たり前になったことを僕は挙げます。10年前にはCIOという言葉しか無かった。でも、今はCTOっていう言葉が業界内では当たり前に使うし、CTOを輩出する上場企業もバンバン出ている。

今後10年で、色んな会社さんにCTO(社内外問わず)が在籍してビジネスの下支えをしてくれるような形になるのが、作らないSIの先にある未来であってほしいなと思います。

カネにならないブログを続けているけど、楽しいです

ブログでの収益報告に対す賛否両論出てきて、とても良いですね。こういうネタが量産されるのがはてな的だ。稼ぐということは手段は何であれ大変なことだな〜

kutabirehateko.hateblo.jp

収益を上げるためにブログを運営することは何の問題もない。他人の不幸やFUDを煽りまくりの炎上商法は嫌いだけど。人生を楽しむためにブログで稼ぐ。ええ話。楽して稼ぎやがって的な嫌儲感は持ってはいけない。それを嫉妬だと断罪する筋の悪さは困り者だけど。

収益報告の最大の弊害は「カネになれば、なんでも良いんだろ？」と嫌悪感を抱かれ、究極的には品格を疑われることなのかもしれないな、と思いました。同窓会で旦那の年収自慢して勝ち組と思っている鬼女かお前は、と。怖い怖い。

報告する方は、純粋に嬉しいだけかもしれない。自分の頑張りで稼げることが。イノセントなだけで。その１万円があれば、自分の人生の選択肢が広がるコトも充分にある。僕も生活費に困ってたら収益第一路線になっていたと思います。ただ「おれはすげぇm9(^Д^)wwww」ってのはカッコ悪い。

世間的知名度を持たない一個人がブログを続けられる理由って、ほとんどない。しかし、カネにならないブログを僕は３つも持っている。こういう人間が異常。自覚は有る。このブログと、プログラミング等のことを書くブログと、野球のブログ。大好きな野球でも、相変わらず小難しいことを書いています。文章を書くのが大好きなのと、何度も何度も「この記事に出会えて嬉しい」という感想を頂いたのと、探していることがある。これが全て重なりあったので、カネにならないブログを持つ意味があるだけ。

今後も「はぐれブロガー純情派」として確固たるポジションを築きたいと思っています。ご愛顧のほど、どうぞよろしく。

【書評】エンジニアとして世界の最前線で働く選択肢

技術評論社傅様よりご恵贈頂きました。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

本書では、「日本人エンジニアがアメリカの現地企業に就職して生きていくとはどういうことか」を中心に書かれています。僕の書評では、アメリカのソフトウェア企業はどのようにエンジニアを評価しているのかにフォーカスしてお届けしたいと思います。

ソフトウェアエンジニアのエコシステムがある

本書に挙げられているアメリカで働くメリットとして、下記が挙げられています。

• 平均給与額が高く、ジョブマーケットの募集数も多い
• 外国人であるというハンディが少ない
• 転職回数が不利にならない

特に印象的だったのが、転職回数が不利に働くことはないということです。むしろ、転職回数が少なすぎると「他社に迎合されなかったのではないか」という評価を受けてしまうことがあるぐらいとのこと。ソフトウェアエンジニアは転職するのが当たり前で、企業の規模を問わず流動性がある為、エンジニアをいろんな環境で活用できるエコシステムが出来上がっていると言っても過言ではない印象を受けました。

シリコンバレーのような場所では、シリコンバレーという１つのメジャーリーグの一員になるようなものだそうです。AmazonからMicrosoftに移るというのは、レッドソックスからヤンキースに移るようなものみたい。おはエルズベリー。

専門色の高い知的労働者の世界は、プロ野球選手とよく似ていると思います。重要なのは流動性。この風潮は全体的なコンセンサスになると良いなぁと思いました。能力が高い人が集う世界は、できる人にあわせたほうが絶対に良いので。

エンジニアがエンジニアを評価する

第３章の転職のセクションがとても面白かったです。まずは電話面接(と言ってもSkypeのようなチャットツールでの面接)があって、そこでも腕試しにコードを書くことを求められるそうです。アメリカは広大ですし時差もありますから、オンサイトで呼びつけるのは最後の最後なんですね。

電話面接をクリアしたあとには、ホワイトボードコーディング面接が待っています。これを突破して初めて内定となるそうです。ホワイトボードコーディング面接については、本書の第４章に詳しく書いてありますのでご参照下さい。

最終的にはフェローかマネージャー

それしか無いもんね。技術を極めてピラミッドの頂点を目指すか、マネージャーとなって守備範囲を広げていくか。ただ、本書にあったのが「自分は仕事で全くコードを書かないのは無理だ」と主張して、マネージャーとしてのランクを１つ下げてまで自分でコードを書くことを選んだケースがあるそうです。すごいな〜。

英語はどこまで出来ればいいんですか？

読み書きと文法がわかれば生きていけるし、ネイティブ以上にもバイリンガルにもそう簡単にはなれないから、英語よりも仕事ができるということが一番重要だって書いてありました。R社の公用語の試みはどうなっているんでしょう。言語を統一するメリットはどこにあったのか、どこかのメディアが記事して欲しいです。脱線しました。

自分の足元を見直す一冊

本書ではアメリカに移るということで発する外国人としての生活環境や、日本的では無い就業環境に多く触れています。特にコアタイムが無いのは素晴らしい。時差もあるし、全員が同じ場所を共有できない前提で仕事が進められる仕組みづくりは大いに参考になりました。それだけに、自分が所属している組織が何を持って評価をしているのか、評価の良し悪しはどこでなされているのかを理解できていないと面食らうことになるのでしょう。

本書を読んで隣の芝生の感じながら、自分にとって譲れないものと目指したいものは何なのかを見直すの一冊となると思います。エンジニアの採用フローなんかはすごく面白かったので、ぜひご一読あれ。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

【書評】業務効率UP+収益力UP 中小企業のシステム改革

幻冬舎メディアコンサルティングの佐藤様よりご恵贈頂きました。

業務効率UP+収益力UP 中小企業のシステム改革 (経営者新書 152)

本書は、青山システムコンサルティング株式会社さんという独立系のITコンサルティングファームの代表の方が中心となって書かれています。こんな本が出るってことは、やはりまだまだまだまだ中小企業のIT活用は未成熟なのでしょう。

業務プロセスの徹底的な洗い出しが９割

本書の主題は上記にあります。構成としては「IT活用でやってもうた」→「KSFはこれ」→「Tobeの描き方」→「運用のあり方」となっており、一番重要なのは第３章です。で、その表題が「業務プロセスの徹底的な洗い出しが９割」です。これには120%同意します。

業務の仕組み全体がシステム

「業務の仕組み全体がシステムである」という一文。非常に重要な意味を持ちます。ここが全く理解できない経営者は、絶対にIT活用で成功しません。

メール・Webサイト・Officeソフトと言う、ある業務を代行していくれるソフトの活用はいくらでも可能。が、「業務の仕組みがどうなっているのか」に着目していないIT活用は常に部分最適になります。仕事の能率が上がっているように見えますが別の所で不便が出るというケースが非常に多く、俯瞰して見ると微妙な感じになってしまうわけです。

システムを導入する目的は「ある担当者の業務効率を改善する」ことでは絶対ダメです。システムを導入するのであれば、「会社全体としての業務効率を向上させる」ことが大前提で、そのシステムによって会社がより優れたサービスを顧客に提供することが可能にならなければならない。もうちょっと簡単にいえば、システムを利用するすべての立場の人にとってメリットがなければなりません。

優れたサービスの骨子となるのは、タイムリーな情報提供なのか、納期短縮なのか、商材拡大なのか。それはわかりませんが、売上の拡大に繋がる施策を打てるようにするための仕組みを作って、その中に流れる情報を定義し、設計し、管理できるようにする。それが出来ないと使えないコンピュータになってしまいまして、それを防ぐために必要なのが「業務プロセスの徹底的な洗い出し」というわけです。

恐らく、青山システムコンサルティングさんでも、上記のような残念なミスマッチがたくさんあったんじゃないでしょうか。心中お察し申し上げます。

本書では在庫管理を例に、現場の業務とシステム機能のミスマッチを幾つか挙げています。この在庫って単語もやっかいで、一語多義的です。複数の意味が含まれています。最低この４つの意味があります。

実棚	今、そこにある商品の数量そのもの
取置在庫	実棚の内、予約が付いていて勝手に使えないもの
フリー在庫	実棚から取り置きを引いたもの
バックオーダー	再生産中の商品における予約数

「在庫、ある？」と言ってるのは、フリー在庫なのか取置在庫なのかバックオーダーの残りの在庫なのか、これによって管理する情報が全く変わってきます。倉庫が複数ある場合は、A倉庫の在庫なのかB倉庫の在庫なのかでも、話が違ってきます。ネットショップ用の在庫なのか、実店舗や卸業者の在庫なのかでも話は変わります。

・・・このように、みなさんが何気なく使っている言葉にプロは鋭くツッコミを入れ、「一体どの情報を元にどんな意思決定をして、業務サイクルを回しているのか」をチェックしています。

最大の課題は人材不足

本書でも、中小企業のIT活用にとって最も頭の痛い問題が「ITの専門家が社内にいない」ことだと書いてあります。ここで言っているITの専門家と言うのは、最低限のアプリケーションを自分で作ることのできる人材だと僕は考えています。そのスキルがあって、上記のような業務設計ができる人材のことを専門家と呼ぶにふさわしいのですが、現状では太平洋に落ちたダイヤモンドを探すぐらい難しいようです。

この人材不足については「顧問エンジニア」という新しいロールを担う人材で少しは解決できるんじゃないかと淡い期待を抱いており、現在資料に落としている所です。概要を知りたい方は、僕のサブブログの下記記事を御覧ください。

aroundthedistance.hatenadiary.jp

なお、僕も業務システム導入・ITコンサルティングのご依頼は受け付けておりますので、お気軽に右下のお問い合わせウィジェットからお問い合わせ下さい。

堅実な成果を良しとする一冊

本書は奇をてらうわけでもなく、「御社がダメな理由」的な上から目線もなく、ある意味淡々とITシステムへの取り組み方が書かれています。ITシステムの効果を疑い始めたら、まずは本書を読んで大まかな背景を掴んで頂くのが良いでしょう。経営者の方のみならず、「なんでこんなシステムで仕事せなあかんねん」とお嘆きのご担当者様にも示唆に富んだ一冊になっています。

業務効率UP+収益力UP 中小企業のシステム改革 (経営者新書 152)

あわせて読みたい

gothedistance.hatenadiary.jp
gothedistance.hatenadiary.jp

【書評】世界を動かすプロジェクトマネジメントの教科書

技術評論社傅様よりご恵贈頂きました。いつもすいません。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方

こちらは初めてマネージャとなってチームを束ね、ひとつのプロジェクトを完遂させる為に何が必要なのかを書かれた入門書となっています。タイム・コンサルタントの日誌から というブログの中の人の一冊です。

WBSをちゃんと作る

本書の８割はここです。プロジェクトマネジメントの最大のポイントは、WBSが正しいかどうかです。間違ったタスクを管理してもしょうがないですから... タスクの妥当性を検証するには、それらのタスクを全て足して100となるかどうかで判断されます。簡単にいえば、抜け漏れがあってはならないということです。

では、WBS作成の抜け漏れを無くすにはどうしたらの良いのか。本書で触れられているエッセンスをご紹介します。

P-WBSとF-WBS

WBSの作成にあたっては求められる成果物をつくるために必要な「すべての作業(アクティビティ)」を「ゴールから逆算して」洗い出す必要があります。逆算して下さい。足し算するとメタボになります。それを吟味するために、成果物に着目したWBS(Product-WBS)と機能に着目した(Functional-WBS)の２つを作ると書いてありました。

例では冷やし中華という成果物をつくるために、成果物の構成要素に着目しアクティビティをリストアップします。麺、きゅうり、たまご、タレ、トマト...こんな感じですね。これだけは全部テーブルの上に乗っけただけなので、次は工程に注目します。作業の流れに沿って、いつどの作業をしなければ必要な成果物が出来ないのかを考えます。レシピを決める→食材を調達→調理→味見→配膳、みたいな感じです。

重要なのは、P-WBSとF-WBSは必ず交差します。仕事を生み出す構成要素(インプットとアウトプット)と、それらに必要な機能群が交わらないことはあり得ないからです。というわけで、これらをマトリックスにまとめたのがこちらの画像です。

こうすることで、各工程の抜け漏れを成果物の構成要素とその要素を扱う工程、いわばダブルチェックを走らせることができるというわけです。確認できたアクティビティマトリックスはリストとして一覧に落としこみます。

ここまでくれば、インプットとアウトプットに前後関係が生まれますので、それをチャートに並べることでネットワークダイアグラムという工程表の完成となります。そして、クリティカルパスを見つけて下さい。

この方法さえマスターすれば、確かに誰もある程度正確なWBSを組むことができるでしょう。構造的欠陥がないので。正確さの精度はWBS以外の要因もありますので。見積期間が甘いとか、そういうやつ。

クリティカルパスを守れ

クリティカルパスが分からなかったら絶対本書を読んで下さいね。で、プロジェクトの納期を短縮させるにはクリティカルパスを短くするしか無いので、それに関係のないタスクを前倒ししようが無駄に時間を食い潰すだけですからね...

クリティカルパスをどう守るかについては、故エリヤフ・ゴールドラット博士のクリティカルチェーンが有名です。本書でも簡単に取り上げられていますが、非常に単純に言うと個別タスクにバッファを持つのではなく、プロジェクト全体にバッファを設けようという考え方です。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

予算・進捗・リスク管理

WBS作成以降は各々１章ずつ上記テーマについて書かれております。どれも重要なポイントです。が、個人的にはアクティビティマトリックスがヒットだったので、その話ばっかりします。

アクティビティマトリックス。ええわ、これ。アクティビティマトリックスの応用範囲はすごく広い。あらゆる仕事に使えると思うんですよ。機能を作る時だって、成果物と処理内容に着目しますもんね。

プロジェクトマネジメント、きほんの「き」

本書を一言でまとめるなら、こういうことだと思います。リファレンスとしても重宝する一冊です。自信を持ってオススメします。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方

チケットを営利目的で転売する問題をどう解決するか

今日はセ・リーグの優勝が決まるかもしれない日です。しかも、ホームでの神宮球場の試合。チケット争奪戦が予想されていました。

当然のごとく、チケットの販売時間から球団公式サイト「スワチケ」は非常に接続が困難になり、仮押さえしたらSorryページに飛んだり、クレカの決済確認でSorryページに飛ばされて購入できない人がたくさん出ました。熱心なヤクルトファンの方が購入できなかったり、昨日のチケットをとっていたのに中止になって今日のチケットを買えなかった人も、たくさんいると思います...

その一方で、転売目的でチケットを入手した人もたくさんいたようで、ヤフオクで「神宮 ヤクルト 10/2」で検索した所、かなりの数が引っかかりました。

心情としては、本当にその公演を楽しみにしている人に適切な価格で購入できるチャンスが損なわれてしまう誠に遺憾であります。

本人縛りでは不都合も多い

転売自体を防ぐことは可能です。可能にするには、購入者以外の譲渡を一切できないように縛れば良い。購入時に顔認証やAppleのTouchIDのような指紋認証を入れるなどすれば本人以外の来場は無効となります。購入時にチケットに対して指紋を紐付けて、その指紋の変更を不可にし、入場時に来場者との指紋称号を行えば入場可能となる。こんな仕組みがあれば、転売を防ぐことは可能でしょう。

オークション等の転売市場に流出することを防ぐのはまず無理ですから、購入者以外の来場を全て無効にしてしまうのが、一番シンプルな解決策です。

が、他人に全く譲渡できないというのも不都合が多いですよね。

転売は真っ当な商取引

恐らくコンサートでも野球でも同じでしょうが、その公演自体が中止にならない限り、チケット購入後のキャンセル・変更・払い戻しは一切できません。明確な理由はわからないのですが、変更が可能となると色々と手続きが大変なのでしょう。

体調が悪くなったり、都合がつかなくなったりで、自分の友だちに代わりに行ってもらって楽しんでもらいたいと思うのは当然のことですし、「そんなの知るか。来れないなら買うな」では乱暴すぎるのも事実です。購入した商品をどういう形で使うかは、原則として消費者の自由。

が、転売を可能にする仕組みがあると、その転売の良し悪しを判断する手段が無いんですよね。違法性が無いからです。転売がNGなら、オークションは全てNGになります。大きく言えばフリマもNGになるでしょうし、金券ショップに売りに行くのもNG。

ダフ屋が現地会場近くで転売してれば地方迷惑条例等でひっかかりアウトですが、ネットオークションや金券ショップで買った事自体は完全に合法なわけですよね。乱暴に言えば「転売の問題って、チケットを定価で買えない恨み節でしょ？」と言えばそれまでの話。３倍でも買いたいという要求自体に違法性は無い。

嵐のコンサートチケットでヤフオクで出店されたのが確認された座席を無効とするという試みがあったそうです。本来は転売屋が罰せられるべきで金で解決した人には罪はない。転売を間接的に無効にするぐらいなら、本人認証必須のほうが筋が良いと思います。

転売の是非を決めるのは主催者

結局のところ、転売自体は真っ当な商取引ですからそれを取り締まるのは無理があります。さしたる社会的意義もない。公演を主催する立場の方が、転売を是とするか非とするかを決めるしか無いというのが現実的な落とし所だと思います。

転売を非とした場合、都合がつかない等でそのチケットが不要になった場合にどうするかという課題は残ります。ぴあの再販サービスのように、「キャンセル待ちで定価で買える」サービスを作って、そこを通さないで購入したチケットは無効とする。

・・・が、そこまでのインフラを作る金銭的負担は主催者にあるわけですし、チケットの売買利益が食われちゃうとやる意味がなくなる。その分の投資をするんでチケット代が15%上がりますとかだったら、納得出来ない人が多いよね。そんなことにはならないと思うけど。

なかなか難しい問題ですが、良い落とし所が見つからないものかと悩みます。

【書評】PHPはどのように動くのか〜PHPコアから読み解く仕組みと定石〜

技術評論社の傅様よりご恵贈頂きました。いつもありがとうございます。

PHPはどのように動くのか　?PHPコアから読み解く仕組みと定石

PHPの文法の解説ではなく、PHP4以降のコアとなっているZend Engineの解説書です。技術評論社でしか世に出せない一冊ではないでしょうか。

PHPコアとは何か

PHPは御存知の通り、インタプリタ型の言語です。PHPスクリプトを字句解析→構文解析を行い、「オペコード(opcode)」にコンパイルして、PHPの実行エンジン(Zend Engine)に食わせて実行します。このオペコードがどのように生成され、実行されているのか。割り当てた変数や関数のメモリはどう管理されているかを実行エンジンレベルで読み解いていくことで、PHPで書いたスクリプトの意味を見直そうというのが本書の趣旨です。目の付け所が濃ゆいですね。

オペコードのパフォーマンス

本書の第２章「オペコードのパフォーマンスを考える」が最も個人的に面白かったです。PHPスクリプトのパフォーマンスはオペコードで決まる、と。自分の書いたPHPスクリプトがこう評価されて実行されるのかと。演算子ひとつとっても、変換されるオペコードが違うのだなぁ...と。気をつけようって思いました。

著者とは違う方の資料ですが、この資料もオペコードを知るのに大変参考になりました。PHP5.5系から組み込まれたオペコードの最適化及びキャッシュを行う「OPcache」の解説です。

Zend OPcacheの速さの秘密を探る from Yoshio Hanawa

www.slideshare.net

コピーオンライト

PHPの実行エンジンの仕組みとして、コピーオンライトというものがあります。PHP5系では、全ての変数の型がコピーオンライトで管理されます。ある変数を代入して参照する時は同じメモリ領域を参照するだけで、コピー後の変数を書き換えた時に新たにメモリ領域を確保するという仕組みです。

<?php
$foo = 'foo';
$bar = $foo; //同じメモリ領域を指す
$bar = 'bar'; //新規にメモリ領域を割当

メモリ領域を節約できるので良さそうなのですが、PHP7系ではコピーオンライトを行う変数の型が制限されました。それ故にパフォーマンスの向上が見込めると本書にはあります。なかなか面白い話ですので、続きは本書をあたって下さい。

C言語の知識があると望ましい

Zend EngineがC言語で実装されていますので、C言語の知識があるとより本書の言わんとしてることが見えてくると思います。僕はほとんど知らないので、基礎文法ぐらいは抑えておこうかなって思いました...

PHPを書くなら目を通しておこう

オペコードを見て「へーそうなんだ」ぐらいの解釈でも全然OKだと思います。オペコードなるものに変換され実行される仕組みを全く知らないのは、PHPを書くのならもったいない。基礎知識として持っておくべきです。ざっと目を通しておくだけでも、何かしら知らなかったPHPの知見を得られることでしょう。

PHPはどのように動くのか　?PHPコアから読み解く仕組みと定石

面白かったです！