勘と経験と度胸だけの経営からの脱却

思考メモ

ソフトウェア開発の世界には、その品質を評価する基準となる品質特性がある。機能性,信頼性,使用性,効率性,保守性,移植性が、国際規格で決められていて、開発時の指標になる。

こうした品質特性の考え方は、政治や経営の文脈でも考えることができそうだし、むしろ人の考えや概念を扱うのがソフトウェアだとしたら、とてもフィットするのではないだろうか。


機能性は、企業としてのパフォーマンスを示す指標であり、顧客への価値を高めることで売上や成長率といった数字に繋がる。

信頼性は、企業を存続させるためのリスクマネジメントしているかどうかで、トラブルなく続けられるかどうかに繋がる。

使用性は、社員にとってのUXを高めることで、働き方の柔軟さや働きやすい制度などを用意することで採用や離職に繋がる。

効率性は、そのまま業務効率のことであり、無駄なコスト構造を解消し、生産性を高めることで、より多くの利益に繋がる。

保守性は、企業が成長していくにつれて、体制や制度の見直しが求められる中で、変化し続けていけるかどうかに繋がる。

移植性は、企業のサステナビリティを高めるために、後継者の育成や適切な権限委譲などを進めていくことに繋がる。


これら品質特性は、売上だけ見ててもダメなように、どれか一つだけでは持続しないので、うまくチューニングしていくことで、良い状態を作ることができる。

こうした品質の観点をもって経営に取り組むことで、よりバランスの良い健全な企業経営が実現できるように思う。

結果だけでなく過程を楽しむこと

思考メモ

ビジネスである限り、結果はとても大事だけど、結果だけを求めると、たまたま運が悪くうまくいかないときに辛いことになる。結果は大事にしつつ、そこに至る過程も大事にしたい。


もし仕事自体が楽しくできれば、少なくとも得るものはあったと思える。成功しないことは失敗ではないのかも。幸せになるまでは不幸であると思わない方が幸せという話に似ている。


旅をするときは、目的地があるけれど、目的地に辿り着くことだけをしている訳ではない。旅の途中で得た経験も財産になる。登山も自分の足で登るから頂上からの景色も一入になる。


過程を楽しむためには、健全な人間関係は欠かせない。むしろ、それが全てとも言える。気のおけない仲間となら、たとえ失敗してもフォローして、許し合えば一緒に笑い話にできる。


甘い話かもしれないが、仲間と共に楽しくやれている方が結果は後からついてくる気がする。現場が楽しく働いていれば結果が自ずと出るようにするのが経営かも。とても難しいけど。

マネジメントに必要な合理性と情緒性

思考メモ

仕事をしていく上で判断するときに、合理性がないといけない。合理的に説明できないことでは、人は動いてくれない。熱意や威圧なんかでは、瞬間的には動かせるかもしれないが長続きはしない。


直感や発想を否定しているわけではない。むしろ、新しいことを生み出すのに、合理的に考えても出てこない。合理性は、アイデアを補強していくことに有効であり、合理的でないアイデアは夢想。


一方で、仕事をするのが人だとしたら、情緒的に考えた仕組みにしなければ、誰も動いてくれない。合理的な内容は頭で理解できても、納得を引き出す訳ではない。感情を配慮しなければいけない。


閃いたアイデアの種を合理性でもって補強し、情緒性でもって柔軟にしていく。そこまで考え尽くしても正解とは限らないが、少なくとも誰に対しても説明できて、後から振り返って分析もできる。


マネジメントが「良い感じにすること」であるならば、情緒性を考慮することすらも、合理的に考えて必然のことになる。情緒性と合理性は相反するものではなく、同時に使いこなせばうまくいく。

遊びが学びに欠かせないわけ

思考メモ

理念に「遊ぶように働く」を掲げているので、改めて「遊び」について学んでみようと読んでみた書籍「遊ぶが学びに欠かせないわけ」。面白くて、良い知見がもらえた。

特に面白かったのは、心理学から捉えた遊びの効能の部分。これまで経営してきて、なんとなく実感してたことを、心理学の実験で説明されていて、心強い気持ちになったな。

ナレッジワーカーたるプログラマの仕事には、学び、問題解決、創造性が欠かせないけれど、それには仕事を遊びと捉えることが生産性の肝だと考えていたことに合致してる。

遊びの定義も参考になった。遊びは、自主的なもので、結果よりも過程が大事で、規則は参加者から生み出されて、想像するところから始まり、ストレスのない状態で行われる。

仕事を、まるで遊んでいるような状態にするには、そうした環境や構造をつくること。それこそが私たちがやってきたマネジメントだった。

また、農業以前の狩猟採集民の方が、豊かで幸せだったという話が興味深いものだった。

狩猟採集は、労働集約的ではなく、知識集約的・技術集約的なもので、高い技術と創造性が求められる。その仕事は、ワクワクして楽しいものだったので、仕事と遊びを分けることはしない。

狩猟採集の民には、骨を折って働くという仕事の捉え方はない。彼らはたくさんの物はなかったが、少ないニーズを少ない仕事で満たしたことで、たくさんの自由時間を持っていた。

その時間で、歌ったり、作曲したり、楽器を演奏し、物語を語ったり、ゲームで遊んだり、休んだりして過ごした彼らの社会を、文化人類学者が「最初の豊かな社会」と呼んだ。

これって、まるで私たちソニックガーデンで目指しているビジョンと合致していて驚いた。知識労働が中心になってくる中で、多くの人が望む社会の姿なのではないかなぁと思った。

チームで頼られる存在を目指す

思考メモ

チームに入ってすぐは、周りに相談するばかりで、良いチームほど助けてもらえるけれど、まるでお客様扱い。チーム内で人間関係を築いて相談できる相手を増やすことは大事だけど、それよりも周りの人たちから相談される存在になることの方が本質。チームとは、背中を預けられる同士の集まりでありたい。


一方的に相談したり助けたりする関係でなく、互いの強みを活かして相談しあうことで、チームとしての成果を出せる。そのために出来ることは、飲み会したり仲良くすることだけではない。チーム内で困ったことが起きたときに、声をかけてもらえるようになるには、自ら発信をして存在感を出していくこと。


例えば、チーム内で他の人には負けないと思えるような特定のスキルを身につけ、それに関するノウハウを発信して周りに知られれば、頼られるようになる。もしくは、スキルに自信がなくても、どんな仕事も前向きに受けることを伝えるだけでも、チーム内で困ったら相談しようと思ってもらえるようになる。


チームの一員だから貢献すべきと考えるより、チームの人たちから頼られる存在になれば本人にとって嬉しいし、それに応えて喜ばれると、さらに仕事も楽しくなると考える方が健全だし長続きする。自分に出来ることを探すのではなく、周りから頼ってもらえるようにする。チームワークに対する発想の転換。

プログラマ成長の加減乗除

思考メモ

プログラマの成長ステージにも 、仲山 進也さんの加減乗除の考え方が適用できそう。加のステージでは、コードを書いたり読んだりする絶対量が必要。書くほどに速くなるし、経験するほど設計と実装の引き出しが増える。ある程度の要件なら、タスクばらしと見積もりできることを目指す段階。


作りたいものが作れるようになったら、減のステージ。いかに効率的に成果を出せるようになるかを意識する。コスパが上がれば、時間に余裕ができるようになり、新しい技術に挑戦できるようになる。また、チームのメンバーとうまくコミュニケーションして、苦手なことを減らし得意なことに集中する段階。


乗のステージでは、ゼロからフルスクラッチで作れる設計・実装・運用の全般的な開発力に加えて、専門的な技術領域を持ち、その分野でリードできる。チーム内でも他の人を助ける場面が増え、多くのプロジェクトで頼られて、複数の案件に関わりつつセルフマネジメントして並列で価値を出していける段階。


技術領域でなく、バイネームで存在感が出せるのが、除のステージ。仕事はプログラミングだとしても、組織で言えば経営の視点や視野を持ちつつ、自分で考えて成果を出す。自分の趣味嗜好でやっていることと、仕事で成果が出ることが一致しているから、使役される労働ではない。「遊ぶように働く」段階。

趣味としてのプログラミング

思考メモ

少しずつプログラミングを始めてる。ちょっとブランクあるからリハビリから。来年の新卒予定の学生たちと一緒に遊ぶ感じでやってる。

英語やスポーツ、楽器などと同じで、習うのも大事だけど、自分で練習して慣れることの方が上達には大事なので、毎日少しでもやる。

本当の初学者には、いきなり実用的なアプリより、動きのある方が楽しいし、変数の中身をイメージしやすいのでゲームを作っている。

最初のうちは理論などすっ飛ばして、チュートリアルを写経して、自分の書いたコードが動くのを楽しむところから始めるのが良いかな、と。

動いた状態から少しずつ変えたりして、コードの意味を理解していけば良い。まだ正確な文法やコードの作法、保守性などは気にしなくて良い。

プログラミングは、実体のない活動なので、いくら失敗しても一円も原価はかからない。むしろ試行錯誤して動かすまでに楽しさがある。

そんな風に、まずはプログラミングが楽しいし、怖くないというように感じられるところから始めるのが良いのではないだろうか。

プロ野球選手もプロのミュージシャンも、みんな最初から職業を意識して始めた訳ではなく、見様見真似で遊ぶところから始めたはずだ。

そうした趣味で遊ぶようなプログラミングは、大人になってからも出来る機会があると良いな、と思う。休日の草野球やフットサルみたいに。

なにも職業としてやる人だけのものではないのは、プロ野球選手じゃなくても野球を楽しめるのと同じことで、プログラミングも楽しめると思う。

昨今の多くのプログラミングスクールは、転職や就職を目的としたものが多いけれど、そうでない大人のプログラミング教室があっても良いのに。

ただし、プログラミング教室に通ったところで、職業プログラマになるのは相当に厳しい。ピアノ教室に通ってもプロのピアニストにはなれない。

それで良いのだ。大人がピアノ教室に通うのはプロになるためよりも、自分の趣味や教養として、楽しむために通っている人の方が多いはず。

スポーツや音楽を少し嗜むだけで、プロプレーヤーの凄さがわかるのと同じように、職業プログラマの凄さを理解できるようになると世界は変わる。

そしてプログラミングの場合は、趣味の延長上でも普段の仕事にも活かすことができる。業務改善で自らプログラミングできれば素晴らしい。

経理の人がプログラミングを覚えたら、自動化して効率的に数字を出せるように、マーケの人なら自分でA/Bテストを組めるかもしれない。

いずれ多くの職業にとって、今のパソコンを扱うのと同じ程度のリテラシーとしてプログラミングが求められる時代がくるかもしれない。

業務の付加価値としてのプログラミングが広まる程に、プログラミングを専門にする職業プログラマの価値が高まっていくかもしれない。

そのようにプロとしてプログラミングをやっていこうとする人には、趣味の教室より長い時間と実践を積める本当の意味での学校があると良い。

もし、そんな学校を作るなら、お金さえ払えば誰でも受けれるのではなく、大学のように入学に試験があり、卒業にも判定があるようにしたい。

私はプログラミングが好きなので、プログラミングを楽しんでいる人を見ると嬉しくなるし、誇りを持って取り組んでいる人を見ると尊敬する。

誰もが音楽を楽しむようにプログラミングを楽しむ。一方で、専門のプロとして価値を生むには相当な技量が求められるからこそ尊敬される。

そんな世界が実現できたら良いな、と。

内発的動機付けのマネジメント

思考メモ

頭を使う難しい仕事であるほどに、教科書もなくマニュアルにも出来なくて、属人性は高まっていく。そうした難しい仕事だからこそ、高い価値が付けられる。そして、高度な仕事になるほど、指示命令と管理監督で成果を出させるのが難しくなる。内発的動機付けで自律的に働いてもらうマネジメントになる。

内発的動機付けで働いてもらうマネジメントの肝は、そもそも会社と社員の間で、働く目的や価値観が揃っていること。だから、会社側だけでなく応募する側にとっても、採用時の見極めが非常に重要になる。最初に掛け違えると、後は報酬など外発的動機付けに頼ることになるが、それだけでは続けられない。

内発的動機付けで働いてもらうには以下の4つは外せない。1.成長が続くこと。レベルアップすると楽しくて続けてしまう。2.裁量があること。難易度を自分たちで調整できると頑張れる。3.正解がないこと。やり方で試行錯誤できると挑戦しがいがある。 4.仲間がいること。一緒に喜び苦労するから楽しい。

プログラマの仕事はコードを書くことか

思考メモ

プログラマの仕事を端的に表すときに「コードを書く」と言ったりするが、それによって単調な仕事だと勘違いされることがある。その誤解は、カメラマンの仕事を「シャッターを押す」だったり、小説家の仕事を「日本語を書く」と言うようなもの。手を動かしてはいるが、実際は頭を使うことが主な仕事だ。


ソフトウェアは、一つのアプリケーションが一つの作品のようなもので、一部の改変が全体に影響を与えることがあるし、一部に品質の悪さがあると全体の品質を落としかねない。製造業のように同じものを沢山つくる訳ではないから、多少の不良品を許容するような作り方はできない。製造でなく設計なのだ。


コードを書くことを単純作業だと誤解した経営者は、より多くのソフトウェアを製作するために人を増やせば良いと考える。しかし、実際には闇雲に人手を増やせば、むしろ全体の生産性を落としてしまうことになる。まさしく『遅れてるプロジェクトへの要員追加は、さらに遅らせるだけである』の言う通り。


沢山の人を入れても混乱せずに生産性と品質を出せるようにと考える勢力と、人を増やさず少人数のままで一人当たりの出来ることを増やして生産性と品質を高めるように考える勢力がある。抽象化や仮想化を重ねるソフトウェア技術の進歩の方向性は後者だと思うし、エンジニアの気持ちとしても後者を望む。


ソフトウェアをチーム開発していくなら、ソースコードの設計に対するポリシーや品質の価値観を揃えること、その上で少人数チームを維持すること、人の増員を単純な足し算で考えないことなど、ソフトウェアの本質とエンジニアのモチベーションについて深く理解した上でマネジメントしていく必要がある。

ページ 3
ページ上部へ